mirror of https://github.com/azaion/gps-denied-onboard.git synced 2026-06-21 08:51:12 +00:00

Files

T

Oleksandr Bezdieniezhnykh c19c76481c 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.

2026-05-09 03:10:57 +03:00

7.5 KiB

Raw Blame History

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:

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).
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:

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.
The Plan skill should add Design Task #1 + Design Task #2 to the satellite-provider Plan cycle as new components / endpoints.
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).

7.5 KiB Raw Blame History Unescape Escape

Parent-suite design tasks for satellite-provider