diff --git a/evals/scenarios/index.mjs b/evals/scenarios/index.mjs index 7828898..3f679e5 100644 --- a/evals/scenarios/index.mjs +++ b/evals/scenarios/index.mjs @@ -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"], + }, + ], }, }, { diff --git a/skills/spec-to-plan/SKILL.md b/skills/spec-to-plan/SKILL.md index 9db5204..c8acc34 100644 --- a/skills/spec-to-plan/SKILL.md +++ b/skills/spec-to-plan/SKILL.md @@ -50,8 +50,11 @@ All steps required! This skill produces or updates a **plan bundle** at `/plan/-/`: - `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-.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 diff --git a/skills/spec-to-plan/references/step-1-analysis.md b/skills/spec-to-plan/references/step-1-analysis.md index 1d52aad..6d63b96 100644 --- a/skills/spec-to-plan/references/step-1-analysis.md +++ b/skills/spec-to-plan/references/step-1-analysis.md @@ -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. diff --git a/skills/spec-to-plan/references/step-2-test-plan.md b/skills/spec-to-plan/references/step-2-test-plan.md index 609f197..eaaee4d 100644 --- a/skills/spec-to-plan/references/step-2-test-plan.md +++ b/skills/spec-to-plan/references/step-2-test-plan.md @@ -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. diff --git a/skills/spec-to-plan/references/step-3-execution-plan.md b/skills/spec-to-plan/references/step-3-execution-plan.md index e6aff31..6c17805 100644 --- a/skills/spec-to-plan/references/step-3-execution-plan.md +++ b/skills/spec-to-plan/references/step-3-execution-plan.md @@ -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.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. diff --git a/spec/evals.md b/spec/evals.md index c019830..fbd9174 100644 --- a/spec/evals.md +++ b/spec/evals.md @@ -74,44 +74,44 @@ coverage; the metric-capture requirement for this matrix is ## Scenarios -| Eval | Use Case | Prompt | Expected Outcome | Required Measurements | -| ------ | -------------- | -------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | -| EV-001 | US-001 | Create an FR plus `domain` and `entity` objects for a small feature. | Agent uses one `quoin write` pack, creates all files, and Quire validates them. | success, latency, tool calls, tokens, validation attempts | -| EV-002 | US-002 | Edit an existing FR after discovering its authoring contract. | Agent uses `catalog show` or `write`, edits only needed sections, and validates changed files. | success, latency, tool calls, tokens | -| EV-003 | US-003 | Install a local fixture plugin and author one plugin-defined object. | Plugin appears in catalog, `write --types` resolves it, created file validates. | success, latency, tool calls, tokens | -| EV-004 | US-004 | Validate a mixed changed set of artifact and object files. | Agent runs scoped Quire validation over the changed file set and reports failures clearly. | success, latency, tool calls, validation attempts | -| EV-005 | US-005 | Start a review workflow for a spec directory and inspect status. | `quoin` starts the workflow and `ix-flow status` reports the run and gate state. | success, latency, tool calls | -| EV-006 | US-001, US-004 | Create multiple artifacts that share object templates. | Agent fetches each type contract once, reuses it across files, and validates all changed files. | success, context fetches, tokens, tool calls | -| EV-007 | US-002 | Use lowercase type names in an authoring request. | `quoin write . --types fr,domain` resolves canonical types and prints usable contracts. | success, latency, tool calls | -| EV-008 | US-004 | Repair a spec file after Quire reports validation diagnostics. | Agent interprets diagnostics, edits the failing file, and reaches passing validation. | success, latency, tool calls, tokens, validation attempts | -| EV-009 | US-003 | Install, list, remove, and reinstall a local plugin fixture. | Plugin registry changes are isolated to `IX_HOME`; catalog reflects each lifecycle step. | success, latency, tool calls | -| EV-010 | US-003 | Install a GitHub/package plugin fixture and request one of its types. | `write --types` resolves the installed type and prints usable paths. | success, latency, tool calls, tokens | -| EV-011 | US-002 | Request an unknown type in an authoring pack. | CLI reports the missing type clearly and exits non-zero. | success, latency, tool calls | -| EV-012 | US-004 | Validate multiple globs for a changed-file subset. | Quire validates only matching files and reports each invalid file with a path. | success, latency, tool calls, validation attempts | -| EV-013 | US-005 | Start matrix and to-plan workflows after accepted requirements. | `quoin matrix` and `quoin to-plan` create runs that `ix-flow status` can inspect. | success, latency, tool calls | -| EV-014 | US-001, US-002 | Author a complete spec set from a settled conversation. | Agent creates spec, use cases, matrix, plan, and eval matrix, then validates all spec files. | success, latency, tool calls, tokens, context fetches | -| EV-015 | US-001, US-004 | Author with sibling development modules present. | Catalog prefers intended dev modules deterministically and validation uses matching contracts. | success, latency, tool calls, tokens | -| EV-016 | US-001, US-004 | Author into two sibling repos in one session. | Agent authors under `core/spec/` and `service/spec/` and validates both with one scoped run. | success, latency, tool calls, tokens | -| EV-017 | US-001, US-002 | Author a larger feature spec set with cross-references. | Agent authors StR + 2 US + 3 FR + NFR + domain + 2 entity, fetching each contract once; all validate. | success, latency, tool calls, tokens, context fetches | -| EV-018 | US-001 | Author objects drawn from three different object modules. | One `write` pack resolves `domain`/`api_endpoint`/`configuration` across modules; all validate. | success, latency, tool calls, tokens | -| EV-020 | US-003 | Install a module from GitHub via a subdir source and author its type. | Agent runs `quoin plugin install github:owner/repo//subdir@ref` (real network clone), then authors and validates one of its types. | success, latency, tool calls, tokens | -| EV-021 | US-001 | Start a new spec from a settled idea (greenfield). | Agent creates `spec.md` plus ≥1 US and ≥1 FR **as discrete files**; all validate. (`artifacts` check) | success, latency, tool calls, tokens | -| EV-022 | US-001 | Add one user story to an existing spec. | Agent adds a new `US` file and creates **no** FR/NFR/IT artifacts; all validate. (`artifacts` require + absent) | success, latency, tool calls | -| EV-023 | US-002 | Edit an existing FR in place. | Agent modifies the FR file only, creating no new artifact types; the FR validates. (`artifacts` require + absent) | success, latency, tool calls, validation attempts | -| EV-024 | US-001 | Add a user story **and** the FR that implements it. | Agent authors **both** a `US` and an `FR` artifact (FR traced to the US); all validate. (`artifacts` require) | success, latency, tool calls, tokens | -| EV-025 | US-001 | Backport a spec from a small source file. | Agent authors ≥1 `FR` artifact under `spec/functional/` (not just a `spec.md` table) capturing the code's behavior; all validate. | success, latency, tool calls, tokens | -| EV-026 | US-005 | Run a subset spec-review producing per-analysis SpecReview docs. | Agent runs a `subset` spec-review (integrity + dependency) and authors one **validated** `SpecReview` doc per selected analysis under `spec/reviews/` (Summary + Findings table, Severity enum). (`files` + `validate`) | success, latency, tool calls, tokens, validation attempts | -| EV-027 | US-008 | Create an implementation plan as a multi-plan bundle via spec-to-plan. | Agent uses spec-to-plan to author a plan bundle `plan/-/` — a `type: Plan` plan.md, reserved index.md/log.md, and ≥3 `type: Task` files whose `relationships:` carry the DAG (`depends_on`) + `references`/`verifies`; the whole bundle validates. (`artifacts` require + `files` + `validate`) | success, latency, tool calls, tokens, validation attempts | -| EV-028 | US-008 | Start a second, independent plan in a project that already has one. | Given an existing `plan/Plan-001-*/` bundle, the agent uses spec-to-plan and starts a NEW plan (Step 0 selection), producing a `plan/Plan-002-*/` bundle (`type: Plan` + `type: Task` files) without disturbing Plan-001; both validate. (`artifacts` Plan≥2 + `files` + `validate`) | success, latency, tool calls, tokens, validation attempts | -| EV-029 | US-008 | Regenerate an existing plan after a spec change (update in place). | Given a `plan/PLAN-001-core/` bundle covering FR-001 and a newly-added FR-002, the agent uses spec-to-plan to UPDATE the same plan — adds a task for FR-002 and refreshes index/log — without spawning a second plan; the bundle still validates. (`artifacts` Plan=1 & Task≥3 + `absentFiles` no Plan-002 + `validate`) | success, latency, tool calls, tokens, validation attempts | -| EV-030 | US-005 | Gap-analysis SAD (combined) → FAIL verdict. | Given a plan with an incomplete task, a matrix TC with no backing tagged test, AND an untraced function, the agent runs gap-analysis and authors ONE validated `SpecReview` (`analysis: gap-analysis`) whose Verdict is **FAIL** and whose Findings name the incomplete task + unbacked TC. (`agentRan` + `artifacts` + `validate` + `fileContains` FAIL) | success, latency, tool calls, tokens, validation attempts | -| EV-031 | US-005 | Gap-analysis HAPPY → PASS verdict. | Given a clean plan (all tasks done, every matrix TC backed by a real tagged test, no untraced code), the agent authors a validated `SpecReview` with Verdict **PASS** (no FAIL/CONDITIONAL). Proves the clean-pass branch still validates. (`fileContains` PASS + excludes) | success, latency, tool calls, tokens, validation attempts | -| EV-032 | US-005 | Gap-analysis SAD (medium-only) → CONDITIONAL verdict. | Plan done and matrix fully backed, but the source has an untraced read-only `listCodes` API with no owning requirement. The review flags `listCodes` and is NOT a clean PASS — isolating the reverse-gap (Step 4) path + CONDITIONAL gate. (`fileContains` listCodes, excludes PASS) | success, latency, tool calls, tokens, validation attempts | -| EV-033 | US-005 | Gap-analysis OPTIONAL semantic review catches a hollow test. | Matrix TC-002 is backed by a tagged test so Step 3 passes — but that test asserts nothing. Only the opted-in semantic review (Step 5) catches it; the review flags TC-002 and is not a clean PASS. (`fileContains` TC-002 + hollow indicator, excludes PASS) | success, latency, tool calls, tokens, validation attempts | -| EV-040 | US-001 | Author an FR whose requirement statements are EARS-clean from the start. | Agent authors `spec/functional/FR-100.md` and revises against `quire validate --summary` until grammar-clean; the FR passes `quire validate --strict` (structurally valid AND zero EARS findings). Exercises the EARS skeleton guidance + `/specify`. (`files` + `validate` strict) | success, latency, tool calls, tokens, validation attempts | -| EV-041 | US-004 | Repair a seeded FR that trips the EARS requirement-grammar check. | A structurally-valid FR seeded with three EARS defects (non-singular + vague response + non-canonical trigger). Agent reads the `[ears:…]` warnings and rewrites the Description until `quire validate --strict` passes (grammar-clean). The EARS analogue of the EV-008 repair loop. (`files` + `validate` strict) | success, latency, tool calls, tokens, validation attempts | -| EV-042 | US-001 | Author an FR using a project term + define it in a domain's Ubiquitous Language. | Agent authors `FR-100` ("shall provide a Sprocket") AND a `domain` object whose `## Ubiquitous Language` defines Sprocket. `quire validate --strict` passes only because the harvested project term makes the otherwise-vague object concrete (FR-044 project Ubiquitous-Language). (`files` + `validate` strict) | success, latency, tool calls, tokens, validation attempts | -| EV-043 | US-004 | Repair a flagged project term by DEFINING it (not rewording). | A seeded FR trips the grammar check on the project term `Sprocket`. The agent resolves it by adding the term to a `domain` object's `## Ubiquitous Language` — leaving the requirement wording intact — until `quire validate --strict` passes. Exercises the FR-044 harvest+inject repair path. (`files` + `validate` strict) | success, latency, tool calls, tokens, validation attempts | +| Eval | Use Case | Prompt | Expected Outcome | Required Measurements | +| ------ | -------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | +| EV-001 | US-001 | Create an FR plus `domain` and `entity` objects for a small feature. | Agent uses one `quoin write` pack, creates all files, and Quire validates them. | success, latency, tool calls, tokens, validation attempts | +| EV-002 | US-002 | Edit an existing FR after discovering its authoring contract. | Agent uses `catalog show` or `write`, edits only needed sections, and validates changed files. | success, latency, tool calls, tokens | +| EV-003 | US-003 | Install a local fixture plugin and author one plugin-defined object. | Plugin appears in catalog, `write --types` resolves it, created file validates. | success, latency, tool calls, tokens | +| EV-004 | US-004 | Validate a mixed changed set of artifact and object files. | Agent runs scoped Quire validation over the changed file set and reports failures clearly. | success, latency, tool calls, validation attempts | +| EV-005 | US-005 | Start a review workflow for a spec directory and inspect status. | `quoin` starts the workflow and `ix-flow status` reports the run and gate state. | success, latency, tool calls | +| EV-006 | US-001, US-004 | Create multiple artifacts that share object templates. | Agent fetches each type contract once, reuses it across files, and validates all changed files. | success, context fetches, tokens, tool calls | +| EV-007 | US-002 | Use lowercase type names in an authoring request. | `quoin write . --types fr,domain` resolves canonical types and prints usable contracts. | success, latency, tool calls | +| EV-008 | US-004 | Repair a spec file after Quire reports validation diagnostics. | Agent interprets diagnostics, edits the failing file, and reaches passing validation. | success, latency, tool calls, tokens, validation attempts | +| EV-009 | US-003 | Install, list, remove, and reinstall a local plugin fixture. | Plugin registry changes are isolated to `IX_HOME`; catalog reflects each lifecycle step. | success, latency, tool calls | +| EV-010 | US-003 | Install a GitHub/package plugin fixture and request one of its types. | `write --types` resolves the installed type and prints usable paths. | success, latency, tool calls, tokens | +| EV-011 | US-002 | Request an unknown type in an authoring pack. | CLI reports the missing type clearly and exits non-zero. | success, latency, tool calls | +| EV-012 | US-004 | Validate multiple globs for a changed-file subset. | Quire validates only matching files and reports each invalid file with a path. | success, latency, tool calls, validation attempts | +| EV-013 | US-005 | Start matrix and to-plan workflows after accepted requirements. | `quoin matrix` and `quoin to-plan` create runs that `ix-flow status` can inspect. | success, latency, tool calls | +| EV-014 | US-001, US-002 | Author a complete spec set from a settled conversation. | Agent creates spec, use cases, matrix, plan, and eval matrix, then validates all spec files. | success, latency, tool calls, tokens, context fetches | +| EV-015 | US-001, US-004 | Author with sibling development modules present. | Catalog prefers intended dev modules deterministically and validation uses matching contracts. | success, latency, tool calls, tokens | +| EV-016 | US-001, US-004 | Author into two sibling repos in one session. | Agent authors under `core/spec/` and `service/spec/` and validates both with one scoped run. | success, latency, tool calls, tokens | +| EV-017 | US-001, US-002 | Author a larger feature spec set with cross-references. | Agent authors StR + 2 US + 3 FR + NFR + domain + 2 entity, fetching each contract once; all validate. | success, latency, tool calls, tokens, context fetches | +| EV-018 | US-001 | Author objects drawn from three different object modules. | One `write` pack resolves `domain`/`api_endpoint`/`configuration` across modules; all validate. | success, latency, tool calls, tokens | +| EV-020 | US-003 | Install a module from GitHub via a subdir source and author its type. | Agent runs `quoin plugin install github:owner/repo//subdir@ref` (real network clone), then authors and validates one of its types. | success, latency, tool calls, tokens | +| EV-021 | US-001 | Start a new spec from a settled idea (greenfield). | Agent creates `spec.md` plus ≥1 US and ≥1 FR **as discrete files**; all validate. (`artifacts` check) | success, latency, tool calls, tokens | +| EV-022 | US-001 | Add one user story to an existing spec. | Agent adds a new `US` file and creates **no** FR/NFR/IT artifacts; all validate. (`artifacts` require + absent) | success, latency, tool calls | +| EV-023 | US-002 | Edit an existing FR in place. | Agent modifies the FR file only, creating no new artifact types; the FR validates. (`artifacts` require + absent) | success, latency, tool calls, validation attempts | +| EV-024 | US-001 | Add a user story **and** the FR that implements it. | Agent authors **both** a `US` and an `FR` artifact (FR traced to the US); all validate. (`artifacts` require) | success, latency, tool calls, tokens | +| EV-025 | US-001 | Backport a spec from a small source file. | Agent authors ≥1 `FR` artifact under `spec/functional/` (not just a `spec.md` table) capturing the code's behavior; all validate. | success, latency, tool calls, tokens | +| EV-026 | US-005 | Run a subset spec-review producing per-analysis SpecReview docs. | Agent runs a `subset` spec-review (integrity + dependency) and authors one **validated** `SpecReview` doc per selected analysis under `spec/reviews/` (Summary + Findings table, Severity enum). (`files` + `validate`) | success, latency, tool calls, tokens, validation attempts | +| EV-027 | US-008 | Create an implementation plan as a multi-plan bundle via spec-to-plan. | Agent uses spec-to-plan to author a plan bundle `plan/-/` — a `type: Plan` plan.md, reserved index.md/log.md, and ≥3 `type: Task` files whose `relationships:` carry the DAG (`depends_on`) + `references`/`verifies`; the whole bundle validates. plan.md follows the lean shape — a single `Task File Mapping` table, no separate `Execution Tracks` section. (`artifacts` require + `files` + `validate` + `fileContains`) | success, latency, tool calls, tokens, validation attempts | +| EV-028 | US-008 | Start a second, independent plan in a project that already has one. | Given an existing `plan/Plan-001-*/` bundle, the agent uses spec-to-plan and starts a NEW plan (Step 0 selection), producing a `plan/Plan-002-*/` bundle (`type: Plan` + `type: Task` files) without disturbing Plan-001; both validate. (`artifacts` Plan≥2 + `files` + `validate`) | success, latency, tool calls, tokens, validation attempts | +| EV-029 | US-008 | Regenerate an existing plan after a spec change (update in place). | Given a `plan/PLAN-001-core/` bundle covering FR-001 and a newly-added FR-002, the agent uses spec-to-plan to UPDATE the same plan — adds a task for FR-002 and refreshes index/log — without spawning a second plan; the bundle still validates. (`artifacts` Plan=1 & Task≥3 + `absentFiles` no Plan-002 + `validate`) | success, latency, tool calls, tokens, validation attempts | +| EV-030 | US-005 | Gap-analysis SAD (combined) → FAIL verdict. | Given a plan with an incomplete task, a matrix TC with no backing tagged test, AND an untraced function, the agent runs gap-analysis and authors ONE validated `SpecReview` (`analysis: gap-analysis`) whose Verdict is **FAIL** and whose Findings name the incomplete task + unbacked TC. (`agentRan` + `artifacts` + `validate` + `fileContains` FAIL) | success, latency, tool calls, tokens, validation attempts | +| EV-031 | US-005 | Gap-analysis HAPPY → PASS verdict. | Given a clean plan (all tasks done, every matrix TC backed by a real tagged test, no untraced code), the agent authors a validated `SpecReview` with Verdict **PASS** (no FAIL/CONDITIONAL). Proves the clean-pass branch still validates. (`fileContains` PASS + excludes) | success, latency, tool calls, tokens, validation attempts | +| EV-032 | US-005 | Gap-analysis SAD (medium-only) → CONDITIONAL verdict. | Plan done and matrix fully backed, but the source has an untraced read-only `listCodes` API with no owning requirement. The review flags `listCodes` and is NOT a clean PASS — isolating the reverse-gap (Step 4) path + CONDITIONAL gate. (`fileContains` listCodes, excludes PASS) | success, latency, tool calls, tokens, validation attempts | +| EV-033 | US-005 | Gap-analysis OPTIONAL semantic review catches a hollow test. | Matrix TC-002 is backed by a tagged test so Step 3 passes — but that test asserts nothing. Only the opted-in semantic review (Step 5) catches it; the review flags TC-002 and is not a clean PASS. (`fileContains` TC-002 + hollow indicator, excludes PASS) | success, latency, tool calls, tokens, validation attempts | +| EV-040 | US-001 | Author an FR whose requirement statements are EARS-clean from the start. | Agent authors `spec/functional/FR-100.md` and revises against `quire validate --summary` until grammar-clean; the FR passes `quire validate --strict` (structurally valid AND zero EARS findings). Exercises the EARS skeleton guidance + `/specify`. (`files` + `validate` strict) | success, latency, tool calls, tokens, validation attempts | +| EV-041 | US-004 | Repair a seeded FR that trips the EARS requirement-grammar check. | A structurally-valid FR seeded with three EARS defects (non-singular + vague response + non-canonical trigger). Agent reads the `[ears:…]` warnings and rewrites the Description until `quire validate --strict` passes (grammar-clean). The EARS analogue of the EV-008 repair loop. (`files` + `validate` strict) | success, latency, tool calls, tokens, validation attempts | +| EV-042 | US-001 | Author an FR using a project term + define it in a domain's Ubiquitous Language. | Agent authors `FR-100` ("shall provide a Sprocket") AND a `domain` object whose `## Ubiquitous Language` defines Sprocket. `quire validate --strict` passes only because the harvested project term makes the otherwise-vague object concrete (FR-044 project Ubiquitous-Language). (`files` + `validate` strict) | success, latency, tool calls, tokens, validation attempts | +| EV-043 | US-004 | Repair a flagged project term by DEFINING it (not rewording). | A seeded FR trips the grammar check on the project term `Sprocket`. The agent resolves it by adding the term to a `domain` object's `## Ubiquitous Language` — leaving the requirement wording intact — until `quire validate --strict` passes. Exercises the FR-044 harvest+inject repair path. (`files` + `validate` strict) | success, latency, tool calls, tokens, validation attempts | > EV-042..EV-043 exercise the **project Ubiquitous-Language** layer (quire-rs > FR-044): a repo's own authored terms — here a `domain` object's `## Ubiquitous