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

.cursor/skills/document/workflows/full.md

@@ -142,6 +142,37 @@ Re-entry is seamless: `state.json` tracks exactly which modules are done.
 
 ---
 
+### Step 2.5: Module Layout Derivation
+
+**Role**: Software architect
+**Goal**: Produce `_docs/02_document/module-layout.md` — the authoritative file-ownership map read by `/implement` Step 4, `/code-review` Phase 7, and `/refactor` discovery. Required for any downstream skill that assigns file ownership or checks architectural layering.
+
+This step derives the layout from the **existing** codebase rather than from a plan. Decompose Step 1.5 is the greenfield counterpart and uses the same template; this step uses the same output shape so downstream consumers don't branch on origin.
+
+1. For each component identified in Step 2, resolve its owning directory from module docs (Step 1) and from directory groupings used in Step 2.
+2. For each component, compute:
+   - **Public API**: exported symbols. Language-specific: Python — `__init__.py` re-exports + non-underscore root-level symbols; TypeScript — `index.ts` / barrel exports; C# — `public` types in the namespace root; Rust — `pub` items in `lib.rs` / `mod.rs`; Go — exported (capitalized) identifiers in the package root.
+   - **Internal**: everything else under the component's directory.
+   - **Owns**: the component's directory glob.
+   - **Imports from**: other components whose Public API this one references (parse imports; reuse tooling from Step 0's dependency graph).
+   - **Consumed by**: reverse of Imports from across all components.
+3. Identify `shared/*` directories already present in the code (or infer candidates: modules imported by ≥2 components and owning no domain logic). Create a Shared / Cross-Cutting entry per concern.
+4. Infer the Allowed Dependencies layering table by topologically sorting the import graph built in step 2. Components that import only from `shared/*` go to Layer 1; each successive layer imports only from lower layers.
+5. Write `_docs/02_document/module-layout.md` using `.cursor/skills/decompose/templates/module-layout.md`. At the top of the file add `**Status**: derived-from-code` and a `## Verification Needed` block listing any inference that was not clean (detected cycles, ambiguous ownership, components not cleanly assignable to a layer).
+
+**Self-verification**:
+- [ ] Every component from Step 2 has a Per-Component Mapping entry
+- [ ] Every Public API list is grounded in an actual exported symbol (no guesses)
+- [ ] No component's `Imports from` points at a component in a higher layer
+- [ ] Shared directories detected in code are listed under Shared / Cross-Cutting
+- [ ] Cycles from Step 0 that span components are surfaced in `## Verification Needed`
+
+**Save**: `_docs/02_document/module-layout.md`
+
+**BLOCKING**: Present the layering table and the `## Verification Needed` block to the user. Do NOT proceed until the user confirms (or patches) the derived layout. Downstream skills assume this file is accurate.
+
+---
+
 ### Step 3: System-Level Synthesis
 
 **Role**: Software architect
@@ -358,6 +389,8 @@ Using `.cursor/skills/plan/templates/final-report.md` as structure:
 │    (batched ~5 modules; session break between batches)           │
 │ 2. Component Assembly → group modules, write component specs     │
 │    [BLOCKING: user confirms components]                          │
+│ 2.5 Module Layout    → derive module-layout.md from code         │
+│    [BLOCKING: user confirms layout]                              │
 │ 3. System Synthesis   → architecture, flows, data model, deploy  │
 │ 4. Verification       → compare all docs vs code, fix errors     │
 │    [BLOCKING: user reviews corrections]                          │