[autodev] Update configuration and documentation for cycle-1

- Enhanced `.env.example` with detailed CMake build flags and replay-mode strategy flags for development and CI environments.
- Updated `.gitignore` to include a new deploy rollback bookmark.
- Revised `_docs/_autodev_state.md` to reflect the current task status and steps.
- Added new lessons to `_docs/LESSONS.md` regarding testing and architectural improvements.
- Documented changes in `_docs/02_document/deployment/ci_cd_pipeline.md` to reflect the relaxed OpenCV version pin.
- Updated test data documentation in `_docs/02_document/tests/test-data.md` to clarify fixture usage and paths.

This commit continues the cycle-1 documentation sync and addresses various configuration updates for improved clarity and functionality.

_docs/LESSONS.md

@@ -2,8 +2,34 @@
 
 Append-only ledger of lessons learned during the project. New entries go at the **top**. Each entry is one short bullet + a one-sentence "what changed".
 
+Ring buffer: trim to the last 15 entries. Categories: `estimation · architecture · testing · dependencies · tooling · process`.
+
 ---
 
+## 2026-05-20 — [process] Before classifying a per-task FAIL, probe cross-cutting state the task depends on (registries, factories, baselines)
+
+**Trigger**: cycle-1 Step 7 Product Implementation Completeness Gate originally classified AZ-332 + AZ-333 as FAIL and proposed two per-strategy remediation tasks (AZ-589 + AZ-590). Post-mortem found the actual gap was the empty central `_STRATEGY_REGISTRY` — a cross-cutting concern that should have produced **one** task (AZ-591), not two. AZ-589 + AZ-590 closed Won't Fix.
+
+**What changed**: completeness gates should now run a workspace grep for cross-cutting registry / factory state the task depends on before classifying a per-task FAIL. If the actual root cause is cross-cutting, propose a single cross-cutting task instead of N per-task remediation tasks. Captured in `_docs/06_metrics/retro_2026-05-20.md` § Suggested Rule/Skill Updates.
+
+Source: `_docs/06_metrics/retro_2026-05-20.md`
+
+## 2026-05-20 — [testing] If N test specs share a single un-built fixture, schedule the fixture builder as a P0 prerequisite during decompose
+
+**Trigger**: cycle-1 ended with 17 NFT scenarios `sitl_replay_ready`-skipping on the Tier-1 docker harness because AZ-595 (SITL observer + FDR replay fixture builder) was decomposed as a peer task and slipped to the end of the cycle. Cumulative review window 88-92 surfaced this as a 5 cp PBI that now blocks the cycle-2 Step 11 retry.
+
+**What changed**: `decompose/SKILL.md` should identify the fixture-builder dependency surface explicitly during test-task decomposition. If N test tasks share one un-built fixture, the fixture builder is a P0 prerequisite and is scheduled ahead of the dependent tasks, not as a peer. Captured in `_docs/06_metrics/retro_2026-05-20.md` § Suggested Rule/Skill Updates.
+
+Source: `_docs/06_metrics/retro_2026-05-20.md`
+
+## 2026-05-20 — [architecture] Land `_docs/02_document/architecture_compliance_baseline.md` as a Step 6 (Decompose) prerequisite so cumulative reviews can emit Baseline Delta sections
+
+**Trigger**: every cumulative review across cycle 1 logged "`_docs/02_document/architecture_compliance_baseline.md` does NOT exist → no Baseline Delta section emitted". Structural regressions (new cycles in the import graph, newly-introduced architecture violations) therefore could not be quantified across cycle 1 — only verified pairwise per batch.
+
+**What changed**: cycle 2 Step 6 (Decompose) should create the baseline file with `0` violations seeded from the structural snapshot at `_docs/06_metrics/structure_2026-05-20.md`. From cycle 2 onward, `## Baseline Delta` rows quantify carried-over / resolved / newly-introduced violations per cycle. Captured in `_docs/06_metrics/retro_2026-05-20.md` § Top 3 Improvement Actions #3.
+
+Source: `_docs/06_metrics/retro_2026-05-20.md`
+
 ## 2026-05-18 — When autodev rewinds N → 7 (or any earlier step) mid-session, treat the handoff as a session boundary
 
 **Trigger**: In Step 11 (Run Tests) cycle 1, the Jetson e2e gate routed the flow back to Step 7 (Implement) for AZ-618 (cross-cutting 5pt task with 12 infrastructure deps). The user repeatedly chose to continue in the same conversation. I rewound state cleanly (task spec + autodev state) but, on attempting to enter the implement skill's batch loop in the SAME conversation, found that even just investigating the 12 builder signatures consumed enough context to reach the Caution zone — writing the implementation would have hit truncation mid-batch.