gps-denied-onboard/_docs/02_document/architecture_compliance_baseline.md

Architecture Compliance Baseline

Purpose. Single canonical document against which every cumulative-review report (per .cursor/skills/code-review/SKILL.md Phase 7 + the implement skill's Step 14.5 cumulative review) computes its ## Baseline Delta — the count of carried-over, resolved, and newly-introduced architecture violations. Without this file, cumulative reviews log "baseline not found → no Baseline Delta section emitted" and structural regressions are visible only pairwise per batch instead of cumulatively.

Baseline established: 2026-05-26 (cycle-4 Step 10, batch 1, AZ-899) Source-of-truth snapshot: _docs/06_metrics/structure_2026-05-20.md Initial violation count: 0 Cycle of last refresh: 4

Source

The "0 violations" claim is grounded in the structural facts captured by the cycle-1-close snapshot (_docs/06_metrics/structure_2026-05-20.md):

Fact	Value
Inventory entries	15 (14 production components C1–C13 + 1 cross-cutting helpers/runtime_root row)
Import cycles in component graph	0 (verified across batches 88–92 cumulative reviews; no back-edges)
Contract files	5 (fdr_record_schema.md, fdr_client_protocol.md, log_record_schema.md, the shared_satellite_provider_ingest/ placeholder, shared_flights_api/)
_STRATEGY_REGISTRY composition seam	runtime_root.airborne_bootstrap + runtime_root.operator_bootstrap (single composition root per binary, ADR-009)
Layering rule	Layer-3 → Layer-4 imports BANNED; AZ-507 cross-component contract surface enforced by tests/unit/test_az270_compose_root.test_ac6_only_compose_root_imports_concrete_strategies lint

The architecture is documented in _docs/02_document/architecture.md (ADR-001 monolith, ADR-002 build-time exclusion, ADR-009 interface-first DI, ADR-011 single-image live+replay). File ownership is documented in _docs/02_document/module-layout.md.

Violations

None at baseline.

This section is the append target for every cumulative-review run that detects an architecture finding (severity ≥ Medium, category = Architecture). The append schema is documented under § Update Protocol below.

Update Protocol

When a cumulative review finds a NEW architecture violation

The reviewing skill (typically .cursor/skills/code-review/SKILL.md Phase 7, invoked from the implement skill's Step 14.5 cumulative review at every K=3 batches) MUST append a row to § Violations using this schema:

Field	Example
Finding ID	arch-2026-06-15-1 (date + sequence within the day)
Batch range	batches 17–19 cycle 4
Severity	High / Medium (Critical findings escalate immediately; Low findings stay in the per-batch report)
Subcategory	import-cycle / cross-component-import / parallel-pipeline / layer-violation / seam-bypass
File:line	src/gps_denied_onboard/components/c2_vpr/ultra_vpr.py:117
One-line summary	c2_vpr imports c6_tile_cache directly, bypassing the consumer-side Protocol cut required by AZ-507
Cumulative-review report	_docs/03_implementation/cumulative_review_batches_17-19_cycle4_report.md
Status	OPEN (newly introduced)

The append happens IN THIS FILE, not in the cumulative-review report. The cumulative-review report references this file's row by Finding ID.

When a violation is resolved

Update the violating row in place: change Status: OPEN to Status: RESOLVED in batch <N> cycle <M> via <commit-hash>. Do NOT delete the row — the audit trail must show both the introduction and the resolution.

When the structural snapshot is refreshed

Any cycle that materially changes structure — new component, new cross-component edge, new contract file, new composition root — re-snapshots to a fresh _docs/06_metrics/structure_<YYYY-MM-DD>.md (the cycle-end retrospective triggers this when the diff is non-trivial). When that happens:

1. Update the **Source-of-truth snapshot** header pointer at the top of this file to the new file.
2. Update the Cycle of last refresh header to the cycle that produced the new snapshot.
3. Update the § Source table values (component count, cycle count, contract count) to match the new snapshot.
4. Do NOT clear § Violations — open findings carry across snapshots. Resolution status is per-finding, not per-snapshot.

The refresh script is the same one that produced structure_2026-05-20.md (approach: count src/gps_denied_onboard/components/*/ directories + src/gps_denied_onboard/runtime_root/ + helpers/; run the AZ-270 composition-root lint to detect cycles; enumerate _docs/02_document/contracts/ subdirectories). If the script has been extracted into tools/structure_snapshot.py between cycles, use it; otherwise the manual approach is documented at the top of the source snapshot file.

Baseline Delta — how cumulative-review reports consume this file

Every cumulative-review report MUST emit a ## Baseline Delta section with three counts derived from this file:

• Carried-over: count of rows whose Status: OPEN (or Status: ACCEPTED-RISK) was unchanged at the start of this review's batch window.
• Resolved: count of rows that transitioned from OPEN to RESOLVED in batch ... during this review's batch window.
• Newly-introduced: count of rows added during this review's batch window.

An empty Baseline Delta (0 new, 0 resolved, 0 carried-over) is still emitted — its presence confirms the cumulative-review consulted the baseline rather than silently skipping the section as in cycles 1–3.

References

• Cycle-3 retro § Top 3 Improvement Actions #3 — _docs/06_metrics/retro_2026-05-26.md
• Cycle-1 retro § Top 3 Improvement Actions #3 (original) — _docs/06_metrics/retro_2026-05-20.md
• Source snapshot — _docs/06_metrics/structure_2026-05-20.md
• Existing-code flow Step 2 — .cursor/skills/autodev/flows/existing-code.md § "Step 2 — Architecture Baseline Scan"
• Implement skill Step 14.5 — .cursor/skills/implement/SKILL.md § "Cumulative Code Review (every K batches)"
• Architecture doc — _docs/02_document/architecture.md
• Module-layout — _docs/02_document/module-layout.md