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.

_docs/00_problem/acceptance_criteria.md

@@ -2,6 +2,7 @@
 
 > Last revised 2026-05-07 (cleanup pass: stripped algorithm/library/parameter implementation details; renamed source label `vo_extrapolated` → `visual_propagated`; broadened FC scope to ArduPilot + iNav).
 > Subsequent revision 2026-05-07 (post-SQ6 research): AC-4.3 reworded to acknowledge that no single message type is accepted by both ArduPilot Plane and iNav — per-FC interface is named explicitly (MAVLink `GPS_INPUT` for ArduPilot Plane, MSP2 `MSP2_SENSOR_GPS` for iNav). Rationale and L1 sources in `_docs/00_research/02_fact_cards/SQ6_fc_external_positioning.md` / `_docs/00_research/01_source_registry/SQ6_external_positioning.md` Sources #4, #9, #10, #12, #13.
+> Subsequent revision 2026-05-09 (Plan Phase 2a.0 outcomes): AC-NEW-4 and AC-NEW-7 validation requirements relaxed from "≥100 flights" literal to Monte-Carlo-with-stated-CI over currently-available data corpus; multi-flight statistical headroom moved to Step 4 risk register (D-PROJ-3). AC-8.4 augmented with explicit in-air-no-upload security gate (flight-state process-level isolation; post-landing upload tool); local mid-flight tile format pinned to match `satellite-provider`'s on-disk format. AC-NEW-7 external-dependency note revised: parent-suite voting layer is not currently implemented; tracked as parent-suite design task D-PROJ-2.
 > See git history for prior versions.
 
 ## Position Accuracy
@@ -53,7 +54,7 @@
 - **AC-8.1** — Imagery via Azaion Suite Satellite Service (offline cache interface; no direct commercial-provider calls). Cache-interface resolution ≥0.5 m/px, ideally 0.3 m/px.
 - **AC-8.2** — Tile freshness: <6 mo (active-conflict sectors), <12 mo (stable rear). Older → reject or downgrade (AC-NEW-6).
 - **AC-8.3** — Imagery pre-loaded onto companion before flight; offline preprocessing time not time-critical. Pre-extracted descriptors/indices count against the cache budget unless explicitly carved out.
-- **AC-8.4** — Mid-flight tile generation: continuously orthorectify nav-camera frames into basemap-projected tiles, deduplicated (latest/highest-quality wins). Upload to Service on landing. Each uploaded tile carries quality metadata sufficient for the Service's ingest pipeline (AC-NEW-7).
+- **AC-8.4** — Mid-flight tile generation: continuously orthorectify nav-camera frames into basemap-projected tiles, deduplicated (latest/highest-quality wins). Tiles are written **only** to the local cache while airborne — in-air outbound writes to `satellite-provider` are **forbidden** for drone-security reasons; enforced by a `flight state` process-level gate (see `architecture.md`). Upload to `satellite-provider` happens **only after landing**, triggered by a separate operator-side post-landing upload tool. Local mid-flight tile format matches `satellite-provider`'s on-disk format so post-landing upload is byte-identical. Each uploaded tile carries quality metadata sufficient for the Service's ingest pipeline (AC-NEW-7).
 - **AC-8.5** — No raw nav-camera or AI-camera frames retained in normal operation; tiles are the only persistent imagery. Forensic exception: ≤0.1 Hz thumbnail log of frames that failed tile generation, within FDR budget (AC-NEW-3).
 - **AC-8.6 — Satellite-anchor relocalization robustness**:
   - **Scale-ratio**: any UAV-frame ground footprint at the deployment altitude band must be retrievable from the cache regardless of internal tiling/indexing.
@@ -80,7 +81,7 @@
 ### AC-NEW-4 — False-position safety budget
 **Statement.** Per flight: **P(error >500 m) <0.1 %**, **P(error >1 km) <0.01 %**.
 **Why.** A single 1-km-off frame can fly the UAV outside the geofence; covariance carried in the MAVLink message is the FC's only defense.
-**Validation.** Monte Carlo over a public aerial-localization dataset (e.g. AerialVL S03) + own recorded flights; report error CDF; pass = both probabilities below budget across ≥100 flights.
+**Validation.** Monte Carlo over the currently-available data corpus (Derkachi flight + 60 stills + synthetic perturbations); report error CDF with stated 95% confidence interval; pass = both probabilities below budget within the CI's lower bound. Multi-flight statistical headroom (originally framed as ≥100 flights) is residual risk tracked in the Step 4 risk register; **D-PROJ-3** reopens this validation when additional multi-flight data becomes available.
 
 ### AC-NEW-5 — Operational environmental envelope
 **Statement.** Operating temp **−20 °C to +50 °C**; vibration/shock per RTCA DO-160G low-altitude UAV-class. Cooling sustains **25 W** at the upper temp for the full **8-hour duty cycle** without throttling.
@@ -94,9 +95,9 @@
 
 ### AC-NEW-7 — Cache-poisoning safety budget
 **Statement.** Per flight, across all onboard tiles written (AC-8.4): **P(geo-misalign >30 m) <1 %**, **P(>100 m) <0.1 %**.
-**Why.** Onboard tiles feed back into the Service basemap (AC-8.4). A bad onboard pose with optimistic covariance writes a misaligned tile that becomes the next flight's anchor — cross-flight error compounding that AC-NEW-4 doesn't capture.
-**External-dependency note.** The Suite Satellite Service is expected to operate a multi-flight ingest-side voting layer that gates onboard-tile promotion to "trusted basemap" until multiple independent flights agree on geo-alignment. Voting algorithm is the Service's concern; onboard's job (AC-8.4) is to publish per-tile quality metadata sufficient for that layer. End-to-end AC-NEW-7 evidence depends on this Service contract.
-**Validation.** Multi-flight Monte Carlo replay over public datasets (e.g. AerialVL, AerialExtreMatch) + own flights, with synthetic over-confidence injection (deflate covariance ×1.5–3): assert both probabilities below budget across ≥100 flights. Independently exercise the Service-side voting contract.
+**Why.** Onboard tiles feed back into the `satellite-provider` basemap when uploaded post-landing (AC-8.4). A bad onboard pose with optimistic covariance writes a misaligned tile that becomes the next flight's anchor — cross-flight error compounding that AC-NEW-4 doesn't capture.
+**External-dependency note.** The parent-suite `satellite-provider` is expected to operate a multi-flight ingest-side trust/voting layer that gates onboard-tile promotion to "trusted basemap" until multiple independent flights agree on geo-alignment. The ingest endpoint and voting layer are **not currently implemented in `satellite-provider`** and are tracked as a parent-suite design task (**D-PROJ-2**). Onboard's job (AC-8.4) is to publish per-tile quality metadata sufficient for that layer. End-to-end AC-NEW-7 evidence depends on the `satellite-provider` contract being added.
+**Validation.** Onboard-only Monte Carlo replay over the currently-available data corpus + synthetic over-confidence injection (deflate covariance ×1.5–3); report error CDF with stated 95% confidence interval; pass = both probabilities below budget within the CI's lower bound for the onboard-side contribution. Multi-flight statistical headroom and the `satellite-provider` voting-side contract verification are residual risks tracked in the Step 4 risk register; **D-PROJ-3** reopens onboard validation when additional multi-flight data becomes available; **D-PROJ-2** reopens cross-suite validation once the ingest + voting layer is built.
 
 ### AC-NEW-8 — Visual blackout + GPS spoofing degraded mode
 **Statement.** When the navigation camera is fully unusable AND FC reports GPS denial/spoof: