[no-ticket] Sync .cursor with suite root

Bring this repo's .cursor/ in line with the suite monorepo root .cursor/
so rules, skills, and autodev artifacts stay consistent across
submodules and sibling repos.

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

.cursor/skills/implement/SKILL.md

@@ -19,20 +19,6 @@ Implement all tasks produced by the `/decompose` skill. This skill reads task sp
 
 For each task the main agent receives a task spec, analyzes the codebase, implements the feature, writes tests, and verifies acceptance criteria — then moves on to the next task.
 
-## Test-Run Cadence (READ FIRST, EVERY BATCH)
-
-Under this skill, full test suite runs happen **exactly once**, at Step 16 (Final Test Run), after every batch in the implementation phase has been committed. Per-batch and per-task full-suite runs are **forbidden**.
-
-What runs when:
-
-- **Per task** (Step 6.4): focused tests for the task's changed files + sibling tests in the same component directory. Nothing more.
-- **Per batch** (Step 7): nothing. Aggregate per-task statuses; do not re-run anything. Cumulative cross-batch regressions are caught by Step 14.5 (Cumulative Code Review), not by a per-batch full-suite invocation.
-- **End of implementation phase** (Step 16): full test suite, exactly once.
-
-This overrides the general `coderule.mdc` rule "run the full test suite when you think you are done with changes". Inside this skill, "done with changes" means the implementation phase is finished (Step 16), not "this batch is finished".
-
-If you catch yourself about to run `pytest tests/unit/` (or equivalent full-suite command) at the end of a batch, STOP — that is the failure mode this banner exists to prevent. Run only the focused subset that touches this batch's changed files.
-
 ## Core Principles
 
 - **Sequential execution**: implement one task at a time. Do NOT spawn subagents and do NOT run tasks in parallel. (See `.cursor/rules/no-subagents.mdc`.)
@@ -44,7 +30,6 @@ If you catch yourself about to run `pytest tests/unit/` (or equivalent full-suit
 - **Auto-start**: batches start immediately — no user confirmation before a batch
 - **Gate on failure**: user confirmation is required only when code review returns FAIL
 - **Commit per batch**: after each batch is confirmed, commit. Ask the user whether to push to remote unless the user previously opted into auto-push for this session.
-- **Focused test runs per task, full-suite gate once at the end**: each task runs only the focused tests for its changed files (see Step 6.4). The full unit/test suite is invoked exactly once, at Step 16 (Final Test Run), after every batch in the implementation phase has been committed. Per-batch full-suite runs are forbidden — they burn time without catching anything the focused runs + cumulative review (Step 14.5) do not already cover.
 
 ## Context Resolution
 
@@ -79,6 +64,27 @@ TASKS_DIR/
 └── done/        ← completed tasks (moved here after implementation)
 ```
 
+### Suite-level invocation context (meta-repo flow)
+
+When invoked from `.cursor/skills/autodev/flows/meta-repo.md` Step 3.5 (or any caller that supplies the same context envelope), the skill receives:
+
+```
+suite_level: true
+TASKS_DIR: <override>          # e.g., _docs/tasks/  (vs. default _docs/02_tasks/)
+module_layout_path: <override>  # e.g., _docs/tasks/_suite_module_layout.md
+```
+
+When `suite_level: true` is present, the following gate adjustments apply — and ONLY these. All other steps (1–14, 16) execute unchanged:
+
+1. **TASKS_DIR override** is honored throughout the skill (Step 1 Parse, Step 13 Archive, Step 15 input paths if it ran). Default `_docs/02_tasks/` is replaced by the supplied path.
+2. **module_layout_path override** is read instead of the hardcoded `_docs/02_document/module-layout.md` in Step 4 (Assign File Ownership). The supplied file uses the same `Per-Component Mapping` schema. If both the override and the hardcoded path are missing, behavior is unchanged from default mode (STOP and instruct).
+3. **Step 14.5 (Cumulative Code Review) — SKIPPED**. The meta-repo has no `_docs/02_document/architecture_compliance_baseline.md`; cross-task drift is captured by the next `monorepo-status` cycle instead.
+4. **Step 15 (Product Implementation Completeness Gate) — SKIPPED**. The gate's hard inputs (`_docs/02_document/architecture.md`, `system-flows.md`, `components/*/description.md`) do not exist in the meta-repo artifact layout. Suite-level tasks are infrastructure / coordination work (renames, cross-repo edits, suite-root infra additions), not feature implementation; the equivalent completeness signal is the next `monorepo-status` drift report (which the meta-repo flow re-runs immediately after Step 3.5 returns).
+5. **Final report filename**: `_docs/03_implementation/suite_implementation_report_{run_name}.md` (in addition to the existing feature/test/refactor variants). Batch reports follow `_docs/03_implementation/suite_batch_{NN}_report.md`.
+6. **Tracker integration** (Step 5: In Progress, Step 12: In Testing) runs unchanged — suite-level tickets follow the same tracker rules as any other.
+
+Without `suite_level: true`, none of these adjustments apply and the skill runs exactly as documented in default mode.
+
 ## Prerequisite Checks (BLOCKING)
 
 1. `TASKS_DIR/todo/` exists and contains at least one task file for the selected context — **STOP if missing**
@@ -118,7 +124,7 @@ 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.
+The authoritative file-ownership map is `_docs/02_document/module-layout.md` (produced by the decompose skill's Step 1.5), unless `suite_level: true` was supplied in the invocation context — in which case the `module_layout_path` override is read instead (see "Suite-level invocation context" above). 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:
 - Read the task spec's **Component** field.
@@ -137,14 +143,7 @@ If `_docs/02_document/module-layout.md` is missing or the component is not found
 
 ### 5. Update Tracker Status → In Progress
 
-For each task in the batch, transition its ticket status to **In Progress** via the configured work item tracker (see `protocols.md` for tracker detection) before starting work. If `tracker: local`, skip this step.
-
-**On any tracker error or ambiguous response: STOP and ASK the user.** Per `.cursor/rules/tracker.mdc`:
-
-- Errored / non-2xx / timeout / empty body / opaque `{"success": true}` → STOP. Do not retry automatically. Do not move on.
-- Surface the raw response verbatim to the user via Choose A/B/C/D (retry / re-auth / `tracker: local` / abort).
-- If the response is a bare `{"success": true}` with no echoed issue state, perform a read-back (`getJiraIssue`) to confirm the status actually changed. If the read-back shows the old status or fails → STOP and ASK.
-- Never proceed past the transition assuming success when the evidence is opaque.
+For each task in the batch, transition its ticket status to **In Progress** via the configured work item tracker (see `protocols.md` for tracker detection) before starting work. If `tracker: local`, skip this step. If a tracker operation fails unexpectedly, follow `.cursor/rules/tracker.mdc`.
 
 ### 6. Implement Tasks Sequentially
 
@@ -154,8 +153,8 @@ For each task in the batch **in topological order, one at a time**:
 1. Read the task spec file.
 2. Respect the file-ownership envelope computed in Step 4 (OWNED / READ-ONLY / FORBIDDEN).
 3. Implement the feature and write/update tests for every acceptance criterion in the spec. Tests for internal product behavior must exercise the production implementation path. If a test cannot run in the current environment (e.g., TensorRT requires GPU), the test must still exist and skip/block with a clear prerequisite reason, but that skip does not make missing production code complete.
-4. Run **focused tests only** — the new/changed test files for THIS task, plus any sibling test files in the same component directory that exercise files the task modified. Do **NOT** run the full unit suite here, and do **NOT** run it at the end of the batch. The full-suite gate runs once at Step 16 (end of the whole implementation phase). If focused tests fail, fix in-place — do not defer.
-5. Capture a short per-task status line (files changed, focused-test pass/fail counts, any blockers) for the batch report.
+4. Run the relevant tests locally before moving on to the next task in the batch. If tests fail, fix in-place — do not defer.
+5. Capture a short per-task status line (files changed, tests pass/fail, any blockers) for the batch report.
 
 Do NOT spawn subagents and do NOT attempt to implement two tasks simultaneously, even if they touch disjoint files. See `.cursor/rules/no-subagents.mdc`.
 
@@ -163,7 +162,6 @@ Do NOT spawn subagents and do NOT attempt to implement two tasks simultaneously,
 
 - After all tasks in the batch are finished, aggregate the per-task status lines into a structured batch status.
 - If any task reported "Blocked", log the blocker with the failing task's ID and continue — the batch report will surface it.
-- **Do NOT run the full unit/test suite here.** The full-suite gate runs exactly once at Step 16 (end of implementation phase). Running it per-batch on a large project burns time without catching anything the focused per-task runs missed — cross-batch regressions are caught by Step 14.5 (Cumulative Code Review) and Step 16, not by repeated full-suite invocations.
 
 **Stuck detection** — while implementing a task, watch for these signals in your own progress:
 - The same file has been rewritten 3+ times without tests going green → stop, mark the task Blocked, and move to the next task in the batch (the user will be asked at the end of the batch).
@@ -231,9 +229,7 @@ Track `auto_fix_attempts` and `escalated_findings` in the batch report for retro
 
 ### 12. Update Tracker Status → In Testing
 
-After the batch is committed (and pushed if the user approved pushing), transition the ticket status of each task in the batch to **In Testing** via the configured work item tracker. If `tracker: local`, skip this step.
-
-**Same STOP-and-ASK rule as Step 5**: on any tracker error, non-2xx response, timeout, empty body, or opaque `{"success": true}` without echoed state, STOP — surface the raw response and ask the user. Verify the transition by reading the issue back when the response is minimal. Never silently proceed.
+After the batch is committed (and pushed if the user approved pushing), transition the ticket status of each task in the batch to **In Testing** via the configured work item tracker. If `tracker: local`, skip this step. If a tracker operation fails unexpectedly, follow `.cursor/rules/tracker.mdc`.
 
 ### 13. Archive Completed Tasks
 
@@ -247,6 +243,8 @@ For product implementation, this archive means "batch implementation accepted."
 
 ### 14.5. Cumulative Code Review (every K batches)
 
+**Skipped entirely when `suite_level: true`** (see "Suite-level invocation context" above) — the meta-repo has no `architecture_compliance_baseline.md` to evaluate against; cross-task drift is captured by the next `monorepo-status` cycle.
+
 - **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)
@@ -264,7 +262,7 @@ For product implementation, this archive means "batch implementation accepted."
 
 ### 15. Product Implementation Completeness Gate
 
-Run this gate after all **product implementation** tasks are complete and before writing any final product implementation report or allowing autodev to proceed to testability/test decomposition. Skip this gate only when the remaining context is explicitly test implementation or refactoring, as determined by the task files and report filename rules.
+Run this gate after all **product implementation** tasks are complete and before writing any final product implementation report or allowing autodev to proceed to testability/test decomposition. Skip this gate when (a) the remaining context is explicitly test implementation or refactoring (as determined by the task files and report filename rules), OR (b) `suite_level: true` was supplied in the invocation context (the gate's inputs do not exist in the meta-repo artifact layout — see "Suite-level invocation context" above).
 
 **Goal**: catch the failure mode where narrow tests validate scaffold behavior while the task's actual outcome, included scope, architecture promise, or named integration remains unimplemented.
 
@@ -321,9 +319,7 @@ Remediation task creation:
 
 ### 16. Final Test Run
 
-This is the **only** full-suite invocation in the implement skill. Steps 6 / 7 / 14 deliberately avoid full-suite runs — they would burn time per-batch without catching anything the focused per-task runs and the cumulative review (Step 14.5) do not already cover.
-
-- After all batches are complete, run the full test suite **once** unless the invoking flow's immediate next step is `Run Tests`.
+- After all batches are complete, run the full test suite once unless the invoking flow's immediate next step is `Run Tests`.
 - If the next flow step is `Run Tests`, record a handoff in the final implementation report and let `.cursor/skills/test-run/SKILL.md` own the full-suite gate to avoid duplicate full runs.
 - When this step does run, read and execute `.cursor/skills/test-run/SKILL.md` (detect runner, run suite, diagnose failures, present blocking choices).
 - Test failures are a **blocking gate** — do not proceed until the test-run skill completes with a user decision.
@@ -336,8 +332,9 @@ After each batch completes, save the batch report to `_docs/03_implementation/ba
 - **Test implementation** (tasks from test decomposition): `_docs/03_implementation/implementation_report_tests.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`
+- **Suite-level** (when `suite_level: true` was supplied — see "Suite-level invocation context" above): `_docs/03_implementation/suite_implementation_report_{run_name}.md`. Batch reports use `_docs/03_implementation/suite_batch_{NN}_report.md`. `{run_name}` is derived from the batch task IDs (e.g., `suite_implementation_report_az543_az549_az550.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 and append the cycle suffix.
+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; if `suite_level: true` was supplied, use the suite 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).
 
@@ -392,4 +389,4 @@ Each batch commit serves as a rollback checkpoint. If recovery is needed:
 - Never run tasks in parallel and never spawn subagents — see `.cursor/rules/no-subagents.mdc`
 - If a task is flagged as stuck, stop working on it and report — do not let it loop indefinitely
 - Always run the Product Implementation Completeness Gate before final product reports
-- Always run or hand off the full test suite after all batches complete (step 16) — and only at step 16. Per-task runs are focused (changed files + sibling component tests); per-batch runs are forbidden.
+- Always run or hand off the full test suite after all batches complete (step 16)