agent-ix · kreneskyp · Jun 27, 2026 · Jun 27, 2026
@@ -821,6 +821,12 @@ export const SCENARIOS = [
     // valid under the active spec-artifacts-process schema (e.g. PL-001/TSK-001 under
     // the uppercase-only published schema; Plan-001/Task-001 once the mixed-case
     // schema PR is pinned in default-modules.yaml).
+    //
+    // Also asserts the LEAN plan shape (spec-to-plan/references/step-3): plan.md is an
+    // orchestration overview, not a mirror of the bundle — the per-task matrix lives in
+    // a single "Task File Mapping" table, and tracks are described once under "Remaining
+    // Work", so there is NO separate "Execution Tracks" section re-stating them. This
+    // `fileContains` locks in the duplication removal the slim-template change made.
     id: "EV-027",
     useCase: "US-008",
     setup(ctx) {
@@ -849,6 +855,15 @@ export const SCENARIOS = [
       },
       files: ["plan/**/index.md", "plan/**/log.md", "plan/**/tasks/*.md"],
       validate: { globs: ["plan/**/*.md"], shouldPass: true },
+      // Lean plan shape: a single per-task "Task File Mapping" table is present, and
+      // tracks are NOT also re-stated in a separate "Execution Tracks" section.
+      fileContains: [
+        {
+          glob: "plan/**/plan.md",
+          includes: ["## +Task File Mapping"],
+          excludes: ["## +Execution Tracks"],
+        },
+      ],
     },
   },
   {

@@ -50,8 +50,11 @@ All steps required!
 This skill produces or updates a **plan bundle** at `<project_root>/plan/<Plan-id>-<slug>/`:
 
 -   `plan.md` (`type: Plan`): The central living document — requirements summary,
-    dependency graph, execution tracks, quality gates, and test plan. Frontmatter
-    `relationships:` trace (`references`) the requirements the plan covers.
+    dependency graph, execution tracks, quality gates, and test plan. It is an
+    **orchestration overview, not a mirror of the bundle**: ownership, the DAG, and test
+    traces are authoritative in the task frontmatter, so `plan.md` states each fact once
+    (see `references/step-3-execution-plan.md`). Frontmatter `relationships:` trace
+    (`references`) the requirements the plan covers.
 -   `tasks/Task-NNN-<slug>.md` (`type: Task`): One file per task. Frontmatter carries
     the machine contract — `status`, `track`, `priority`, and `relationships:` edges
     (`depends_on` for the DAG, `references` for requirement ownership, `verifies` for

@@ -75,4 +75,14 @@ relationships:
 ### Cross-cutting constraints
 - `NFR-001` applies to [which code paths].
 - `NFR-002` applies to [which merge points].
+
+### The seams (optional)
+One short paragraph grounding the plan in the existing code — the concrete files,
+functions, or boundaries each track attaches to (e.g. "FR-021 widens the write guard in
+`authorize.ts`; FR-022 reuses the existing `chokidar-change-source.ts`"). Keep it to a
+few sentences; omit if the spec is greenfield.
 ```
+
+This is the **single** dependency-graph representation for the bundle. Step 3 references
+it — it does not re-emit a "Remaining Dependency Graph" or a separate "Execution Tracks"
+section.
@@ -37,3 +37,7 @@
 ### Verification (NFRs)
 - [ ] **verify_response_time** (NFR-001): Run load test to ensure p95 < 200ms.
 ```
+
+This is the **single** TC enumeration for the bundle. Downstream sections reference TC
+ids only via the Step 3 **Task File Mapping** table — do not re-list them per track or in
+track exit-criteria.
@@ -64,7 +64,8 @@ A gate is a checkpoint where you validate a fundamental assumption before invest
 - Before starting optimization work (confirm correctness first)
 - Before starting dependent work that would need rework if the gate fails
 
-**Gate format:**
+**Gate format** (this is the thinking format; in `plan.md` the gate is rendered
+**once**, as a one-liner inline in its track — see Output Format below):
 ```markdown
 #### Gate: [Name]
 - **Measures:** [What you're validating]
@@ -155,41 +156,46 @@ the `plan.md` body — see the Output Format below.
 
 ## Output Format (appended to plan/<Plan-id>-<slug>/plan.md)
 
+`plan.md` is an **orchestration overview, not a mirror of the bundle.** Ownership, the
+DAG, and test traces are authoritative in **task frontmatter** (`references`,
+`depends_on`, `verifies`). State each fact **once**: the requirement checklist in
+Requirements Summary (Step 1), the dependency *reasons* in the Dependency Graph (Step 1),
+the TC enumeration in the Test Plan (Step 2), and the per-task row in the Task File
+Mapping below. Step 3 appends only the sections below — it does **not** re-emit the
+dependency graph, add a separate "Execution Tracks" section, restate any task's
+`## Scope`, or re-list TC ids per track.
+
 ```markdown
 ## Remaining Work
 
-### Remaining Dependency Graph
-[Text DAG or ASCII diagram showing what depends on what]
+Describe the tracks **once**, here. One line per item: title, difficulty (optional
+size estimate), and a *behavioral* exit criterion. The item's scope and subtasks live
+in its task file — do not repeat them. Do not list TC ids here; they live in the Test
+Plan and the Task File Mapping.
 
 ### Track A: Critical Path (serial)
-#### A1: [First step]
-- **Scope:** ...
-- **Difficulty:** Easy | Medium | Hard
-- **Estimated new code:** ~NNN lines
-- **Exit criteria:** ...
-
-#### A2: [Second step]
-...
-
-#### Gate: [Quality checkpoint]
-- **Measures:** ...
-- **Pass criteria:** ...
+- **A1 = Task-NNN** [title] — [Easy|Medium|Hard], ~NNN lines; exit: [behavioral outcome, e.g. "converges with no acknowledged loss"].
+- **A2 = Task-NNN** [title] — [difficulty]; exit: [behavioral outcome].
+- **Gate = Task-NNN** [name] — measures [what]; pass: [threshold]. (State each gate once, here in its track — never also in a separate section.)
 
 ### Track B: Parallel (independent agent, can start now)
-#### B1: [Parallel item]
-...
+- **B1 = Task-NNN** [title] — [difficulty]; exit: [behavioral outcome].
 
 ### Track C: Post-Gate
-#### C1: [Gated item]
-...
+- **C1 = Task-NNN** [title] — [difficulty]; exit: [behavioral outcome].
 
 ## Parallel Execution Summary
-[ASCII timeline showing tracks running concurrently]
+[ASCII timeline showing the tracks running concurrently.]
 
 ## Task File Mapping
-[Table mapping Task-NNN files → track → owned requirements → status. The
-authoritative status/deps live in each task's frontmatter; this table is a
-human-readable mirror.]
+
+The single per-task table — the only place that enumerates per-task ownership and
+verification. It is a human-readable mirror of the task frontmatter, which stays
+authoritative for status and edges.
+
+| Task     | Track | Owns (references) | Verified by (verifies) | Status      |
+| -------- | ----- | ----------------- | ---------------------- | ----------- |
+| Task-NNN | A     | FR-00X            | TC-0XX…TC-0XX          | not_started |
 
 ## Coordination Rules
 [What to freeze, what not to start early, shared-file/shared-state single-writer
@@ -198,6 +204,13 @@ discipline, merge sequencing.]
 
 ## Common Mistakes to Avoid
 
+- **Mirroring frontmatter in prose.** `plan.md` is an orchestration overview; ownership,
+  the DAG, and test traces are authoritative in task frontmatter (`references`,
+  `depends_on`, `verifies`). State each fact once — requirement checklist (Requirements
+  Summary), dependency reasons (Dependency Graph), TC enumeration (Test Plan), per-task
+  row (Task File Mapping). Do not add a second "Execution Tracks" section, re-emit the
+  dependency graph, re-list TC ids in track exit-criteria, restate a task's `## Scope`,
+  or describe a gate twice.
 - **Bundling done + remaining work in one task.** If build is done but scan isn't, they're separate tasks even if they were originally planned together.
 - **Missing shared dependencies.** If two items need the same algorithm, extract it as a deliverable — don't let two parallel workers implement it independently.
 - **No gates.** If the whole system's value depends on one unproven property (e.g., recall quality), measure it before building everything around it.