Oleksandr Bezdieniezhnykh
1198890b74
Original spec called for direct OSM/CARTO downloads, contradicting architecture (C11 owns tile network I/O against parent-suite satellite-provider .NET 8 service; C10 batches descriptors over the populated C6, never touches the upstream). Rewritten spec drives the production C10/C11 pipeline against the real satellite-provider running in docker-compose.test.yml, replacing the mock-suite-sat- service GET stub. Complexity 5 -> 8 pts (single-ticket override). Decision log: _docs/_process_leftovers/2026-05-21_az777_complexity_ override.md. Jira AZ-777 description + summary synced. Autodev state pauses for next session to pick up Phase 1 (satellite-provider stand-up + smoke test). Co-authored-by: Cursor <cursoragent@cursor.com>
3.2 KiB
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:
- 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.
- 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.
- 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.