[autodev] Step 13 partial: system-level cycle-1 doc sync

Updates _docs/02_document/ to capture the highest-leverage
cycle-1 deltas after 97 implementation batches:

- FINAL_report.md: revise Decision 9 to reflect the actual
  opencv-python pin (>=4.11.0.86,<4.12; D-CROSS-CVE-1
  deferred per leftover); new "Cycle 1 Implementation Status"
  section documents the _STRATEGY_REGISTRY + pre_constructed
  composition-root additions (AZ-591, AZ-618/AZ-619..AZ-624),
  AZ-332 + AZ-333 BLOCKED with parked Tier-2 follow-ups
  AZ-592 + AZ-593, AZ-589 + AZ-590 closed Won't-Fix, Step 11
  Run Tests results (3343 passed / 88 skipped / 0 failed
  local; Docker harness rehab tracked by AZ-602), and the
  deferred-reconciliation list.
- glossary.md: 5 new cycle-1 entries (_STRATEGY_REGISTRY,
  airborne_bootstrap, KltRansac as production-default Tier-1
  VIO, pre_constructed kwarg, Tier-1 task / Tier-2 task
  capability classification). Status line notes the cycle-1
  additions pending re-confirmation.
- ripple_log_cycle1.md (new): explains why per-file
  enumeration is N/A for end-of-cycle-1 sync, lists the
  three doc-update levels and their effective scope, and
  records the recommended follow-up ordering for the
  deferred component / helper / contract / test passes.

Step 13 deferred: architecture.md, module-layout.md,
system-flows.md, 14 component description.md + tests.md,
8 helper docs, 18 contract subfolders, 7 test docs (~50+
files; ~80 product tasks + ~8 helper tasks + ~36 blackbox
test tasks). Filed in FINAL_report.md and
ripple_log_cycle1.md; resume in a fresh conversation per
the 2026-05-18 LESSONS.md guidance.

State: greenfield / Step 13 / in_progress / phase 5
(system-level-updates) / cycle 1.

Co-authored-by: Cursor <cursoragent@cursor.com>

_docs/02_document/glossary.md

@@ -1,13 +1,15 @@
 # Glossary
 
-**Status**: confirmed-by-user
-**Date**: 2026-05-09
+**Status**: confirmed-by-user (Plan baseline 2026-05-09); cycle-1 additions appended 2026-05-19 pending re-confirmation
+**Date**: 2026-05-09 baseline · 2026-05-19 cycle-1 additions (marked with `(source: cycle 1 as-built …)` in their entry)
 **Scope**: project-specific terminology for the GPS-denied onboard pose-estimation system. Generic software / industry terms (REST, JSON, IMU, WGS84, etc.) are intentionally omitted.
 
 Terms are alphabetical. Each entry: one-line definition + parenthetical source.
 
 ---
 
+**`_STRATEGY_REGISTRY`** — Module-level dict in `runtime_root` mapping `(component_slug, strategy_name) → factory`, with `tier` and `depends_on` metadata. Populated per-binary by an `<role>_bootstrap.register_<role>_strategies()` call before `compose_root()` runs; `compose_root()` raises `StrategyNotLinkedError` if a config-selected strategy is absent. Runtime-side complement to ADR-002 build-time exclusion: the build decides which strategies *can* be registered, the registry decides which one this binary *does* register. Filled cycle-1 by AZ-591; public API is `register_strategy(component_slug, strategy_name, factory, *, tier, depends_on)`. (source: cycle 1 as-built; AZ-591 task spec)
+
 **adti20** — Informal name for the production deployment camera, the **ADTi Surveyor Lite 20MP 20L V1** (APS-C ~23.6×15.7 mm, ~5472×3648 px, fixed downward, no gimbal). Pinned in `restrictions.md` §Cameras. (source: `restrictions.md`, user confirmation 2026-05-09)
 
 **adti26** — Informal name for the camera that captured the 60 still-image test fixtures (`AD000001..AD000060.jpg`) under `_docs/00_problem/input_data/`. Distinct from the production-deployed `adti20`; calibration data must be sourced from public/factory references for these test images. (source: user confirmation 2026-05-09)
@@ -18,6 +20,8 @@ Terms are alphabetical. Each entry: one-line definition + parenthetical source.
 
 **AI camera** — Operator-controlled gimbal+zoom camera consumed by AI detection systems; out of scope for nav-pose, in scope for AC-7.x object localization only. (source: `restrictions.md` §Cameras)
 
+**`airborne_bootstrap`** — Module under `runtime_root/` that performs the two pre-`compose_root()` setup steps for the airborne binary: `register_airborne_strategies()` populates `_STRATEGY_REGISTRY` with 7 component-strategy slots (c1_vio, c2_vpr, c2_5_rerank, c3_matcher, c3_5_adhop, c4_pose, c5_state), and `build_pre_constructed(config)` constructs the 12-key infrastructure dict (`pre_constructed`). The airborne entrypoint `runtime_root.main()` calls both before `compose_root(config, pre_constructed=...)`. Missing registry entry → `StrategyNotLinkedError`; missing `pre_constructed` key → `AirborneBootstrapError`. Operator binary uses the parallel `operator_bootstrap` module today only as a placeholder. (source: cycle 1 as-built; AZ-591 + AZ-618 umbrella → AZ-619..AZ-624 subtasks)
+
 **Camera calibration artifact** — JSON file carrying camera intrinsics + distortion + body-to-camera extrinsics + acquisition method (`factory_sheet | checkerboard_refined | hybrid`). The only way camera-specific parameters enter the system; no hard-coded camera math anywhere. Test fixtures and production deployments load different artifacts on the same code path. (source: user directive 2026-05-09)
 
 **Companion / Companion PC** — The onboard Jetson Orin Nano Super running the GPS-denied estimation pipeline. Synonyms used interchangeably across docs. (source: `restrictions.md` §Onboard Hardware)
@@ -56,6 +60,8 @@ Terms are alphabetical. Each entry: one-line definition + parenthetical source.
 
 **Jetson Orin Nano Super** — Pinned companion compute: 67 TOPS sparse INT8, 8 GB shared LPDDR5, 25 W TDP, JetPack/CUDA/TensorRT. (source: `restrictions.md`)
 
+**`KltRansac`** — Engine-rule-mandatory simple-baseline `VioStrategy` (AZ-334). In cycle 1 this is the **production-default** airborne VIO selection because OKVIS2 (AZ-332) and VINS-Mono (AZ-333) are BLOCKED on Tier-2 prerequisites (CI build env + Jetson hardware + DBoW2 vocab; upstream vendoring decision). The `_STRATEGY_REGISTRY` still registers all three slots — config-selecting OKVIS2 / VINS-Mono raises `StrategyNotAvailableError` from `vio_factory.py` until their `BUILD_*` flag is ON and the Tier-2 follow-ups (AZ-592, AZ-593) land. ADR-001 / ADR-002 unchanged; only the production default selection shifts. (source: cycle 1 as-built; `implementation_completeness_cycle1_report.md`)
+
 **Mid-flight bounded-delta GPS gate** — Third clause of Principle #11. Even when FC GPS health is "stable + non-spoofed for ≥ 10 s" and the visual/satellite consistency check has succeeded, the FC's reported position must be within ≤ 200 m (configurable) of the companion's last emitted `PoseEstimate` before the FC GPS is fused via `add_pose_anchor`. Catches "FC reports stable GPS but the value is wrong". (source: Principle #11 amended, ADR-010)
 
 **Mid-flight tile generation** — Companion orthorectifies nav-camera frames into basemap-projected tiles in flight, deduplicates, stores locally in `satellite-provider`-compatible format. NO outbound upload while airborne — upload happens post-landing only. (source: AC-8.4, user directive 2026-05-09)
@@ -70,6 +76,10 @@ Terms are alphabetical. Each entry: one-line definition + parenthetical source.
 
 **Operator** — Pre-flight and post-flight human role: authors the flight route in the **Mission Planner UI** (`suite/ui`), classifies the operational area (active-conflict vs stable rear), drives C12 cache provisioning (which reads the `Flight` from the parent-suite `flights` REST service, downloads satellite tiles via the **Tile Manager** for the route bbox, and bakes the takeoff origin into the C10 Manifest), stages calibration onto the companion before takeoff, and after landing triggers the **Tile Manager** upload run. (source: `problem.md`, AC-3.4 / AC-6.2, ADR-010, user confirmation 2026-05-09 + 2026-05-11)
 
+**`pre_constructed`** — Mandatory kwarg of `compose_root(config, pre_constructed=...)` carrying a 12-key dict of infrastructure objects (`c13_fdr`, `c6_descriptor_index`, `c6_tile_store`, `c7_inference`, `c3_lightglue_runtime`, `c3_feature_extractor`, `c282_ransac_filter`, `c5_wgs_converter`, `c5_se3_utils`, `c5_isam2_graph_handle`, `c5_imu_preintegrator`, `clock`). Built by `airborne_bootstrap.build_pre_constructed(config)` in 6 dependency-ordered phases (Phase A=c13/clock through Phase F=wire `main()`); GPU-touching builders gate on `BUILD_*` env flags. Tests stub by passing the same kwarg. Missing key → `AirborneBootstrapError`. (source: cycle 1 as-built; AZ-618 umbrella → AZ-619..AZ-624 subtasks)
+
+**Tier-1 task / Tier-2 task** — Capability-readiness classification distinct from the `Tier-1 / Tier-2` test-environment split. A **Tier-1 task** is the cycle deliverable; passes the implement skill's cycle-end Completeness Gate without external hardware/CI prerequisites. A **Tier-2 task** is a follow-up gated on prerequisites that are not provisioned in this cycle (e.g., DBoW2 vocab artifact for OKVIS2; Jetson runner for VINS-Mono pybind11 binding). Tier-2 follow-ups are parked in `_docs/02_tasks/backlog/` with the Tier-1 task's BLOCKED handle naming them explicitly. The implement skill's "PASS-with-BLOCKED" terminal classification permits a Tier-1 task to ship in BLOCKED state if a Tier-2 follow-up is named in its Implementation Notes. (source: cycle 1 as-built; `implementation_completeness_cycle1_report.md`)
+
 **Tile Manager** — Operator-side component (C11) that owns both directions of network I/O against `satellite-provider`: pre-flight download (F1) into the local C6 store via the `TileDownloader` interface, and post-landing upload (F10) from C6 to the parent-suite ingest endpoint via the `TileUploader` interface. Carries **no internal flight-state gating** (Batch 44 SRP refactor — the post-landing safety check lives in C12's `PostLandingUploadOrchestrator`, which reads the `flight_footer.clean_shutdown` field). Implemented as a separate binary / image so neither network path is loaded in the airborne companion (ADR-004 process-level isolation). Replaces the earlier "post-landing upload tool" naming after Plan-cycle scope expansion 2026-05-09. (source: user directive 2026-05-09; Batch 44 SRP refactor 2026-05-13)
 
 **`satellite-provider`** — First-class architecture boundary: the suite's existing .NET 8 REST microservice at `/Users/obezdienie001/dev/azaion/suite/satellite-provider/`. Runs in Docker (`:5100`, OpenAPI at `/swagger`); downloads Google Maps tiles; stores them in PostgreSQL + filesystem (`./tiles/{zoomLevel}/{x}/{y}.jpg`). Read-only from the onboard runtime; receives post-landing tile uploads via a yet-to-be-designed ingest endpoint (parent-suite work, D-PROJ-2). Synonym in older docs: "Suite Sat Service" / "Azaion Suite Satellite Service". (source: parent-suite `satellite-provider/README.md`, user confirmation 2026-05-09)