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

.cursor/skills/new-task/SKILL.md

@@ -77,6 +77,8 @@ Record the description verbatim for use in subsequent steps.
 
 Read the user's description and the existing codebase documentation from DOCUMENT_DIR (architecture.md, components/, system-flows.md).
 
+**Consult LESSONS.md**: if `_docs/LESSONS.md` exists, read it and look for entries in categories `estimation`, `architecture`, `dependencies` that might apply to the task under consideration. If a relevant lesson exists (e.g., "estimation: auth-related changes historically take 2x estimate"), bias the classification and recommendation accordingly. Note in the output which lessons (if any) were applied.
+
 Assess the change along these dimensions:
 - **Scope**: how many components/files are affected?
 - **Novelty**: does it involve libraries, protocols, or patterns not already in the codebase?
@@ -178,6 +180,34 @@ When gaps are found, the task spec (Step 6) MUST include the missing tests in th
 
 ---
 
+### Step 4.5: Contract & Layout Check
+
+**Role**: Architect
+**Goal**: Prevent silent public-API drift and keep `module-layout.md` consistent before implementation locks file ownership.
+
+Apply the four shared-task triggers from `.cursor/skills/decompose/SKILL.md` Step 2 rule #10 (shared/*, Scope mentions interface/DTO/schema/event/contract/API/shared-model, parent epic is cross-cutting, ≥2 consumers) and classify the task:
+
+- **Producer** — any trigger fires, OR the task changes a public signature / invariant / serialization / error variant of an existing symbol:
+  1. Check for an existing contract at `_docs/02_document/contracts/<component>/<name>.md`.
+  2. If present → decide version bump (patch / minor / major per the contract's Versioning Rules) and add the Change Log entry to the task's deliverables.
+  3. If absent → add creation of the contract file (using `.cursor/skills/decompose/templates/api-contract.md`) to the task's Scope.Included; add a `## Contract` section to the task spec.
+  4. List every currently-known consumer (from Codebase Analysis Step 4) and add them to the contract's Consumer tasks field.
+
+- **Consumer** — the task imports or calls a public API belonging to another component:
+  1. Resolve the component's contract file; add it to the task's `### Document Dependencies` section.
+  2. If the cross-component interface has no contract file, Choose: **A)** create a retroactive contract now as a prerequisite task, **B)** proceed without (logs an explicit coupling risk in the task's Risks & Mitigation).
+
+- **Layout delta** — the task introduces a new component OR changes an existing component's Public API surface:
+  1. Draft the Per-Component Mapping entry (or the Public API diff) against `_docs/02_document/module-layout.md` using `.cursor/skills/decompose/templates/module-layout.md` format.
+  2. Add the layout edit to the task's deliverables; the implementer writes it alongside the code change.
+  3. If `module-layout.md` does not exist, STOP and instruct the user to run `/document` first (existing-code flow) or `/decompose` default mode (greenfield). Do not guess.
+
+Record the classification and any contract/layout deliverables in the working notes; they feed Step 5 (Validate Assumptions) and Step 6 (Create Task).
+
+**BLOCKING**: none — this step surfaces findings; the user confirms them in Step 5.
+
+---
+
 ### Step 5: Validate Assumptions
 
 **Role**: Quality gate
@@ -229,6 +259,9 @@ Present using the Choose format for each decision that has meaningful alternativ
 - [ ] Complexity points match the assessment
 - [ ] Dependencies reference existing task tracker IDs where applicable
 - [ ] No implementation details leaked into the spec
+- [ ] If Step 4.5 classified the task as producer, the `## Contract` section exists and points at a contract file
+- [ ] If Step 4.5 classified the task as consumer, `### Document Dependencies` lists the relevant contract file
+- [ ] If Step 4.5 flagged a layout delta, the task's Scope.Included names the `module-layout.md` edit
 
 ---
 
@@ -237,7 +270,7 @@ Present using the Choose format for each decision that has meaningful alternativ
 **Role**: Project coordinator
 **Goal**: Create a work item ticket and link it to the task file.
 
-1. Create a ticket via the configured work item tracker (see `autopilot/protocols.md` for tracker detection):
+1. Create a ticket via the configured work item tracker (see `autodev/protocols.md` for tracker detection):
    - Summary: the task's **Name** field
    - Description: the task's **Problem** and **Acceptance Criteria** sections
    - Story points: the task's **Complexity** value