gps-denied-onboard/_docs/_process_leftovers/2026-05-21_az777_complexity_override.md

AZ-777 — Complexity override (8 pts, single ticket)

Timestamp: 2026-05-21T13:30:00+03:00 Type: Decision log (not a blocked tracker write) Decision-maker: user (explicit choice via /autodev questionnaire 2026-05-21)

Context

The standard PBI complexity rule in user_rules says:

Create PBI with 2 or 3 points of complexity, could be 5. Do not create very complex PBIs with more than 5 points.

AZ-777 was originally a 5-pt task ("write a script that downloads OSM/CARTO basemap tiles directly"). During cycle-3 Step 10 implementation, the agent surfaced that the task spec contradicted the architecture (C10 does not touch satellite-provider; C11 owns that path against the real parent-suite .NET service). The user was asked to choose among:

• A) Decompose AZ-777 into 4 sub-tickets (AZ-777-a/b/c/d), cancel original
• B) Rewrite AZ-777 in place, expand to 8 pts, keep single ticket, multi-session implementation
• C) Implement original spec as-written (ignore architecture mismatch)
• D) Close cycle, pick up later

User chose B.

Override rationale

The four sub-deliverables (satellite-provider stand-up, Derkachi catalog seeding, operator_pre_flight_setup rewrite, Tier-2 AC-4/AC-5 validation) only deliver demo-confidence value when shipped together. Splitting them into four PBIs would create a half-shipped state where:

• AZ-777-a alone leaves the e2e harness with a satellite-provider service that nothing consumes.
• AZ-777-b alone seeds a tile catalog that nothing queries.
• AZ-777-c alone tries to drive a fixture without the upstream service in place.

The user's preference is single-ticket containment with explicit phase boundaries documented in the task spec (Phases 1–5 + STOP gates per phase). This is the "single ticket but staged execution" pattern, not the "decompose into sub-tickets" pattern.

STOP-gate enforcement

The rewritten AZ-777 spec includes explicit STOP gates between phases:

1. Phase 1 → Phase 2: If satellite-provider stand-up fails for parent-suite reasons (contract drift, arm64 issue), STOP and file a parent-suite ticket. Do not work around on the onboard side.
2. Phase 2 → Phase 3: If satellite-provider's region-onboarding endpoint shape differs from what the seed script expects, STOP and file a parent-suite ticket.
3. Any phase → next: If the implementation runs into work that materially exceeds the remaining phase's budget, STOP and propose decomposition (escape hatch into the 4-ticket split that was option A above).

The "single ticket" property is preserved as long as work proceeds linearly. If it grinds at any phase boundary, decomposition becomes the escape hatch. The user has been informed of this escape via the task spec's Risk 5.

Replay obligation

This is NOT a tracker write blocker — Jira is reachable and the AZ-777 description + story points update is being made in the same /autodev turn that this decision log is being written. This file is the AUDIT TRAIL for the override, not a deferred-write record.

No replay action required on subsequent /autodev invocations. The file can be deleted once AZ-777 is moved to done/, but it's small enough that keeping it as historical documentation of the decision is fine.

2026-05-21 spec-refresh addendum (cycle-3 batch 104)

The /autodev session that was supposed to execute Phase 1 instead discovered material drift between the prior session's rewritten spec and current codebase reality. Findings:

• Tier-1 is deprecated per _docs/02_document/tests/environment.md 2026-05-20 active policy. The original Phase 1 explicitly modified docker-compose.test.yml — that file is now out of scope.
• Jetson compose already has the real satellite-provider service (satellite-provider + satellite-provider-postgres, lineage AZ-688 / AZ-691 / AZ-692; no local task spec files for those tickets — they were closed Jira-side without local /decompose output). Original spec said "add service" — already there.
• Port / protocol mismatch: original spec said port 5101 HTTP; actual is 8080 HTTPS with self-signed dev cert (per Dockerfile EXPOSE 8080 + Jetson compose ASPNETCORE_URLS: https://+:8080).
• DB naming: original spec said satellite-provider-db; existing convention is satellite-provider-postgres.
• mock-sat already retired from Jetson compose. D-PROJ-2 / POST /api/satellite/upload has shipped on the real satellite-provider (Program.cs:211). MOCK_SAT_UPLOAD_URL env var that the original spec proposed retaining doesn't exist in source code at all.
• C11 contract drift surfaced: C11's _LIST_PATH = /api/satellite/tiles and _GET_PATH = /api/satellite/tiles constants in tile_downloader.py:61-62 do NOT match the real satellite-provider API. Actual endpoints (Program.cs:187-209):
  • POST /api/satellite/tiles/inventory (bulk lookup by (z,x,y) or locationHashes per tile-inventory.md v1.0.0)
  • GET /tiles/{z}/{x}/{y} (slippy-map tile fetch) Phase 1 now includes C11 contract adaptation — this is the largest single sub-deliverable of the refreshed Phase 1 and explains why the 8-pt budget stays appropriate even after dropping the Tier-1 mods.
• arm64 manifest verified: mcr.microsoft.com/dotnet/aspnet:10.0 has a multi-arch manifest including arm64 (per docker manifest inspect). Risk 3 of the original spec (cross-compile follow-up) is CLOSED — no follow-up ticket needed.

The user chose option A from the spec-reconciliation Choose block: refresh the spec to match reality, re-sync Jira, then proceed with the corrected Phase 1 in a fresh session.

The 8-pt complexity stays. Phase boundaries (STOP gates between phases) preserved. Single-ticket containment preserved.

Both this addendum and the canonical local spec at _docs/02_tasks/todo/AZ-777_derkachi_c6_reference_fixture.md were updated in the same /autodev turn that synced the refresh to Jira.