[autodev] Step 13 partial: c10/c11/c12/c13 cycle-1 doc sync

Batch 4 of the cycle-1 component-doc sync. For each of C10
(provisioning), C11 (tilemanager), C12 (operator_orchestrator),
and C13 (fdr):

- Append "Cycle-1 operational reality" paragraph to § 1
  documenting the actual cycle-1 wiring path:
  - C10: operator-side / cross-tier; NOT in _STRATEGY_REGISTRY;
    composed via runtime_root/c10_factory.py with six per-service
    factories; reuses C7 InferenceRuntime for engine compile;
    AZ-323 Ed25519 signer + C10ManifestConfig signing-mode gate;
    AZ-324 ManifestVerifierImpl with airborne/operator modes;
    AZ-507 c6 cuts kept in c10_factory; AZ-687 N/A.
  - C11: operator-workstation-only; airborne build target
    excludes source tree (ADR-004 / AC-8.4); composed via
    runtime_root/c11_factory.py with three per-service factories;
    distinct FdrClient producer_ids for signing_key + tile_uploader;
    AZ-320 IdempotentRetryTileUploader wraps by default;
    AZ-507 keeps c6 surfaces caller-injected; AZ-687 N/A.
  - C12: operator-workstation CLI binary; airborne build excludes
    source tree (ADR-004 + Principle #9); composed via
    runtime_root/c12_factory.py; OperatorOrchestratorServices
    dataclass aggregates AZ-326/327/328/329/330/489 services with
    sibling fields defaulting to None; AZ-507 cuts via
    RemoteCacheProvisionerInvoker + TileDownloaderCut/UploaderCut;
    AZ-687 N/A.
  - C13: airborne infrastructure; pre_constructed[c13_fdr] seeded
    FIRST via make_fdr_client(AIRBORNE_MAIN_PRODUCER_ID, config)
    (AZ-619 Phase A); per-producer _CACHE gives AC-619.2 singleton;
    AZ-274 drop-oldest overrun policy wired at construction;
    c1_vio / c5_state require it, c2_5/c3/c3_5/c4 optional; AZ-687
    guard explicitly does NOT apply — seed runs before any block
    presence check so replay binaries still write FDR.

Also bump _docs/_process_leftovers/2026-05-11_d_cross_cve_1_opencv_pin_deferred.md
replay timestamp to 17:18 (start of this /autodev invocation);
gtsam==4.2.1 still requires numpy<2.0.0 so the relaxed opencv pin
remains in effect.

Update _docs/_autodev_state.md sub_step.detail to record batch
4/~5 done; next batch is the 8 helpers under common-helpers/.

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

_docs/02_document/components/11_c10_provisioning/description.md

@@ -8,6 +8,8 @@
 
 **Architectural Pattern**: Coordinator — single concrete implementation `CacheProvisioner` behind two interfaces (`CacheProvisioner` for the F1 build phase, `ManifestVerifier` for F2's content-hash gate). The interfaces are split because F2 only needs the verifier and shouldn't pull in the full provisioning code path.
 
+**Cycle-1 operational reality**: C10 is **operator-side / cross-tier infrastructure**, NOT an airborne strategy slot — it does not appear in `_AIRBORNE_REGISTRATIONS` and `register_airborne_strategies()` (AZ-591) never registers it; equivalently it has no row in `AIRBORNE_REQUIRED_PRE_CONSTRUCTED_KEYS`. The operator binary composes C10 via `runtime_root/c10_factory.py`, which exposes six tiny per-service factories (`build_engine_compiler`, `build_backbone_specs`, `build_manifest_builder`, `build_manifest_verifier`, `build_descriptor_batcher`, `build_cache_provisioner`) that the CLI wires directly. The factory reuses the C7 `InferenceRuntime` via `inference_factory.build_inference_runtime` for the engine-compile path (honouring `BUILD_TENSORRT_RUNTIME` / `BUILD_PYTORCH_FP16_RUNTIME`) and threads `Sha256Sidecar`, `Ed25519ManifestSigner`, and a structured logger explicitly — no global registry. The AZ-323 `ManifestBuilder` reads `config.components['c10_provisioning'].manifest` (`C10ManifestConfig`: `signing_mode ∈ {operator, dev}`, `allowed_operator_fingerprints`, `schema_version="1.1"`); operator-mode signs only with an allowlisted Ed25519 key fingerprint, dev-mode warns when an allowlisted key is used. AZ-324's `ManifestVerifierImpl` has two modes selected by `with_tile_store`: `False` (airborne C5 path, MV-INV-5: trust the Ed25519 signature + recorded `tiles_coverage_sha256`) and `True` (operator C12 path: re-derive the aggregate from C6 and report drift) — wired in `build_manifest_verifier` and never silently flipping. The AZ-507 cross-component cut keeps C10 from importing C6 directly: `c10_factory.py` owns three composition-root adapters (`c6_tile_metadata_store_to_tiles_query`, `c6_tile_store_to_pixel_opener`, `c6_descriptor_index_to_rebuilder`) that translate C6's DTOs into C10's narrow `TileHashRecord` / `TileBboxRecord` / `TilePixelOpener` / `DescriptorIndexRebuilder` cuts. AZ-687 replay-mode guard does not apply to C10 — replay-mode binaries are airborne-only and never invoke the C10 build path.
+
 **Upstream dependencies**:
 
 - C12 OperatorTooling → triggers `build_cache_artifacts(...)` after C11 `TileDownloader` has populated C6.

_docs/02_document/components/12_c11_tilemanager/description.md

@@ -11,6 +11,8 @@ C11 is a **separate operator-side binary / image**. The airborne companion image
 
 **Architectural Pattern**: Pipeline behind two interfaces (`TileDownloader`, `TileUploader`) under one component, consistent with C8's multi-interface shape (FC-AP, FC-iNav, GCS adapters under one component). The two interfaces are bundled into C11 because they share auth (TLS + service-internal API key for download, per-flight onboard signing key for upload), HTTP client, network configuration, deployment unit (operator-tooling tarball), and the airborne-exclusion property — splitting them into two components would duplicate all of that. They are kept as **two interfaces** so SRP is preserved at the call-site level: C12 binds `TileDownloader` for the F1 cache-build workflow, `TileUploader` for the F10 post-landing trigger; neither is forced to depend on the other.
 
+**Cycle-1 operational reality**: C11 is **operator-workstation-only**, NOT an airborne strategy slot — there is no `c11_tile_manager` slot in `_AIRBORNE_REGISTRATIONS`, no row in `AIRBORNE_REQUIRED_PRE_CONSTRUCTED_KEYS`, and the airborne companion image's build target deliberately excludes the entire `c11_tile_manager/` source tree (ADR-004 process-level isolation; AC-8.4). The operator binary composes C11 via `runtime_root/c11_factory.py`, which exposes three tiny per-service factories — `build_per_flight_key_manager` (AZ-318), `build_tile_uploader` (AZ-319 + AZ-320), and `build_tile_downloader` (AZ-316) — each called explicitly by C12's CLI; no central registry. FDR wiring goes through the per-producer `make_fdr_client` cache: AZ-318 `PerFlightKeyManager` defaults to `make_fdr_client("c11_tile_manager.signing_key", config)`, AZ-319 `HttpTileUploader` to `make_fdr_client("c11_tile_manager.tile_uploader", config)` — both distinct from the airborne `"airborne_main"` producer, so the operator-workstation process gets its own per-component FdrClient instances rather than sharing the airborne singleton. AZ-320's `IdempotentRetryTileUploader` decorator wraps `HttpTileUploader` by default (per-call + per-tile bounded retry); `config.components['c11_tile_manager'].disable_retry_decorator = True` suppresses the wrap for low-level debugging or test wiring that needs to observe the inner uploader. The AZ-507 cross-component cut keeps C11 from importing C6 directly: `tile_store` / `tile_metadata_store` are passed in by the operator-binary composition root as consumer-side cuts; `http_client` (an `httpx.Client`) is also caller-owned so tests can swap in `httpx.MockTransport`. AZ-687 replay-mode guard does not apply — C11 has no airborne footprint.
+
 **Upstream dependencies**:
 
 - C12 OperatorTooling → invokes `TileDownloader.download_tiles_for_area(...)` during F1 and `TileUploader.upload_pending_tiles(...)` post-landing.

_docs/02_document/components/13_c12_operator_orchestrator/description.md

@@ -6,6 +6,8 @@
 
 **Architectural Pattern**: Coordinator (single concrete `OperatorTooling` today). Three interfaces: `CacheBuildWorkflow` (pre-flight UX), `FlightsApiClient` (read the operator-authored `Flight` from the parent-suite `flights` REST service or a local JSON export — AZ-489, ADR-010), and `OperatorReLocService` (mid-flight operator re-loc requests, AC-3.4). `OperatorReLocService` is consumed via the GCS link by C8 (operator commands subscription); `FlightsApiClient` is operator-workstation-only and never reaches the airborne companion (Principle #9).
 
+**Cycle-1 operational reality**: C12 is the **operator-workstation CLI** — a standalone binary with `__main__.py` / `cli.py` entry points, NOT an airborne strategy slot. There is no `c12_operator_orchestrator` slot in `_AIRBORNE_REGISTRATIONS`, no row in `AIRBORNE_REQUIRED_PRE_CONSTRUCTED_KEYS`, and the airborne companion image's build target deliberately excludes the entire `c12_operator_orchestrator/` source tree (ADR-004 + Principle #9 process-level isolation). The CLI composes its dependencies via `runtime_root/c12_factory.py`, which exposes one builder per service and aggregates them into the immutable `OperatorOrchestratorServices` dataclass: `build_flights_api_client` (AZ-489, returns `HttpxFlightsApiClient` with TLS verify ON), `build_sector_classification_store` (AZ-326), `build_companion_bringup` (AZ-327, paramiko-based SSH with `ParamikoSshSessionFactory` + `RemoteSidecarVerifier`), `build_build_cache_orchestrator` (AZ-328, wraps `FilelockFileLockFactory` + `RemoteCacheProvisionerInvoker` + a c11 `TileDownloaderCut` adapter), `build_post_landing_upload_orchestrator` (AZ-329, reads `LocalFdrFooterReader` and gates on `clean_shutdown=True` before invoking C11's `TileUploader`), and `build_operator_reloc_service` (AZ-330, the GCS-side `OperatorCommandTransport` producer). The `build_cache_orchestrator`, `post_landing_upload_orchestrator`, and `operator_reloc_service` fields default to `None` so CLI subcommands that don't need them short-circuit with `EXIT_OK` rather than fail — keeping AZ-326 / AZ-327 unit tests stable as later sibling tasks added service fields in-place. The AZ-507 cross-component cut keeps C12 from importing C10 or C11 directly: `RemoteCacheProvisionerInvoker` calls C10 over SSH, and `TileDownloaderCut` / `TileUploaderCut` adapters translate c11's real `DownloadRequest` / `UploadBatchReport` DTOs to the local cut DTOs the orchestrator consumes. AZ-687 replay-mode guard does not apply — C12 has no airborne footprint.
+
 **Upstream dependencies**:
 - Operator (human input — flight ID or flight file path, sector classification, calibration path).
 - `flights` REST service (parent-suite `suite/flights/`) — read via `FlightsApiClient` to fetch the operator-authored `Flight` (waypoints + altitudes); offline alternative is a local JSON export in the same DTO shape.

_docs/02_document/components/14_c13_fdr/description.md

@@ -6,6 +6,8 @@
 
 **Architectural Pattern**: single concrete `FileFdrWriter` behind a `FdrWriter` interface. Single writer thread fed by lock-free in-process queues from every component. Lossy on writer-thread overrun **only by logging the rollover event**, never silently.
 
+**Cycle-1 operational reality**: C13 is **airborne infrastructure** seeded as the very first slot of `build_pre_constructed` — `constructed["c13_fdr"] = make_fdr_client(AIRBORNE_MAIN_PRODUCER_ID, config)` (AZ-619 Phase A, where `AIRBORNE_MAIN_PRODUCER_ID = "airborne_main"`). The `make_fdr_client(producer_id, config)` factory in `fdr_client/client.py` carries a process-level `_CACHE` keyed by `producer_id`, so any later `make_fdr_client("airborne_main", config)` call in the same process returns the SAME `FdrClient` instance — that's the AC-619.2 cross-component singleton guarantee. Per-component callers can also obtain their OWN per-producer FdrClient via `make_fdr_client("<their_slug>", config)`: C11 uses `"c11_tile_manager.signing_key"` (AZ-318) and `"c11_tile_manager.tile_uploader"` (AZ-319), C6's `freshness_gate.py` uses its own producer, etc. — each entry in the cache is a distinct `SpscRingBuffer` consumer side. Per-producer capacity comes from `config.fdr.per_producer_capacity[producer_id]` (override) or `config.fdr.queue_size` (default), rounded UP to the next power of two and clipped to `MIN_CAPACITY`. The drop-oldest overrun policy (AZ-274 `default_overrun_policy`) is wired automatically at `FdrClient` construction time; AZ-274 also routes the dropped record through the `on_overrun` hook so the rollover-log event is emitted exactly once per overrun, never silently. Required-key relationship: `c1_vio` and `c5_state` list `c13_fdr` in `AIRBORNE_REQUIRED_PRE_CONSTRUCTED_KEYS` (missing raises `AirborneBootstrapError`); `c2_5_rerank`, `c3_matcher`, `c3_5_adhop`, and `c4_pose` read it via `constructed.get("c13_fdr")` (optional — silently passes `None` to the wrapper, which is the documented contract for "FDR off" test fixtures). AZ-687 replay-mode guard does NOT apply to C13: the slot is seeded unconditionally before any `_replay_omits_component_block(...)` check — a replay binary still writes FDR (TlogDerivedClock-stamped) so post-flight analysis tools can drain the queue.
+
 **Upstream dependencies**: every component publishes to C13 via in-process pub/sub (drop-oldest-with-rollover-log on overrun).
 
 **Downstream consumers**:

_docs/_autodev_state.md

@@ -8,7 +8,7 @@ status: in_progress
 sub_step:
   phase: 8
   name: component-doc-updates
-  detail: "batch 3/~5 done (c6/c7/c8); next: c10/c11/c12/c13; then 8 helpers; then tests/"
+  detail: "batch 4/~5 done (c10/c11/c12/c13); next: 8 helpers; then tests/"
 retry_count: 0
 cycle: 1
 tracker: jira

_docs/_process_leftovers/2026-05-11_d_cross_cve_1_opencv_pin_deferred.md

@@ -1,10 +1,10 @@
 # D-CROSS-CVE-1 opencv-python pin deferred — gtsam/numpy ABI block
 
 **Recorded**: 2026-05-11T02:55+03:00 (Europe/Kyiv)
-**Last replay attempt**: 2026-05-19T17:13+03:00 (Europe/Kyiv) — replay attempted
+**Last replay attempt**: 2026-05-19T17:18+03:00 (Europe/Kyiv) — replay re-checked
-during `/autodev` invocation; `gtsam==4.2.1` still latest on PyPI with
+at start of next `/autodev` invocation (5 min after prior check). `gtsam==4.2.1`
-`requires_dist: numpy<2.0.0,>=1.11.0`. Replay condition (numpy>=2 stable
+still latest on PyPI with `requires_dist: numpy<2.0.0,>=1.11.0`. Replay
-wheels) still NOT met. Leftover remains open.
+condition (numpy>=2 stable wheels) still NOT met. Leftover remains open.
 **Status**: deferred-non-user (replay when upstream gtsam wheels target numpy>=2)
 
 ## What is blocked