mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-06-21 10:31:13 +00:00
Update autodev skill documentation and acceptance criteria
Enhanced the SKILL.md file to enforce conciseness rules for the state file, specifying acceptable content and file size limits. Updated the autodev state to reflect the transition to the planning phase, including changes to the current step and sub-step details. Revised acceptance criteria to clarify validation requirements and external dependencies, ensuring alignment with the latest research findings. Added a new overlay for Mode B revisions to track changes and decisions made during the assessment process.
This commit is contained in:
Oleksandr Bezdieniezhnykh
@@ -0,0 +1,103 @@
|
||||
# Parent-suite design tasks for `satellite-provider`
|
||||
|
||||
**Date created**: 2026-05-09 (Plan Phase 2a.0 outcome — `gps-denied-onboard` workspace)
|
||||
**Workspace this leftover lives in**: `gps-denied-onboard`
|
||||
**Workspace work needs to happen in**: `/Users/obezdienie001/dev/azaion/suite/satellite-provider/`
|
||||
**Type**: cross-workspace dependency surfaced from this Plan cycle, NOT a tracker write blocker
|
||||
|
||||
---
|
||||
|
||||
## Why this is a leftover
|
||||
|
||||
During Plan Phase 2a.0 (Glossary + Architecture Vision) for `gps-denied-onboard`, two assumptions in `_docs/01_solution/solution.md` were validated against the actual `satellite-provider` codebase and found broken:
|
||||
|
||||
1. **AC-8.4 — mid-flight tile upload to the Service**: `solution.md` and `acceptance_criteria.md` both assume the onboard system uploads orthorectified mid-flight tiles to `satellite-provider` after landing. **`satellite-provider` has no inbound ingest endpoint.** It is read-only from the onboard side (downloads tiles from Google Maps + serves them).
|
||||
|
||||
2. **AC-NEW-7 — multi-flight ingest-side voting / trust layer**: `solution.md` assumes the Service operates "a multi-flight ingest-side voting layer that gates onboard-tile promotion to 'trusted basemap' until multiple independent flights agree on geo-alignment". **No such layer exists in `satellite-provider`.**
|
||||
|
||||
Both gaps are parent-suite design / build tasks. They are tracked in this onboard workspace as **D-PROJ-2** and surfaced to the parent suite via this leftover file.
|
||||
|
||||
`gps-denied-onboard` will proceed in this Plan cycle treating both as planned external capabilities; the architecture document references them as such.
|
||||
|
||||
---
|
||||
|
||||
## Why these are NOT replayed automatically
|
||||
|
||||
Per `.cursor/rules/tracker.mdc` § Leftovers Mechanism, this leftover does NOT block onboard progress and does NOT auto-replay because:
|
||||
|
||||
- Replay requires writes against a different workspace's `_docs/` (and tracker entries against `satellite-provider`'s tracker scope).
|
||||
- The next `/autodev` invocation in the **`satellite-provider`** workspace should pick this up at its own Bootstrap step. Cross-workspace leftover replay is intentionally human-gated.
|
||||
|
||||
If you (the human) explicitly want me to write these design tasks into `satellite-provider/_docs/` from this conversation, say so — I have the user's permission from the 2026-05-09 turn ("If it doesn't provide sufficient information, then analyze the repository, think about the best solution to tile selection process, and document it there"). I held back to respect the workspace boundary discipline this autodev session was operating under.
|
||||
|
||||
---
|
||||
|
||||
## Design task #1 — Inbound tile ingest endpoint
|
||||
|
||||
**Trigger**: AC-8.4 (mid-flight tile generation, post-landing upload) per `gps-denied-onboard/_docs/00_problem/acceptance_criteria.md`.
|
||||
|
||||
**Contract sketch (from the onboard side)**:
|
||||
|
||||
```
|
||||
POST /api/satellite/tiles/ingest
|
||||
Content-Type: multipart/form-data
|
||||
|
||||
Fields per tile (one or more per request, batched):
|
||||
- tile_blob: JPEG body, byte-identical to satellite-provider's existing tile format
|
||||
- zoomLevel: int — same semantics as satellite-provider's existing tiles table
|
||||
- latitude: double — center latitude (composite key element)
|
||||
- longitude: double — center longitude
|
||||
- tile_size_meters: double
|
||||
- tile_size_pixels: int
|
||||
- capture_timestamp: ISO 8601 — when the onboard companion generated the tile
|
||||
- flight_id: UUID — which flight this tile came from
|
||||
- companion_id: string — which deployed unit produced it
|
||||
- quality_metadata: JSON blob (per AC-8.4 quality metadata for the Service's voting pipeline):
|
||||
- estimator_label: "satellite_anchored" | "visual_propagated" | "dead_reckoned"
|
||||
- covariance_2x2: [[σ_xx, σ_xy], [σ_yx, σ_yy]] — horizontal sub-matrix at tile-emit time
|
||||
- last_anchor_age_ms: int — AC-1.3 binning input
|
||||
- mre_px: double — reprojection error at the contributing match
|
||||
- imu_bias_norm: double — VIO health proxy
|
||||
- signature: optional — onboard companion's per-flight key signature over the payload (for source authentication; Plan Phase 2a.0 carryforward)
|
||||
|
||||
Response: 202 Accepted with batch UUID + per-tile ingest status (queued / rejected / duplicate / superseded).
|
||||
```
|
||||
|
||||
**On-disk persistence**: tiles stored in the same `./tiles/{zoomLevel}/{x}/{y}.jpg` layout as existing Google-Maps-sourced tiles. Service's existing `tiles` table extended with: `flight_id`, `companion_id`, `capture_timestamp`, `source` (`googlemaps | onboard_ingest`), `quality_metadata` (jsonb), `voting_status` (`pending | trusted | rejected`).
|
||||
|
||||
**Design questions for `satellite-provider`'s Plan phase**:
|
||||
- How to authenticate the onboard companion (mTLS? per-flight ephemeral keys? signed payload?). Companion is a remote untrusted endpoint by threat model.
|
||||
- How to rate-limit ingest (a compromised companion could DOS the basemap).
|
||||
- How to expose an admin/operator UI to inspect ingested-but-not-yet-trusted tiles.
|
||||
|
||||
---
|
||||
|
||||
## Design task #2 — Multi-flight trust / voting layer
|
||||
|
||||
**Trigger**: AC-NEW-7 (cache-poisoning safety budget; cross-flight error compounding) per `gps-denied-onboard/_docs/00_problem/acceptance_criteria.md`.
|
||||
|
||||
**Goal (from the onboard side)**: when `satellite-provider` serves tiles to a future flight's pre-flight cache build, tiles ingested from prior flights must NOT be served as "trusted basemap" until multiple independent flights agree on geo-alignment for the same area.
|
||||
|
||||
**Algorithmic intent (not prescriptive — Service team owns the design)**:
|
||||
- Tiles enter with `voting_status = pending`.
|
||||
- A tile is promoted to `voting_status = trusted` when ≥N independent companions (different `companion_id`) have ingested geometrically-consistent tiles covering the same lat/lon/zoom cell, weighted by the quality metadata above.
|
||||
- The pre-flight cache builder (operator-side tool) consumes only `trusted` tiles by default; can be overridden to accept `pending` tiles for stale-area refresh, with explicit operator confirmation.
|
||||
- Stale tiles (per AC-8.2 freshness) are demoted on age regardless of trust status.
|
||||
|
||||
**Design questions for `satellite-provider`'s Plan phase**:
|
||||
- N (votes-required threshold) — driven by AC-NEW-7's safety budget back-solved against measured per-flight pose error CDF.
|
||||
- How to detect adversarial agreement (multiple compromised companions colluding) — out-of-band integrity checks against Google Maps ground truth?
|
||||
- What "geometric consistency" means quantitatively (pixel-level RANSAC on overlapping tiles? GTSAM factor-graph over multi-flight poses?).
|
||||
- What happens when `trusted` tiles disagree with newly ingested `pending` tiles in active-conflict sectors (legitimate scene change vs. cache poisoning).
|
||||
|
||||
---
|
||||
|
||||
## Hand-off
|
||||
|
||||
Next time `/autodev` runs in the **`satellite-provider`** workspace:
|
||||
|
||||
1. Bootstrap should detect this leftover via cross-workspace search (`/Users/obezdienie001/dev/azaion/suite/gps-denied-onboard/_docs/_process_leftovers/`) — NOTE: cross-workspace leftover detection is not yet implemented in autodev; human operator must surface this manually for now.
|
||||
2. The Plan skill should add Design Task #1 + Design Task #2 to the satellite-provider Plan cycle as new components / endpoints.
|
||||
3. After both are implemented, this leftover can be deleted from `gps-denied-onboard`.
|
||||
|
||||
Until then, `gps-denied-onboard` Plan / Decompose / Implement phases will proceed with the architecture vision treating both capabilities as **planned external dependencies** (not yet available, but contract is sketched above).
|
||||
Reference in New Issue
Block a user