azaion/gps-denied-onboard
1
0
Fork 0
mirror of https://github.com/azaion/gps-denied-onboard.git synced 2026-06-22 06:51:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

[AZ-489] [AZ-490] ADR-010 design pass: operator-mission as cold-start anchor

Browse Source 
Architecture, contracts, and task amendments for the flight-route-driven
preflight + cold-start origin feature (ADR-010). No source code touched
in this commit; the implementation commits for AZ-489 / AZ-490 / AZ-419
land separately.

* architecture.md: ADR-010, new Principle #14, amended Principle #11,
  external systems gain flights service + Mission Planner UI, data
  model gains Flight / Waypoint / TakeoffOrigin.
* system-flows.md: F1 gains phase 0 (Flight resolve), F2 gains
  cold-start ladder, F7 gains mid-flight bounded-delta GPS gate.
* glossary.md: Flight, Flights API, Mid-flight bounded-delta GPS gate,
  Mission Planner UI, Takeoff origin, Waypoint.
* C10: description + cache_provisioner + manifest_verifier bumped to
  v1.1 carrying takeoff_origin + flight_id in the manifest hash.
* C12: description updated + new flights_api_client.md contract v1.0.
* C5: description + state_estimator_protocol bumped to v1.1 with
  set_takeoff_origin + 3-clause spoof-promotion gate.
* AZ-323/324/325/326/328/419 amended in place. AZ-490 spec created
  (C5 set_takeoff_origin entrypoint).
* Dependencies table: 142 tasks / 478 pts / 15 forward edges
  (2 new tasks, 2 backward deps, 2 forward deps from AZ-419).
* Leftovers cleared: 2026-05-11 Jira transition entries for AZ-355
  and AZ-386 are deleted (Jira reconnected; both already transitioned
  in their respective implementation commits).

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Oleksandr Bezdieniezhnykh
2026-05-12 01:28:05 +03:00
parent db27e25630
commit e0be591b06
20 changed files with 875 additions and 221 deletions
Download Patch File Download Diff File Expand all files Collapse all files
_docs/_process_leftovers/2026-05-11_jira_transition_az355_deferred.md
-45
View File
@@ -1,45 +0,0 @@
# Jira transition for AZ-355 deferred — MCP "Not connected"
**Recorded**: 2026-05-11T10:50+03:00 (Europe/Kyiv)
**Status**: deferred-non-user (replay on next autodev invocation when Jira MCP is connected)
## What is blocked
Status transition of `AZ-355` from `To Do` → `Done` to reflect that
Batch 20 has landed the C4 `PoseEstimator` Protocol + factory + DTOs
+ composition wiring (see
`_docs/03_implementation/batch_20_cycle1_report.md`).
## Why
The Atlassian MCP server returned `"Not connected"` on
`getAccessibleAtlassianResources` during the Batch 20 wrap-up — same
failure mode that AZ-386 hit a few hours earlier. Per the
Leftovers Mechanism the write is recorded here and the non-tracker
work (commit, push) is allowed to proceed; the next autodev
invocation will replay the transition.
## Replay payload
- **Tool**: `transitionJiraIssue`
- **cloudId**: `denyspopov.atlassian.net`
- **issueIdOrKey**: `AZ-355`
- **target status**: `Done` (transition id is project-specific; resolve
via `getTransitionsForJiraIssue` at replay time — Jira project `AZ`
uses the standard "Software" workflow so the transition is `id: 31`
in current Jira config; confirm at replay time).
## Acceptance check on replay
After the transition succeeds:
- `getJiraIssue(AZ-355)` returns `fields.status.name == "Done"`.
- Delete this leftover file.
## Notes
- Code, tests, docs, and state file are all updated and committed. The
only outstanding action is the tracker status transition; the
AZ-355 task spec is already in `_docs/02_tasks/done/`.
- The previous leftover for AZ-386 is still pending; replay both in
one batch when the MCP comes back.
_docs/_process_leftovers/2026-05-11_jira_transition_az386_deferred.md
-44
View File
@@ -1,44 +0,0 @@
# Jira transition for AZ-386 deferred — MCP "Not connected"
**Recorded**: 2026-05-11T10:00+03:00 (Europe/Kyiv)
**Status**: deferred-non-user (replay on next autodev invocation when Jira MCP is connected)
## What is blocked
Status transition of `AZ-386` from `To Do` → `Done` to reflect that
Batch 19 has landed the `EskfStateEstimator` mandatory simple-baseline
in code + tests + documentation (see
`_docs/03_implementation/batch_19_cycle1_report.md`).
## Why
The Atlassian MCP server returned `"Not connected"` on both
`transitionJiraIssue` and `getAccessibleAtlassianResources` during the
Batch 19 wrap-up. This is the documented "MCP unavailable" failure
mode in `.cursor/rules/tracker.mdc`. Per the Leftovers Mechanism the
write is recorded here and the non-tracker work (commit, push) is
allowed to proceed; the next autodev invocation will replay the
transition.
## Replay payload
- **Tool**: `transitionJiraIssue`
- **cloudId**: `denyspopov.atlassian.net`
- **issueIdOrKey**: `AZ-386`
- **target status**: `Done` (transition id is project-specific; resolve
via `getTransitionsForJiraIssue` at replay time — Jira project `AZ`
uses the standard "Software" workflow so the transition is `id: 31`
in current Jira config; confirm at replay time).
## Acceptance check on replay
After the transition succeeds:
- `getJiraIssue(AZ-386)` returns `fields.status.name == "Done"`.
- Delete this leftover file.
## Notes
- Code, tests, docs, and state file are all updated and committed. The
only outstanding action is the tracker status transition; the
AZ-386 task spec is already in `_docs/02_tasks/done/`.