Sync .cursor from suite (autodev orchestrator + monorepo skills)

.cursor/skills/implement/SKILL.md

@@ -51,6 +51,13 @@ TASKS_DIR/
 1. `TASKS_DIR/todo/` exists and contains at least one task file — **STOP if missing**
 2. `_dependencies_table.md` exists — **STOP if missing**
 3. At least one task is not yet completed — **STOP if all done**
+4. **Working tree is clean** — run `git status --porcelain`; the output must be empty.
+   - If dirty, STOP and present the list of changed files to the user via the Choose format:
+     - A) Commit or stash stray changes manually, then re-invoke `/implement`
+     - B) Agent commits stray changes as a single `chore: WIP pre-implement` commit and proceeds
+     - C) Abort
+   - Rationale: implementer subagents edit files in parallel and commit per batch. Unrelated uncommitted changes get silently folded into batch commits otherwise.
+   - This check is repeated at the start of each batch iteration (see step 6 / step 14 Loop).
 
 ## Algorithm
 
@@ -77,11 +84,21 @@ TASKS_DIR/
 
 ### 4. Assign File Ownership
 
+The authoritative file-ownership map is `_docs/02_document/module-layout.md` (produced by the decompose skill's Step 1.5). Task specs are purely behavioral — they do NOT carry file paths. Derive ownership from the layout, not from the task spec's prose.
+
 For each task in the batch:
-- Parse the task spec's Component field and Scope section
-- Map the component to directories/files in the project
-- Determine: files OWNED (exclusive write), files READ-ONLY (shared interfaces, types), files FORBIDDEN (other agents' owned files)
-- If two tasks in the same batch would modify the same file, schedule them sequentially instead of in parallel
+- Read the task spec's **Component** field.
+- Look up the component in `_docs/02_document/module-layout.md` → Per-Component Mapping.
+- Set **OWNED** = the component's `Owns` glob (exclusive write for the duration of the batch).
+- Set **READ-ONLY** = Public API files of every component in the component's `Imports from` list, plus all `shared/*` Public API files.
+- Set **FORBIDDEN** = every other component's `Owns` glob, and every other component's internal (non-Public API) files.
+- If the task is a shared / cross-cutting task (lives under `shared/*`), OWNED = that shared directory; READ-ONLY = nothing; FORBIDDEN = every component directory.
+- If two tasks in the same batch map to the same component or overlapping `Owns` globs, schedule them sequentially instead of in parallel.
+
+If `_docs/02_document/module-layout.md` is missing or the component is not found:
+- STOP the batch.
+- Instruct the user to run `/decompose` Step 1.5 or to manually add the component entry to `module-layout.md`.
+- Do NOT guess file paths from the task spec — that is exactly the drift this file exists to prevent.
 
 ### 5. Update Tracker Status → In Progress
 
@@ -89,6 +106,8 @@ For each task in the batch, transition its ticket status to **In Progress** via
 
 ### 6. Launch Implementer Subagents
 
+**Per-batch dirty-tree re-check**: before launching subagents, run `git status --porcelain`. On the first batch this is guaranteed clean by the prerequisite check. On subsequent batches, the previous batch ended with a commit so the tree should still be clean. If the tree is dirty at this point, STOP and surface the dirty files to the user using the same A/B/C choice as the prerequisite check. The most likely causes are a failed commit in the previous batch, a user who edited files mid-loop, or a pre-commit hook that re-wrote files and was not captured.
+
 For each task in the batch, launch an `implementer` subagent with:
 - Path to the task spec file
 - List of files OWNED (exclusive write access)
@@ -142,11 +161,12 @@ Bounded auto-fix loop — only applies to **mechanical** findings. Critical and
 |----------|----------|-----------|
 | Low | any | yes |
 | Medium | Style, Maintainability, Performance | yes |
-| Medium | Bug, Spec-Gap, Security | escalate |
+| Medium | Bug, Spec-Gap, Security, Architecture | escalate |
 | High | Style, Scope | yes |
-| High | Bug, Spec-Gap, Performance, Maintainability | escalate |
+| High | Bug, Spec-Gap, Performance, Maintainability, Architecture | escalate |
 | Critical | any | escalate |
 | any | Security | escalate |
+| any | Architecture (cyclic deps) | escalate |
 
 Flow:
 
@@ -179,6 +199,23 @@ Move each completed task file from `TASKS_DIR/todo/` to `TASKS_DIR/done/`.
 
 - Go back to step 2 until all tasks in `todo/` are done
 
+### 14.5. Cumulative Code Review (every K batches)
+
+- **Trigger**: every K completed batches (default `K = 3`; configurable per run via a `cumulative_review_interval` knob in the invocation context)
+- **Purpose**: per-batch review (Step 9) catches batch-local issues; cumulative review catches issues that only appear when tasks are combined — architecture drift, cross-task inconsistency, duplicate symbols introduced across different batches, contracts that drifted across producer/consumer batches
+- **Scope**: the union of files changed since the **last** cumulative review (or since the start of the run if this is the first)
+- **Action**: invoke `.cursor/skills/code-review/SKILL.md` in **cumulative mode**. All 7 phases run, with emphasis on Phase 6 (Cross-Task Consistency), Phase 7 (Architecture Compliance), and duplicate-symbol detection across the accumulated code
+- **Output**: write the report to `_docs/03_implementation/cumulative_review_batches_[NN-MM]_cycle[N]_report.md` where `[NN-MM]` is the batch range covered and `[N]` is the current `state.cycle`. When `_docs/02_document/architecture_compliance_baseline.md` exists, the report includes the `## Baseline Delta` section (carried over / resolved / newly introduced) per `code-review/SKILL.md` "Baseline delta".
+- **Gate**:
+  - `PASS` or `PASS_WITH_WARNINGS` → continue to next batch (step 14 loop)
+  - `FAIL` → STOP. Present the report to the user via the Choose format:
+    - A) Auto-fix findings using the Auto-Fix Gate matrix in step 10, then re-run cumulative review
+    - B) Open a targeted refactor run (invoke refactor skill in guided mode with the findings as `list-of-changes.md`)
+    - C) Manually fix, then re-invoke `/implement`
+  - Do NOT loop to the next batch on `FAIL` — the whole point is to stop drift before it compounds
+- **Interaction with Auto-Fix Gate**: Architecture findings (new category from code-review Phase 7) always escalate per the implement auto-fix matrix; they cannot silently auto-fix
+- **Resumability**: if interrupted, the next invocation checks for the latest `cumulative_review_batches_*.md` and computes the changed-file set from batch reports produced after that review
+
 ### 15. Final Test Run
 
 - After all batches are complete, run the full test suite once
@@ -188,13 +225,15 @@ Move each completed task file from `TASKS_DIR/todo/` to `TASKS_DIR/done/`.
 
 ## Batch Report Persistence
 
-After each batch completes, save the batch report to `_docs/03_implementation/batch_[NN]_report.md`. Create the directory if it doesn't exist. When all tasks are complete, produce a FINAL implementation report with a summary of all batches. The filename depends on context:
+After each batch completes, save the batch report to `_docs/03_implementation/batch_[NN]_cycle[N]_report.md` for feature implementation (or `batch_[NN]_report.md` for test/refactor runs). Create the directory if it doesn't exist. When all tasks are complete, produce a FINAL implementation report with a summary of all batches. The filename depends on context:
 
 - **Test implementation** (tasks from test decomposition): `_docs/03_implementation/implementation_report_tests.md`
-- **Feature implementation**: `_docs/03_implementation/implementation_report_{feature_slug}.md` where `{feature_slug}` is derived from the batch task names (e.g., `implementation_report_core_api.md`)
+- **Feature implementation**: `_docs/03_implementation/implementation_report_{feature_slug}_cycle{N}.md` where `{feature_slug}` is derived from the batch task names (e.g., `implementation_report_core_api_cycle2.md`) and `{N}` is the current `state.cycle` from `_docs/_autodev_state.md`. If `state.cycle` is absent (pre-migration), default to `cycle1`.
 - **Refactoring**: `_docs/03_implementation/implementation_report_refactor_{run_name}.md`
 
-Determine the context from the task files being implemented: if all tasks have test-related names or belong to a test epic, use the tests filename; otherwise derive the feature slug from the component names.
+Determine the context from the task files being implemented: if all tasks have test-related names or belong to a test epic, use the tests filename; otherwise derive the feature slug from the component names and append the cycle suffix.
+
+Batch report filenames must also include the cycle counter when running feature implementation: `_docs/03_implementation/batch_{NN}_cycle{N}_report.md` (test and refactor runs may use the plain `batch_{NN}_report.md` form since they are not cycle-scoped).
 
 ## Batch Report
 
@@ -237,7 +276,7 @@ After each batch, produce a structured report:
 Each batch commit serves as a rollback checkpoint. If recovery is needed:
 
 - **Tests fail after final test run**: `git revert <batch-commit-hash>` using hashes from the batch reports in `_docs/03_implementation/`
-- **Resuming after interruption**: Read `_docs/03_implementation/batch_*_report.md` files to determine which batches completed, then continue from the next batch
+- **Resuming after interruption**: Read `_docs/03_implementation/batch_*_report.md` files (filtered by current `state.cycle` for feature implementation) to determine which batches completed, then continue from the next batch
 - **Multiple consecutive batches fail**: Stop and escalate to user with links to batch reports and commit hashes
 
 ## Safety Rules