contract-driven-delivery 2.0.18 → 2.0.19

package/CHANGELOG.md

@@ -1,5 +1,31 @@
 # Changelog
 
+## [2.0.19] - 2026-05-15
+
+Design ownership patch for the implementation-planning flow.
+
+### Changed
+
+- **`design.md` now has an explicit owner and task**: `spec-architect` owns
+  `specs/changes/<change-id>/design.md`; `tasks.yml` now tracks required
+  design confirmation separately from CI gate planning and implementation
+  planning.
+- **Optional report artifacts are now minimized**: routine reviewer evidence
+  should use concise `agent-log/*.yml` pointers; report markdown is reserved for
+  blocking findings, approved-with-risk decisions, excluded pre-existing
+  failures, visual evidence bundles, or high-risk stress/soak results.
+- **Execution artifacts now reference instead of duplicate**:
+  `implementation-plan.md`, `test-plan.md`, and `ci-gates.md` now instruct
+  agents to reference source artifacts by path/section/id instead of copying
+  full design, test, CI, or contract prose.
+- **Planner no longer backfills design**: `implementation-planner` now blocks
+  and routes back to `spec-architect` if classification requires design but
+  `design.md` is missing or still scaffolded.
+- **Classifier and resume routing are stricter**: classification now keeps
+  `Architecture Review Required`, Optional Artifacts `design.md`, Required
+  Agents, and task `1.3` consistent; `/cdd-resume` resumes from
+  `spec-architect` before planning when required design is missing.
+
 ## [2.0.18] - 2026-05-15
 
 Implementation planning handoff release. This adds a senior planning step so

package/README.md

@@ -94,8 +94,8 @@ or
 3. The `change-classifier` agent (Opus) reads the request, classifies risk and tier, decides which agents are needed
 4. If the request is too broad, the classifier can return an atomic split proposal instead of forcing one Tier 0/1 monolith
 5. For Tier 0-1 work, Claude's narration uses stage badges so users can tell whether the flow is deciding, implementing, testing, or reviewing
-6. Agents run in order: contracts ??test plan ??spec/architecture review (if needed) ??CI/CD gates ??implementation plan ??backend engineer ??frontend engineer ??QA
-7. `implementation-planner` writes `implementation-plan.md`, the concise execution packet implementation agents follow
+6. Agents run in order: contracts ??test plan ??`spec-architect` writes `design.md` if required ??CI/CD gates ??implementation plan ??backend engineer ??frontend engineer ??QA
+7. `implementation-planner` reads the confirmed artifacts and writes `implementation-plan.md`, the concise execution packet implementation agents follow. It does not create `design.md`; missing required design routes back to `spec-architect`.
 8. Implementation agents write code/tests from that plan and optional concise handoff notes
 9. `cdd-kit gate <change-id>` runs automatically to confirm all artifacts are complete
 10. Claude reports a summary and the suggested git commit
@@ -120,7 +120,7 @@ Machine-readable metadata such as future `change.yml` / `trace.yml` should follo
 CDD uses two agent classes on purpose:
 
 - `change-classifier`, `contract-reviewer`, `qa-reviewer`, `visual-reviewer`, `dependency-security-reviewer`, `ui-ux-reviewer`, `repo-context-scanner`, and `spec-drift-auditor` are read-only. They return analysis, verdicts, or optional handoff notes; main Claude writes the corresponding files.
-- `implementation-planner`, `backend-engineer`, `frontend-engineer`, `e2e-resilience-engineer`, `monkey-test-engineer`, `stress-soak-engineer`, `ci-cd-gatekeeper`, `test-strategist`, and `spec-architect` are write-capable. They write their own implementation artifacts directly.
+- `implementation-planner`, `backend-engineer`, `frontend-engineer`, `e2e-resilience-engineer`, `monkey-test-engineer`, `stress-soak-engineer`, `ci-cd-gatekeeper`, `test-strategist`, and `spec-architect` are write-capable. They write their own owned artifacts directly: for example, `spec-architect` owns `design.md`, while `implementation-planner` owns `implementation-plan.md`.
 
 This split is deliberate:
 
@@ -128,6 +128,24 @@ This split is deliberate:
 - Implementation and planning agents write directly so large artifacts and code edits do not have to be relayed back through the main orchestrator, which reduces token waste and preserves clearer ownership.
 - `tasks.yml` remains owned by main Claude so task state changes stay centralized even when multiple agents contribute files.
 
+### Artifact Minimization
+
+CDD keeps the authoritative artifact set small. Routine reviewer findings should
+not become new markdown files.
+
+| artifact class | files | rule |
+|---|---|---|
+| Core decision and planning | `change-classification.md`, `context-manifest.md`, `test-plan.md`, `ci-gates.md`, `implementation-plan.md`, `tasks.yml` | required for implementation changes |
+| Conditional design | `design.md` | only when `spec-architect` is required |
+| Durable evidence reports | `qa-report.md`, `visual-review-report.md`, `regression-report.md`, `monkey-test-report.md`, `stress-soak-report.md` | only for blocking findings, approved-with-risk, excluded pre-existing failures, visual evidence bundles, or high-risk load/soak results |
+| Lightweight traces | `agent-log/*.yml` | optional concise pointers for routine evidence and resume/debugging |
+
+Later artifacts should reference earlier artifacts by path, section, acceptance
+criterion, decision id, or gate name. They should not copy full test strategy,
+CI policy, design rationale, or contract prose. This keeps token use bounded
+and prevents multiple markdown files from becoming conflicting sources of
+truth.
+
 **You stay in control by:**
 - Reviewing the `change-classification.md` before implementation starts
 - Checking the `test-plan.md` to confirm the right test families are planned
@@ -297,12 +315,12 @@ What gets updated:
 | `cdd-kit refresh --yes` | global agents/skills, missing project files, kit-shipped templates with backup, model policy roles, hooks, `.cdd/code-map.yml` | user source, contracts content, active change content |
 | `cdd-kit migrate --all` | existing `specs/changes/*` metadata and new required scaffolds | implementation code and completed archive history |
 
-For this release, run `cdd-kit refresh --yes` so the new
+For releases 2.0.18 and newer, run `cdd-kit refresh --yes` so the
 `implementation-planner` agent, updated `/cdd-new` and `/cdd-resume` skills,
 fresh `specs/templates/`, and `.cdd/model-policy.json` role binding are all in
 place. Then run `cdd-kit migrate --all` so existing active change directories
-receive `implementation-plan.md`; fill that plan before resuming implementation
-agents.
+receive `implementation-plan.md`; fill required `design.md` with
+`spec-architect` before resuming the planner or implementation agents.
 
 If you do not want template overwrites, run the narrower path:
 
@@ -579,6 +597,10 @@ cdd-kit new add-user-api --depends-on add-user-db
 cdd-kit new add-user-auth --skip-scan
 ```
 
+Prefer the default scaffold. `--all` is mainly for template inspection or
+manual workflows; `/cdd-new` should create optional markdown only when
+classification requires it or review evidence needs durable prose.
+
 By default, `cdd-kit new` auto-runs `cdd-kit context-scan` when `specs/context/` indexes are missing or stale. Use `--skip-scan` only if you intentionally want a bare scaffold without refreshing classifier indexes first.
 
 For larger requests, split the work into atomic changes on the same feature branch and use `--depends-on` to record upstream order. `cdd-kit gate` blocks a dependent change until each upstream change is either archived or has `status: completed` in its `tasks.yml`.

package/assets/agents/change-classifier.md

@@ -152,9 +152,32 @@ The following 7 artifacts are always required for implementation changes:
 | design.md | no | |
 | qa-report.md | no | |
 | regression-report.md | no | |
+| visual-review-report.md | no | |
+| monkey-test-report.md | no | |
+| stress-soak-report.md | no | |
 
 Note: `archive.md` is created during change close-out, not at classification time.
 
+Artifact minimization rule:
+- Do not create optional markdown just because an agent can write or review it.
+- Prefer short `agent-log/*.yml` pointers for routine evidence, reviewer notes,
+  and pass/fail summaries.
+- Set `qa-report.md`, `visual-review-report.md`, `regression-report.md`,
+  `monkey-test-report.md`, or `stress-soak-report.md` to `yes` only when the
+  change needs durable prose evidence: blocking findings, approved-with-risk,
+  pre-existing failures excluded from the gate, visual evidence bundles, or
+  high-risk load/soak results.
+- Set `current-behavior.md`, `proposal.md`, or `spec.md` to `yes` only when the
+  request needs a separate product investigation or user-facing behavior
+  decision that does not fit in classification, design, or implementation plan.
+- Later artifacts should reference earlier artifacts by path/section/id instead
+  of copying full rationale, tests, CI gates, or design decisions.
+
+Design consistency rule:
+- If `Architecture Review Required` is `yes`, set `design.md` to `yes` and include `spec-architect` in `## Required Agents`.
+- If `design.md` is `yes`, `Architecture Review Required` must also be `yes` and `spec-architect` must be listed.
+- If no design review is needed, include task `1.3` in `## Tasks Not Applicable`.
+
 ## Required Contracts
 - API:
 - CSS/UI:
@@ -251,7 +274,7 @@ concrete pointer (path:line-range, test-id, URL, or pass/fail string):
 artifacts:
   - { type: tier, pointer: "Tier 2" }
   - { type: risk, pointer: "medium" }
-  - { type: required-artifacts, pointer: "change-request, classification, test-plan, ci-gates, tasks" }
+  - { type: required-artifacts, pointer: "change-request, classification, context-manifest, test-plan, ci-gates, implementation-plan, tasks" }
   - { type: required-reviewers, pointer: "contract-reviewer, qa-reviewer" }
   - { type: context-manifest-draft, pointer: "specs/changes/<id>/context-manifest.md#allowed-paths" }
 ```
@@ -263,7 +286,10 @@ If a recommended `type` does not apply to your run, either omit it or use `point
 - A single request can be both `ui-only-change` and `api-only-change` ??list both as primary; require both UI/UX-visual review AND contract tests.
 - `bug-fix` that requires a contract change is no longer just a bug-fix ??promote to `feature-enhancement` or `business-logic-change` to force the contract path.
 - `refactor` that touches CI gates is also a `ci-cd-change`.
-- When uncertain, classify upward (higher risk, more artifacts); the cost of unnecessary artifacts is small, the cost of skipped artifacts is high.
+- When uncertain, classify upward for risk and required agents, but keep optional
+  artifacts minimal. The cost of a skipped required artifact is high; the cost
+  of unnecessary optional markdown is also high because it increases token load
+  and creates duplicate sources of truth.
 
 ## Routing rules
 
@@ -274,4 +300,5 @@ If a recommended `type` does not apply to your run, either omit it or use `point
 - High-load, auto-refresh, queue, cache, report, or long-running job change requires stress or soak consideration.
 - Existing behavior changes require current behavior and regression scope.
 - Bug fixes require reproduction, root cause, failing test, and regression test whenever feasible.
+- Architecture review, non-obvious design decisions, module-boundary changes, data-flow changes, migration/rollback decisions, compatibility trade-offs, or operational-risk decisions require `spec-architect` to write `design.md` before `implementation-planner` runs.
 - Any implementation change requires `implementation-planner` before backend/frontend/test implementation agents. The planner turns decisions, contracts, and tests into the execution packet; implementation agents should not infer missing scope from chat history.

package/assets/agents/ci-cd-gatekeeper.md

@@ -9,6 +9,10 @@ You are the CI/CD gatekeeper.
 
 CI/CD is mandatory. Every change must have a `ci-gates.md` plan, even if the plan states that existing gates are sufficient. You both design the gate plan and apply the required workflow changes.
 
+Keep `ci-gates.md` as the authority for gate policy only. Reference
+`test-plan.md` rows, acceptance criteria, or test commands; do not duplicate the
+full test strategy or implementation plan.
+
 ## Responsibilities
 
 - Design the gate plan (`ci-gates.md`) for every change.

package/assets/agents/e2e-resilience-engineer.md

@@ -33,7 +33,10 @@ Before editing tests, read `specs/changes/<change-id>/implementation-plan.md` an
 
 ## Output
 
-Record test files, scenarios, fixtures/mocks, commands, screenshots/videos, and mutation checks.
+Record test files, scenarios, fixtures/mocks, commands, screenshots/videos, and
+mutation checks in concise response text plus optional `agent-log/*.yml`
+evidence pointers. Do not create separate markdown reports unless
+classification explicitly requires one or failures need durable prose.
 
 ## Read scope
 

package/assets/agents/implementation-planner.md

@@ -11,6 +11,10 @@ Your job is to give implementation agents a complete, low-ambiguity execution pa
 
 `specs/changes/<change-id>/implementation-plan.md`
 
+You have the Edit tool and should write that file directly. If the runtime
+denies file writes, report `blocked` with the exact target path and do not
+continue as if the plan were written.
+
 ## Inputs
 
 Read these change artifacts first:
@@ -27,16 +31,27 @@ Read these change artifacts first:
 
 Use the context manifest as the read boundary. If required context is missing, add a Context Expansion Request and report `blocked` instead of guessing.
 
+If `change-classification.md` says `Architecture Review Required: yes`, marks
+Optional Artifacts `design.md` as `yes`, or lists `spec-architect` in
+`## Required Agents`, then `specs/changes/<change-id>/design.md` must already
+exist and be filled before you plan. If it is missing or still a scaffold,
+report `blocked` and route back to `spec-architect`. Do not create or repair
+`design.md` yourself.
+
 ## Planning Rules
 
 - Write an execution plan, not a rationale document.
 - Include only the background needed to execute safely.
 - Name concrete files, directories, contracts, and tests whenever known.
+- Reference `test-plan.md`, `ci-gates.md`, `design.md`, and contract files by
+  path, section, criterion id, decision id, or gate name. Do not copy their full
+  prose into this plan.
 - State non-goals clearly so implementation agents do not opportunistically refactor.
 - Map every required change to an owner agent.
 - Map acceptance criteria to tests or verification commands.
 - If the chosen approach is not clear from the artifacts, stop and report `blocked`.
 - If a bug fix lacks reproduction, root cause, or regression coverage and the classification says those are required, stop and report `blocked`.
+- Never write `design.md`; design decisions are owned by `spec-architect`.
 
 ## Output
 
@@ -61,6 +76,13 @@ Write `specs/changes/<change-id>/implementation-plan.md` with this structure:
 |---|---|---|---|
 | IP-1 | ... | ... | backend-engineer |
 
+## Source Artifact Pointers
+| source | relevant pointer | used for |
+|---|---|---|
+| test-plan.md | AC-1 | tests to run/write |
+| ci-gates.md | required gates table | verification commands |
+| design.md | Decision: ... | implementation constraint |
+
 ## File-Level Plan
 | path or glob | action | notes |
 |---|---|---|
@@ -79,6 +101,7 @@ Write `specs/changes/<change-id>/implementation-plan.md` with this structure:
 
 ## Handoff Constraints
 - Implementation agents must not infer missing requirements from chat history.
+- Do not re-copy full design, test strategy, CI policy, or contract prose into this plan; follow the source pointers above.
 - If this plan omits a required file, behavior, contract, or test, stop and report `blocked`.
 - Keep implementation within the file-level plan unless a Context Expansion Request is approved.
 

package/assets/agents/monkey-test-engineer.md

@@ -37,6 +37,11 @@ id, seed/input, baseline commit or prior evidence, and whether this change
 touched the failing surface. Mark it as a follow-up when it is outside this
 change's scope; keep new or regressed failures blocking.
 
+Default reporting should be concise response text plus optional
+`agent-log/*.yml` evidence pointers. Create `monkey-test-report.md` only when
+classification explicitly requires it, when failures or excluded pre-existing
+issues need durable prose, or when QA needs approved-with-risk evidence.
+
 ## Tools
 
 - Property-based ??fast-check (JS/TS), hypothesis (Python), proptest (Rust) for state machine invariants.

package/assets/agents/qa-reviewer.md

@@ -53,6 +53,14 @@ Invoke `spec-drift-auditor` at the following points (do not wait for issues to s
 
 ## Output
 
+Default output is a concise QA verdict in your response plus an optional
+`Agent Log` YAML block. Do not ask main Claude to create `qa-report.md` for a
+routine approved change.
+
+Emit a full `# QA Report` body only when `change-classification.md` explicitly
+requires `qa-report.md`, or when the decision is `blocked` /
+`approved-with-risk`, or when pre-existing failures are excluded from this gate.
+
 ```md
 # QA Report
 

package/assets/agents/spec-architect.md

@@ -7,7 +7,7 @@ model: opus
 
 You are the architecture reviewer.
 
-Do not implement or modify production code, tests, configs, or contracts. Your only permitted write target is `docs/adr/`. Evaluate whether the proposed change affects architecture, contracts, module boundaries, performance, data flow, compatibility, deployment, or operational risk. When your evaluation concludes that a decision requires durable recording, author an ADR file.
+Do not implement or modify production code, tests, configs, or contracts. You are the owner for `specs/changes/<change-id>/design.md`. Your primary write target is `specs/changes/<change-id>/design.md`. You may also write an ADR under `docs/adr/` when the ADR rule below applies. Evaluate whether the proposed change affects architecture, contracts, module boundaries, performance, data flow, compatibility, deployment, or operational risk.
 
 ## ADR rule
 

package/assets/agents/spec-drift-auditor.md

@@ -33,6 +33,14 @@ By default, do NOT read `specs/changes/` history. Only read historical change re
 
 ## Output
 
+Default output is a concise drift verdict in your response plus an optional
+`Agent Log` YAML block with evidence pointers. Do not create standalone drift
+markdown for a clean audit.
+
+Emit a full `# Spec Drift Audit` body only when drift is found, when the user
+asked for standalone audit documentation, or when classification requires
+`regression-report.md`.
+
 ```md
 # Spec Drift Audit
 

package/assets/agents/stress-soak-engineer.md

@@ -37,8 +37,17 @@ Before editing tests or load profiles, read `specs/changes/<change-id>/implement
 
 ## Output
 
+Write or update the actual load/soak test files, profiles, commands, and
+workflow wiring required by `implementation-plan.md` and `test-plan.md`.
+Default reporting should be concise response text plus optional
+`agent-log/*.yml` evidence pointers.
+
+Create `stress-soak-report.md` only when `change-classification.md` explicitly
+requires it, when high-risk load/soak results must be retained as durable
+evidence, or when the run is blocked/failed.
+
 ```md
-# Stress / Soak Plan or Report
+# Stress / Soak Report
 
 ## Workload Model
 ...

package/assets/agents/test-strategist.md

@@ -60,6 +60,7 @@ Your output goes into `specs/changes/<id>/test-plan.md`. It must answer WHAT to
 - **DO NOT** write: mock setup details, fixture data, or expected JSON payloads
 - **DO NOT** write: per-test input/output tables with more than 15 rows
 - **DO NOT** write: example assertions or test helper code
+- **DO NOT** duplicate CI gate policy or implementation-plan execution steps; reference the relevant gate names and acceptance criteria instead.
 
 Implementation detail belongs in the test files, not in test-plan.md.
 Target: `test-plan.md` ??100 lines.

package/assets/agents/ui-ux-reviewer.md

@@ -30,6 +30,13 @@ Review the intended interaction, not just whether code compiles.
 
 ## Output
 
+Default output is a concise UI/UX verdict in your response plus an optional
+`Agent Log` YAML block with evidence pointers. Do not ask main Claude to create
+a separate markdown report for a routine approved review.
+
+Emit a full review body only when blocking UX/accessibility issues require
+durable prose or the classifier explicitly requested a report artifact.
+
 ```md
 # UI/UX Review
 

package/assets/agents/visual-reviewer.md

@@ -27,6 +27,15 @@ Frontend visual changes require evidence. Use screenshots, videos, or a clear ma
 
 ## Output
 
+Default output is a concise visual verdict in your response plus an optional
+`Agent Log` YAML block with evidence pointers. Do not ask main Claude to create
+`visual-review-report.md` for a routine approved UI change.
+
+Emit a full `# Visual Review Report` body only when
+`change-classification.md` explicitly requires `visual-review-report.md`, when
+visual evidence must be preserved as a bundle, or when the decision is
+`changes-required`.
+
 ```md
 # Visual Review Report
 

package/assets/skills/cdd-new/SKILL.md

@@ -12,9 +12,32 @@ description: Start a new tracked change. Scaffolds all required artifacts, class
 - `specs/changes/<id>/` = why we decided this back then (passive archive ??read only when investigating history, never as input to planning)
 - `CLAUDE.md` = what this project is and how to start work
 
-## Spec depth rules
+## Artifact ownership and deduplication
 
-Every artifact under `specs/changes/<id>/` answers **WHAT** and **WHY**, not HOW.
+Every artifact under `specs/changes/<id>/` must have one authoritative job.
+Do not duplicate the same fact across multiple markdown files. Later artifacts
+must reference earlier artifacts by path, section, criterion id, or decision id
+instead of restating full content.
+
+Core artifacts:
+
+| artifact | authority |
+|---|---|
+| `change-classification.md` | risk, tier, required agents, required artifacts, acceptance criteria, context-manifest draft |
+| `context-manifest.md` | read boundary and approved context |
+| `test-plan.md` | acceptance criterion to test family/file mapping |
+| `ci-gates.md` | required/informational/manual gates and promotion policy |
+| `design.md` | architecture/design decisions, only when required |
+| `implementation-plan.md` | concise execution packet that references the above artifacts |
+| `tasks.yml` | centralized task status only |
+
+Evidence and review notes default to short optional `agent-log/*.yml` pointers.
+Create report markdown (`qa-report.md`, `visual-review-report.md`,
+`regression-report.md`, `monkey-test-report.md`, `stress-soak-report.md`) only
+when the classifier explicitly requires it, or when a reviewer finds blocking
+findings or approved-with-risk evidence that needs durable review prose.
+
+Every spec artifact answers **WHAT** and **WHY**, not HOW.
 
 Soft caps (guidance, not gate-enforced):
 - `spec.md` ??200 lines
@@ -112,11 +135,23 @@ rules to `contracts/` or project guidance (`CLAUDE.md`/`CODEX.md`).
 
 ## Artifact opt-in policy
 
-Only create optional artifacts (`current-behavior.md`, `proposal.md`, `spec.md`, `design.md`, `qa-report.md`, `regression-report.md`) when the classifier's `change-classification.md` explicitly marks them as `yes`.
+Only create optional artifacts (`current-behavior.md`, `proposal.md`, `spec.md`,
+`design.md`, `qa-report.md`, `regression-report.md`, `visual-review-report.md`,
+`monkey-test-report.md`, `stress-soak-report.md`) when the classifier's
+`change-classification.md` explicitly marks them as `yes`, or when a reviewer
+finds blocking findings / approved-with-risk evidence that must be preserved as prose.
+
+`design.md` is owned by `spec-architect`, not `implementation-planner`. If the
+classifier marks `design.md` as `yes`, marks `Architecture Review Required:
+yes`, or lists `spec-architect` in `## Required Agents`, invoke
+`spec-architect` before `implementation-planner`. If none of those triggers is
+present, mark task `1.3` as `skipped`.
 
 Note: `archive.md` is created during `/cdd-close`, not during `/cdd-new` ??it is not part of the classifier's opt-in surface.
 
-If the classifier marks an artifact as `no` or leaves it blank, **do not create the file** ??even if a review agent could contribute to it.
+If the classifier marks an artifact as `no` or leaves it blank, **do not create
+the file** just because an agent could contribute to it. Use an optional
+`agent-log/*.yml` pointer instead.
 
 The 7 always-required artifacts are: `change-request.md`, `change-classification.md`, `implementation-plan.md`, `test-plan.md`, `ci-gates.md`, `tasks.yml`, and `context-manifest.md`.
 
@@ -158,7 +193,7 @@ the kit and is bundled into every install.
 |---|---|---|
 | `change-request.md` | `specs/templates/change-request.md` | Fill the `## Original Request` section with the user's exact description before invoking the classifier; leave the rest blank |
 | `change-classification.md` | `specs/templates/change-classification.md` | Replace blank template with classifier output (Step 2) |
-| `implementation-plan.md` | `specs/templates/implementation-plan.md` | `implementation-planner` writes this directly after contracts, tests, design, and CI gate plan are known |
+| `implementation-plan.md` | `specs/templates/implementation-plan.md` | `implementation-planner` writes this directly after contracts, tests, required design, and CI gate plan are known |
 | `test-plan.md` | `specs/templates/test-plan.md` | `test-strategist` writes this directly |
 | `ci-gates.md` | `specs/templates/ci-gates.md` | `ci-cd-gatekeeper` writes this directly |
 | `tasks.yml` | `specs/templates/tasks.yml` | Tick checkboxes as agents complete; backfill `tier:` frontmatter from classifier (Step 2.4) |
@@ -239,7 +274,11 @@ Wait until these five writes are done before continuing.
 
 Read `change-classification.md` to determine the tier. Then invoke agents **in the exact order below**.
 
-**For each read-only agent**: wait for its text response ??YOU write its artifact file(s) ??YOU write an optional handoff note when useful ??YOU tick relevant tasks.yml item(s).
+**For each read-only agent**: wait for its text response. YOU write a report
+artifact only if the classifier required that report or the agent found
+blocking findings / approved-with-risk evidence that needs durable prose. Otherwise
+write at most a short optional handoff note, then tick relevant `tasks.yml`
+item(s).
 
 **For each write-capable agent**: wait for it to confirm completion ??YOU tick relevant tasks.yml item(s).
 
@@ -269,8 +308,9 @@ agent:
 - confirm required artifacts exist; optional handoff notes are not gate inputs
 - if the agent reports `blocked`, halt and surface its concrete next action
 - tick the owned `tasks.yml` items immediately
-- record incidental/pre-existing findings in the appropriate report instead of
-  silently fixing unrelated scope
+- record incidental/pre-existing findings in `agent-log/*.yml`; escalate to
+  `qa-report.md` or `regression-report.md` only when the finding blocks release,
+  changes the QA decision, or needs durable follow-up ownership
 
 ### Agent stage badges (UI v1)
 
@@ -348,16 +388,20 @@ prompt; the agent's behavior is defined by the agent prompt files in
    - YOU tick: applicable items in section 3 based on what test families were planned
    - Provide the classifier's `## Inferred Acceptance Criteria` list to test-strategist. These become the `criterion id` column in the Acceptance Criteria ??Test Mapping table.
 
-3. **`spec-architect`** (write-capable) ??only if `change-classification.md` contains `Architecture Review Required: yes`.
-   - YOU tick: `1.3` (if it produced a gate plan)
+3. **`spec-architect`** (write-capable) ??only if `change-classification.md` contains `Architecture Review Required: yes`, marks `design.md` as `yes`, or lists `spec-architect` in `## Required Agents`.
+   - Writes `specs/changes/<change-id>/design.md` directly. This is the design/architecture decision record consumed by `implementation-planner`.
+   - YOU tick: `1.3`
+   - If the classifier did not require design, YOU mark `1.3` as `skipped` before continuing.
 
 4. **`ci-cd-gatekeeper`** (write-capable) ??writes `specs/changes/<change-id>/ci-gates.md` directly before implementation planning.
-   - YOU tick: `1.3`, `4.4`, applicable items in section 6
+   - YOU tick: `1.4`, `4.4`, applicable items in section 6
 
-5. **`implementation-planner`** (write-capable) ??writes `specs/changes/<change-id>/implementation-plan.md` directly after classification, contracts, test plan, design, and CI gate plan are available.
+5. **`implementation-planner`** (write-capable) ??writes `specs/changes/<change-id>/implementation-plan.md` directly after classification, contracts, test plan, required design, and CI gate plan are available.
    - This is the handoff packet for implementation agents. It should contain execution scope, non-goals, required changes, file-level plan, contract updates, test execution plan, and constraints.
+   - It must reference `test-plan.md`, `ci-gates.md`, contracts, and `design.md` by path/section/id instead of copying their full content.
+   - It must not create or repair `design.md`. If required design is missing, route back to `spec-architect`.
    - If it reports `blocked`, halt and surface the missing decision/context to the user.
-   - YOU tick: `1.4`
+   - YOU tick: `1.5`
 
 6. **`backend-engineer`** (write-capable) ??if the change touches server, API, data, or business logic. Writes implementation directly; may write an optional handoff note.
    - YOU tick: `4.1` and/or `4.3` based on scope
@@ -409,7 +453,8 @@ All agents from Tier 2??, plus insert these after `frontend-engineer` / `backend
 - If a required or informational test has pre-existing failures unrelated to
   this change, do not count them as this change's pass/fail result. Record the
   failing test id, baseline commit or prior evidence, owner, and follow-up in
-  `qa-report.md`; QA may only approve this as `approved-with-risk`.
+  optional `agent-log/*.yml`; create `qa-report.md` only when the QA decision is
+  `approved-with-risk` or `blocked`.
 - If implementation uncovers unrelated old bugs, fix only those needed to meet
   this change's acceptance criteria or to avoid a new safety/security risk.
   Otherwise record them as follow-up with evidence and owner.
@@ -490,7 +535,7 @@ Gate: PASSED
 Tasks completed:
 - [x] all applicable items have status: done in specs/changes/<change-id>/tasks.yml
 
-All artifacts written to: specs/changes/<change-id>/
+Core artifacts written to: specs/changes/<change-id>/
 
 Next step:
   git add specs/changes/<change-id>/
@@ -518,7 +563,7 @@ Please review the above items and re-run: cdd-kit gate <change-id>
 ## Rules
 
 - Never start implementation (backend/frontend-engineer) before `contract-reviewer` has completed for Tier 0?? changes
-- Never start implementation (backend/frontend-engineer or dedicated test engineers) before `implementation-plan.md` exists and `tasks.yml` item `1.4` is done
+- Never start implementation (backend/frontend-engineer or dedicated test engineers) before `implementation-plan.md` exists and `tasks.yml` item `1.5` is done
 - Never skip `test-plan.md` for Tier 0?? changes
 - Never skip `ci-gates.md` for any implementation change
 - Agent logs are optional; do not create them just to satisfy a gate.

package/assets/skills/cdd-resume/SKILL.md

@@ -42,6 +42,7 @@ Read only these state files first:
 - `specs/changes/<change-id>/context-manifest.md` if present
 - `specs/changes/<change-id>/agent-log/*.yml`
 - `specs/changes/<change-id>/change-classification.md`
+- `specs/changes/<change-id>/design.md` if present
 - `specs/changes/<change-id>/implementation-plan.md` if present
 
 Do not run broad repository search during resume. Do not read `src/`, `tests/`, or `contracts/` unless the current `context-manifest.md` authorizes that path or an approved expansion lists it.
@@ -55,6 +56,8 @@ Read `specs/changes/<change-id>/agent-log/` to list which agents have already ru
 
 Read `specs/changes/<change-id>/change-classification.md` to recall the tier and required agents.
 
+If `change-classification.md` requires `design.md` (`Architecture Review Required: yes`, Optional Artifacts `design.md: yes`, or Required Agents includes `spec-architect`) and `design.md` is missing or still a scaffold, resume from `spec-architect` before invoking `implementation-planner`.
+
 Read `specs/changes/<change-id>/implementation-plan.md` if it exists. If implementation tasks are still pending and the plan is missing or still a scaffold, resume from `implementation-planner` before invoking backend/frontend/test implementation agents.
 
 Read `specs/changes/<change-id>/context-manifest.md`:
@@ -114,6 +117,7 @@ Continue until all required agents are done, then run `cdd-kit gate <change-id>`
 - Never start from Step 1 of `/cdd-new` — only resume from the next pending agent
 - Never use broad search to reconstruct state; resume from `tasks.yml`, `context-manifest.md`, and `agent-log/`
 - Never continue past pending Context Expansion Requests
+- Never resume `implementation-planner` before required `design.md` exists
 - Never resume backend/frontend/test implementation agents before `implementation-plan.md` is ready
 - If tasks.yml has `status: abandoned`, report to user and stop
 - If tasks.yml has `status: gate-blocked`, go directly to gate retry (max 3)

package/assets/skills/contract-driven-delivery/SKILL.md

@@ -22,6 +22,13 @@ Use this skill to turn software requests into traceable, testable, CI/CD-gated c
 3. Select required artifacts.
    - Use templates in `templates/`.
    - Do not force every artifact for tiny changes, but do require `change-classification.md`, `implementation-plan.md`, `test-plan.md`, and `ci-gates.md` for implementation changes.
+   - Keep each fact in one authoritative artifact. Later artifacts should
+     reference earlier artifacts by path, section, criterion id, decision id, or
+     gate name instead of duplicating full prose.
+   - Use optional `agent-log/*.yml` pointers for routine review evidence.
+     Create report markdown only for blocking findings, approved-with-risk,
+     excluded pre-existing failures, visual evidence bundles, or high-risk
+     load/soak results.
 4. Update contracts before or alongside implementation. Invoke contract-reviewer to validate API/CSS/env/data/business/CI-CD contracts before or alongside implementation.
    - API: `references/api-contract-standard.md`
    - CSS/UI: `references/css-contract-standard.md`
@@ -39,12 +46,16 @@ Use this skill to turn software requests into traceable, testable, CI/CD-gated c
    - `stress-soak-engineer` implements load, soak, and long-running stability tests.
    - Invoke the relevant test engineer(s) before or alongside implementation based on the risk tier.
    - Each engineer must read the matching standard before authoring tests: e2e-resilience-engineer → references/e2e-standard.md, monkey-test-engineer → references/monkey-operation-standard.md, stress-soak-engineer → references/stress-soak-standard.md.
-6. Produce the implementation plan.
-   - Invoke `implementation-planner` after classification, contracts, test-plan, design (if any), and CI gate plan are known.
+6. Confirm design decisions when required.
+   - If classification marks `Architecture Review Required: yes`, Optional Artifacts `design.md: yes`, or Required Agents includes `spec-architect`, invoke `spec-architect` before `implementation-planner`.
+   - `spec-architect` owns `specs/changes/<id>/design.md`.
+   - `implementation-planner` must not create or repair `design.md`; if required design is missing, route back to `spec-architect`.
+7. Produce the implementation plan.
+   - Invoke `implementation-planner` after classification, contracts, test-plan, required design, and CI gate plan are known.
    - `implementation-plan.md` is the execution packet for implementation agents: scope, non-goals, file-level plan, contract updates, tests, acceptance criteria, and constraints.
    - Keep the plan concise. It should not duplicate the full investigation history or user discussion.
    - If the planner reports missing decisions or context, stop before implementation and resolve that gap.
-7. Implement through the right role.
+8. Implement through the right role.
    - Backend/frontend work must follow contracts and tests.
    - Backend/frontend/test implementation agents must read `implementation-plan.md` and should report `blocked` instead of inferring missing requirements from chat history.
    - Before invoking an agent with known concrete read paths, run
@@ -56,12 +67,12 @@ Use this skill to turn software requests into traceable, testable, CI/CD-gated c
    - Invoke ui-ux-reviewer for interaction, copy, accessibility, and information hierarchy review whenever UI changes.
    - Invoke visual-reviewer for layout, responsive, CSS contract, and screenshot diff review whenever UI changes.
    - If implementation reveals an unexpected boundary or architectural constraint, halt and re-invoke `spec-architect` before continuing.
-8. Run quality gates.
+9. Run quality gates.
    - Use `references/qa-gates.md`.
    - CI/CD gate plan is mandatory.
    - `qa-reviewer` decides release readiness; Tier 1 gates must be green; Tier 3+ gates must be green or explicitly deferred with a recorded promotion policy.
    - Invoke ci-cd-gatekeeper to design and enforce the gate plan.
-9. Archive and audit drift.
+10. Archive and audit drift.
    - Use `references/spec-drift-policy.md`.
    - General agents record evidence and findings only; durable learning
      promotion happens only during `/cdd-close` Step 3.
@@ -87,7 +98,7 @@ Use this skill to turn software requests into traceable, testable, CI/CD-gated c
 - test-plan
 - ci-gates
 - tasks
-- QA report
+- QA verdict; `qa-report.md` only when blocked, approved-with-risk, or required by classification
 
 ### UI change
 
@@ -121,6 +132,10 @@ Required when the change involves report generation, large queries, auto-refresh
 
 When using this skill, produce concrete artifact content instead of vague recommendations. Include exact files to create/update, exact gates to run, exact commands if detectable, and exact acceptance criteria.
 
+Avoid artifact sprawl: do not create optional markdown when a concise verdict
+or `agent-log/*.yml` pointer is enough. Do not duplicate full test strategy,
+CI policy, design rationale, or contract prose across artifacts.
+
 ## Scripts
 
 - `scripts/detect_project_profile.py`: inspect a repository and emit a Markdown project profile.
@@ -137,4 +152,6 @@ Run scripts with Python 3 from the repository root.
 - `tasks.yml`: structured YAML, validated by `src/schemas/tasks.schema.ts`.
 - `agent-log/<agent>.yml`: optional structured handoff note per `references/agent-log-protocol.md`.
 - `implementation-plan.md`: required execution handoff for implementation agents.
-- All other change artifacts remain markdown prose.
+- Report markdown is optional and reserved for durable review evidence. Routine
+  pass/fail evidence belongs in short `agent-log/*.yml` pointers or the final
+  assistant summary.

package/assets/skills/contract-driven-delivery/references/qa-gates.md

@@ -20,7 +20,11 @@
 
 ## QA rule
 
-QA approval requires evidence. Evidence may be command output, CI links, logs, screenshots, videos, traces, metrics, or artifact files.
+QA approval requires evidence. Evidence may be command output, CI links, logs,
+screenshots, videos, traces, metrics, or artifact files. Routine approvals
+should use concise verdict text plus optional `agent-log/*.yml` pointers.
+Create `qa-report.md` only for blocked, approved-with-risk, or excluded
+pre-existing failure decisions.
 
 ## Fixback rule
 

package/assets/skills/contract-driven-delivery/references/spec-drift-policy.md

@@ -25,4 +25,7 @@ Run a drift audit when:
 
 ## Output
 
-Use `templates/regression-report.md` or create `spec-drift-audit.md` when the audit is standalone.
+Use concise verdict text plus optional `agent-log/*.yml` evidence pointers for
+clean audits. Use `templates/regression-report.md` or create
+`spec-drift-audit.md` only when drift is found, the user asked for standalone
+audit documentation, or the change needs durable follow-up prose.

package/assets/skills/contract-driven-delivery/references/stress-soak-standard.md

@@ -40,3 +40,7 @@ Define:
 - raw logs or metrics
 - pass/fail conclusion
 - follow-up issues for degraded but non-blocking findings
+
+Routine results may be captured as concise response text plus optional
+`agent-log/*.yml` pointers. Create `stress-soak-report.md` only for required
+high-risk evidence, failed/blocked runs, or approved-with-risk decisions.

package/assets/skills/contract-driven-delivery/references/visual-review-standard.md

@@ -24,4 +24,7 @@ Visual review is required when frontend output changes.
 
 ## Review output
 
-Use `templates/visual-review-report.md`.
+Use concise verdict text plus optional `agent-log/*.yml` evidence pointers for
+routine approvals. Use `templates/visual-review-report.md` only for blocking
+visual findings, approved-with-risk decisions, or evidence bundles that need
+durable review prose.

package/assets/skills/contract-driven-delivery/scripts/generate_change_scaffold.py

@@ -9,27 +9,36 @@ def main():
     ap.add_argument('change_id')
     ap.add_argument('--root', default='.')
     ap.add_argument('--templates', default=None)
+    ap.add_argument('--all', action='store_true', help='also copy optional report/spec templates')
     args=ap.parse_args()
     root=Path(args.root).resolve()
     templates=Path(args.templates).resolve() if args.templates else Path(__file__).resolve().parents[1]/'templates'
     dest=root/'specs'/'changes'/args.change_id
     dest.mkdir(parents=True, exist_ok=False)
-    mapping={
+    required={
         'change-request.md':'change-request.md',
         'change-classification.md':'change-classification.md',
         'implementation-plan.md':'implementation-plan.md',
+        'test-plan.md':'test-plan.md',
+        'ci-gates.md':'ci-gates.md',
+        'tasks.yml':'tasks.yml',
+    }
+    optional={
         'current-behavior.md':'current-behavior.md',
         'proposal.md':'proposal.md',
         'spec.md':'spec.md',
         'design.md':'design.md',
         'contracts.md':'contracts.md',
-        'test-plan.md':'test-plan.md',
-        'ci-gates.md':'ci-gates.md',
-        'tasks.yml':'tasks.yml',
         'qa-report.md':'qa-report.md',
         'regression-report.md':'regression-report.md',
+        'visual-review-report.md':'visual-review-report.md',
+        'monkey-test-report.md':'monkey-test-report.md',
+        'stress-soak-report.md':'stress-soak-report.md',
         'archive.md':'archive.md',
     }
+    mapping=dict(required)
+    if args.all:
+        mapping.update(optional)
     for src,dst in mapping.items():
         s=templates/src
         if s.exists():

package/assets/skills/contract-driven-delivery/templates/change-classification.md

@@ -16,6 +16,7 @@
 ## Architecture Review Required
 - yes / no
 - reason: (fill only if yes)
+<!-- If yes, Optional Artifacts must set design.md to yes and Required Agents must include spec-architect. -->
 
 ## Required Artifacts
 Always required: change-request.md, change-classification.md, implementation-plan.md, test-plan.md, ci-gates.md, tasks.yml, context-manifest.md
@@ -29,6 +30,14 @@ Always required: change-request.md, change-classification.md, implementation-pla
 | design.md | no | |
 | qa-report.md | no | |
 | regression-report.md | no | |
+| visual-review-report.md | no | |
+| monkey-test-report.md | no | |
+| stress-soak-report.md | no | |
+
+Artifact minimization:
+- Prefer optional `agent-log/*.yml` pointers for routine review evidence.
+- Create report markdown only for blocking findings, approved-with-risk, excluded pre-existing failures, visual evidence bundles, or high-risk load/soak results.
+- Later artifacts should reference earlier artifacts by path/section/id instead of duplicating full content.
 
 ## Required Contracts
 - API:
@@ -61,7 +70,8 @@ Always required: change-request.md, change-classification.md, implementation-pla
 
 ## Tasks Not Applicable
 <!-- Comma-separated task IDs from tasks.yml that do NOT apply to this change.
-     /cdd-new SKILL marks these as `status: skipped` in tasks.yml. -->
+     /cdd-new SKILL marks these as `status: skipped` in tasks.yml.
+     Include 1.3 when design.md is not required. -->
 - not-applicable:
 
 ## Clarifications or Assumptions

package/assets/skills/contract-driven-delivery/templates/ci-gates.md

@@ -29,3 +29,7 @@
 ## Artifact Retention
 
 ## Merge Eligibility Decision
+
+## Notes
+
+Reference test-plan.md rows or gate names instead of duplicating full test strategy.

package/assets/skills/contract-driven-delivery/templates/implementation-plan.md

@@ -24,6 +24,14 @@ last-changed: <date>
 |---|---|---|---|
 | IP-1 |  |  |  |
 
+## Source Artifact Pointers
+
+| source | relevant pointer | used for |
+|---|---|---|
+| test-plan.md | AC-1 | tests to run/write |
+| ci-gates.md | required gates table | verification commands |
+| design.md | Decision:  | implementation constraint |
+
 ## File-Level Plan
 
 | path or glob | action | notes |
@@ -48,6 +56,7 @@ last-changed: <date>
 ## Handoff Constraints
 
 - Implementation agents must not infer missing requirements from chat history.
+- Do not re-copy full design, test strategy, CI policy, or contract prose into this plan; follow the source pointers above.
 - If this plan omits a required file, behavior, contract, or test, stop and report `blocked`.
 - Keep implementation within the file-level plan unless a Context Expansion Request is approved.
 

package/assets/skills/contract-driven-delivery/templates/tasks.yml

@@ -11,8 +11,9 @@ tasks:
   # status: pending | done | skipped
   - { id: "1.1", section: Preparation, title: "Confirm classification and required artifacts", status: pending }
   - { id: "1.2", section: Preparation, title: "Confirm contracts to update", status: pending }
-  - { id: "1.3", section: Preparation, title: "Confirm CI/CD gate plan", status: pending }
-  - { id: "1.4", section: Preparation, title: "Confirm implementation plan", status: pending }
+  - { id: "1.3", section: Preparation, title: "Confirm design decisions if required", status: pending }
+  - { id: "1.4", section: Preparation, title: "Confirm CI/CD gate plan", status: pending }
+  - { id: "1.5", section: Preparation, title: "Confirm implementation plan", status: pending }
   - { id: "2.1", section: "Contract Updates", title: "API contract", status: pending }
   - { id: "2.2", section: "Contract Updates", title: "CSS/UI contract", status: pending }
   - { id: "2.3", section: "Contract Updates", title: "Env contract", status: pending }

package/assets/skills/contract-driven-delivery/templates/test-plan.md

@@ -22,4 +22,4 @@ Mark all that apply: unit / contract / integration / e2e / data-boundary / resil
 
 ## Notes
 
-(Keep this section under 10 lines. Implementation detail belongs in the test files themselves.)
+(Keep this section under 10 lines. Implementation detail belongs in the test files themselves. Do not repeat full implementation-plan or CI-gate content here.)

package/assets/specs-templates/change-classification.md

@@ -16,6 +16,7 @@
 ## Architecture Review Required
 - yes / no
 - reason: (fill only if yes)
+<!-- If yes, Optional Artifacts must set design.md to yes and Required Agents must include spec-architect. -->
 
 ## Required Artifacts
 Always required: change-request.md, change-classification.md, implementation-plan.md, test-plan.md, ci-gates.md, tasks.yml, context-manifest.md
@@ -29,6 +30,14 @@ Always required: change-request.md, change-classification.md, implementation-pla
 | design.md | no | |
 | qa-report.md | no | |
 | regression-report.md | no | |
+| visual-review-report.md | no | |
+| monkey-test-report.md | no | |
+| stress-soak-report.md | no | |
+
+Artifact minimization:
+- Prefer optional `agent-log/*.yml` pointers for routine review evidence.
+- Create report markdown only for blocking findings, approved-with-risk, excluded pre-existing failures, visual evidence bundles, or high-risk load/soak results.
+- Later artifacts should reference earlier artifacts by path/section/id instead of duplicating full content.
 
 ## Required Contracts
 - API:
@@ -61,7 +70,8 @@ Always required: change-request.md, change-classification.md, implementation-pla
 
 ## Tasks Not Applicable
 <!-- Comma-separated task IDs from tasks.yml that do NOT apply to this change.
-     /cdd-new SKILL marks these as `status: skipped` in tasks.yml. -->
+     /cdd-new SKILL marks these as `status: skipped` in tasks.yml.
+     Include 1.3 when design.md is not required. -->
 - not-applicable:
 
 ## Clarifications or Assumptions

package/assets/specs-templates/ci-gates.md

@@ -29,3 +29,7 @@
 ## Artifact Retention
 
 ## Merge Eligibility Decision
+
+## Notes
+
+Reference test-plan.md rows or gate names instead of duplicating full test strategy.

package/assets/specs-templates/implementation-plan.md

@@ -24,6 +24,14 @@ last-changed: <date>
 |---|---|---|---|
 | IP-1 |  |  |  |
 
+## Source Artifact Pointers
+
+| source | relevant pointer | used for |
+|---|---|---|
+| test-plan.md | AC-1 | tests to run/write |
+| ci-gates.md | required gates table | verification commands |
+| design.md | Decision:  | implementation constraint |
+
 ## File-Level Plan
 
 | path or glob | action | notes |
@@ -48,6 +56,7 @@ last-changed: <date>
 ## Handoff Constraints
 
 - Implementation agents must not infer missing requirements from chat history.
+- Do not re-copy full design, test strategy, CI policy, or contract prose into this plan; follow the source pointers above.
 - If this plan omits a required file, behavior, contract, or test, stop and report `blocked`.
 - Keep implementation within the file-level plan unless a Context Expansion Request is approved.
 

package/assets/specs-templates/tasks.yml

@@ -11,8 +11,9 @@ tasks:
   # status: pending | done | skipped   (optional: note: "reason or context")
   - { id: "1.1", section: Preparation, title: "Confirm classification and required artifacts", status: pending }
   - { id: "1.2", section: Preparation, title: "Confirm contracts to update", status: pending }
-  - { id: "1.3", section: Preparation, title: "Confirm CI/CD gate plan", status: pending }
-  - { id: "1.4", section: Preparation, title: "Confirm implementation plan", status: pending }
+  - { id: "1.3", section: Preparation, title: "Confirm design decisions if required", status: pending }
+  - { id: "1.4", section: Preparation, title: "Confirm CI/CD gate plan", status: pending }
+  - { id: "1.5", section: Preparation, title: "Confirm implementation plan", status: pending }
   - { id: "2.1", section: "Contract Updates", title: "API contract", status: pending }
   - { id: "2.2", section: "Contract Updates", title: "CSS/UI contract", status: pending }
   - { id: "2.3", section: "Contract Updates", title: "Env contract", status: pending }

package/assets/specs-templates/test-plan.md

@@ -22,4 +22,4 @@ Mark all that apply: unit / contract / integration / e2e / data-boundary / resil
 
 ## Notes
 
-(Keep this section under 10 lines. Implementation detail belongs in the test files themselves.)
+(Keep this section under 10 lines. Implementation detail belongs in the test files themselves. Do not repeat full implementation-plan or CI-gate content here.)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "contract-driven-delivery",
-  "version": "2.0.18",
+  "version": "2.0.19",
   "description": "Contract-driven delivery kit for AI coding agents with deterministic context indexes, manifest-backed read-scope governance, and orchestrated contracts-first delivery.",
   "keywords": [
     "contract-driven",