mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-06-21 05:41:13 +00:00
Oleksandr Bezdieniezhnykh
63c0217e3d
AZ-835 Epic (E2E real-flight validation pipeline, ~17 SP across 6 children C1-C6) supersedes AZ-777 Phase 3+ (bbox-based static seed). Children C3-C6 deliberately not yet filed — will be re-estimated after C1+C2 land from real RouteSpec shape and Route API client ergonomics. - AZ-836 (C1, 3 SP): TlogRouteExtractor — pure function over .tlog binary returning RouteSpec (waypoints + suggested region size). Deps: AZ-697 (load_tlog_ground_truth, done), AZ-279 (WGS converter, done). - AZ-838 (C2, 3 SP): SatelliteProviderRouteClient + seed_route.py CLI mirror of seed_region.py. Hard-depends on AZ-836's RouteSpec dataclass. - _dependencies_table.md updated with the three new rows. Workspace-boundary rule expansion: codifies the sibling-repo task-spec exception (the only permitted write into a sibling repo) and the "External Systems Are Black Boxes" rule (contract-only consumption of producer repos like satellite-provider). Bookkeeping: _autodev_state.md condensed to <30 lines per the state.md conciseness rule; opencv-pin leftover replay re-checked 2026-05-22 (gtsam still only 4.2, replay condition unchanged). Co-authored-by: Cursor <cursoragent@cursor.com>
45 lines
4.8 KiB
Plaintext
45 lines
4.8 KiB
Plaintext
# Workspace Boundary
|
|
|
|
- Only modify files within the current repository (workspace root).
|
|
- Never write, edit, or delete files in sibling repositories or parent directories outside the workspace.
|
|
- When a task requires changes in another repository (e.g., admin API, flights, UI), **document** the required changes in the task's implementation notes or a dedicated cross-repo doc — do not implement them.
|
|
- The mock API at `e2e/mocks/mock_api/` may be updated to reflect the expected contract of external services, but this is a test mock — not the real implementation.
|
|
- If a task is entirely scoped to another repository, mark it as out-of-scope for this workspace and note the target repository.
|
|
|
|
## Exception — Adding Task Specs to Sibling Repos
|
|
|
|
The ONLY permitted form of writing into a sibling repository is **creating task-spec markdown files** (and updating the matching `_dependencies_table.md`) in that repo's `_docs/02_tasks/todo/` directory, and ONLY when the user explicitly asks for it in the current turn.
|
|
|
|
- "Explicit" means the user names the action (e.g. "add the md files to satellite-provider", "create the task spec there", "mirror it into their repo"). Inference from context is NOT enough — ask first.
|
|
- Mirror the sibling repo's existing template (read ONE of their `done/` task files to learn the format — this is process documentation, not source code).
|
|
- NEVER commit or push in the sibling repo unless the user separately and explicitly authorizes it. Default is "write to disk, leave for their review".
|
|
- Update `_dependencies_table.md` to keep it consistent with the new task files.
|
|
- The exception covers task specs ONLY. It does NOT extend to source code, CI/compose files, README, design docs, scripts, env templates, or any other file type in the sibling repo.
|
|
- Each task-spec md must point back to the Jira ticket (which is the source of truth) and reference where the work was discovered (originating ticket in this repo).
|
|
|
|
## External Systems Are Black Boxes
|
|
|
|
External systems (sibling repos, third-party services, parent-suite services like `satellite-provider`) are treated as **black boxes** governed by their published **contract** (OpenAPI spec, contracts/*.md, public schemas, env-var docs).
|
|
|
|
- Treat the contract as the ONLY source of truth about an external system. The contract is what you may rely on; the implementation is what you may NOT rely on.
|
|
- Do NOT investigate, grep, read, browse, or reason about an external system's internal source, internal directory layout, internal database schema, internal config files, persistent volumes, cache contents, log formats, deployment scripts, or any other implementation detail — even when the sibling repo is right there on disk and you could.
|
|
- The ONE acceptable use of an external repo's source files is to READ ITS CONTRACT (e.g., `../satellite-provider/_docs/02_document/contracts/api/*.md`, an `openapi.yaml`, a `.proto`, a published schema). The contract may live in the sibling repo because that's where the producer documents it — that's fine. Anything OUTSIDE the contract directory is off-limits.
|
|
- When the external system fails (returns errors, returns malformed data, is unreachable, contradicts its contract): STOP and report it to the user with the exact symptom (status code, error message, missing field, timeout). Do NOT diagnose why by reading the external system's internals. The producer team owns its own diagnosis. The signal is the symptom.
|
|
- "It works" / "it doesn't work" is the only thing you may conclude about an external system. "It works this way because of X internal mechanism" is forbidden.
|
|
|
|
## Why
|
|
|
|
- Internals drift; contracts are stable. Reasoning that depends on internals breaks when the producer refactors.
|
|
- Investigating internals trains the wrong mental model — agents start "fixing" cross-repo bugs by adapting consumer code to producer quirks instead of flagging the contract gap.
|
|
- The producer team is the authority on its own system. Bypassing them creates two competing diagnoses and erodes the contract boundary.
|
|
- Time spent reading external internals is time NOT spent on the actual scope.
|
|
|
|
## Concrete examples
|
|
|
|
- ✅ Reading `../satellite-provider/_docs/02_document/contracts/api/tile-inventory.md` to learn the inventory POST schema.
|
|
- ❌ Reading `../satellite-provider/SatelliteProvider.Api/Program.cs` to learn what the inventory endpoint does internally.
|
|
- ❌ Listing `../satellite-provider/tiles/` to see what tiles are cached.
|
|
- ❌ Reading `../satellite-provider/.env` to figure out what env vars it expects (read the producer's published `.env.example` or contract doc instead).
|
|
- ✅ Reporting "satellite-provider returns 500 when I POST a 1-tile inventory for (z=15, x=19308, y=11420)".
|
|
- ❌ Reporting "satellite-provider returns 500 because its `TileService.GetInventoryAsync` throws when the Postgres `tiles` table is empty".
|