codexspec 0.7.8__tar.gz → 0.7.9__tar.gz

{codexspec-0.7.8 → codexspec-0.7.9}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: codexspec
-Version: 0.7.8
+Version: 0.7.9
 Summary: CodexSpec - A Requirements-First SDD toolkit for Claude Code
 Project-URL: Homepage, https://github.com/Zts0hg/codexspec
 Project-URL: Repository, https://github.com/Zts0hg/codexspec
@@ -166,9 +166,12 @@ CodexSpec is built on the belief that **effective AI-assisted development requir
 CodexSpec structures development into **reviewable checkpoints**:
 
 ```
-Idea → /specify → requirements.md → /generate-spec → spec.md → /spec-to-plan → plan.md → /plan-to-tasks → tasks.md → /implement
-                                                   │                         │                            │
-                                              Review spec               Review plan                  Review tasks
+Idea → /specify           → requirements.md
+     → /generate-spec      → spec.md      → review-spec
+     → /spec-to-design     → design.md    → review-design
+     → /spec-to-plan       → plan.md      → review-plan
+     → /plan-to-tasks      → tasks.md     → review-tasks
+     → /implement-tasks    → code
 ```
 
 Confirmed requirements are the highest-priority feature authority. Derived artifacts carry explicit source links so conflicts can be traced back instead of silently propagated.
@@ -176,6 +179,7 @@ Confirmed requirements are the highest-priority feature authority. Derived artif
 **Every generated artifact has a corresponding review command:**
 
 - `spec.md` → `/codexspec:review-spec`
+- `design.md` → `/codexspec:review-design`
 - `plan.md` → `/codexspec:review-plan`
 - `tasks.md` → `/codexspec:review-tasks`
 - All artifacts → `/codexspec:analyze`
@@ -207,6 +211,7 @@ claude
 > /codexspec:constitution Create principles focused on code quality and testing
 > /codexspec:specify I want to build a todo application
 > /codexspec:generate-spec
+> /codexspec:spec-to-design
 > /codexspec:spec-to-plan
 > /codexspec:plan-to-tasks
 > /codexspec:implement-tasks
@@ -355,9 +360,12 @@ The config command will guide you through:
 CodexSpec breaks development into **reviewable checkpoints**:
 
 ```
-Idea → /specify → requirements.md → /generate-spec → spec.md → /spec-to-plan → plan.md → /plan-to-tasks → tasks.md → /implement
-                                                   │                         │                            │
-                                              Review spec               Review plan                  Review tasks
+Idea → /specify           → requirements.md
+     → /generate-spec      → spec.md      → review-spec
+     → /spec-to-design     → design.md    → review-design
+     → /spec-to-plan       → plan.md      → review-plan
+     → /plan-to-tasks      → tasks.md     → review-tasks
+     → /implement-tasks    → code
 ```
 
 ### Workflow Steps
@@ -367,10 +375,11 @@ Idea → /specify → requirements.md → /generate-spec → spec.md → /spec-t
 | 1. Project Principles        | `/codexspec:constitution`    | `constitution.md`           | ✅           |
 | 2. Requirement Clarification | `/codexspec:specify`         | `requirements.md`           | ✅           |
 | 3. Generate Spec             | `/codexspec:generate-spec`   | `spec.md` + auto-review     | ✅           |
-| 4. Technical Planning        | `/codexspec:spec-to-plan`    | `plan.md` + auto-review     | ✅           |
-| 5. Task Breakdown            | `/codexspec:plan-to-tasks`   | `tasks.md` + auto-review    | ✅           |
-| 6. Cross-Artifact Analysis   | `/codexspec:analyze`         | Analysis report             | ✅           |
-| 7. Implementation            | `/codexspec:implement-tasks` | Code                        | -           |
+| 4. System Design             | `/codexspec:spec-to-design`  | `design.md` + auto-review   | ✅           |
+| 5. Technical Planning        | `/codexspec:spec-to-plan`    | `plan.md` + auto-review     | ✅           |
+| 6. Task Breakdown            | `/codexspec:plan-to-tasks`   | `tasks.md` + auto-review    | ✅           |
+| 7. Cross-Artifact Analysis   | `/codexspec:analyze`         | Analysis report             | ✅           |
+| 8. Implementation            | `/codexspec:implement-tasks` | Code                        | -           |
 
 ### specify vs clarify: When to Use Which?
 
@@ -568,7 +577,8 @@ Implementation follows **conditional TDD workflow**:
 | `/codexspec:constitution`    | Create/update project constitution with cross-artifact validation |
 | `/codexspec:specify`         | Clarify, confirm, and persist requirements in `requirements.md`    |
 | `/codexspec:generate-spec`   | Generate `spec.md` document ★ Auto-review                         |
-| `/codexspec:spec-to-plan`    | Convert spec to technical plan ★ Auto-review                      |
+| `/codexspec:spec-to-design`  | Produce `design.md` (architecture/components/decisions) ★ Auto-review |
+| `/codexspec:spec-to-plan`    | Convert design to implementation plan ★ Auto-review              |
 | `/codexspec:plan-to-tasks`   | Break down plan into traceable, verifiable tasks ★ Auto-review    |
 | `/codexspec:implement-tasks` | Execute tasks (conditional TDD)                                   |
 
@@ -577,6 +587,7 @@ Implementation follows **conditional TDD workflow**:
 | Command                   | Description                            |
 | ------------------------- | -------------------------------------- |
 | `/codexspec:review-spec`  | Review specification (auto or manual)  |
+| `/codexspec:review-design` | Review design (auto or manual)        |
 | `/codexspec:review-plan`  | Review technical plan (auto or manual) |
 | `/codexspec:review-tasks` | Review task breakdown (auto or manual) |
 

{codexspec-0.7.8 → codexspec-0.7.9}/README.md

@@ -121,9 +121,12 @@ CodexSpec is built on the belief that **effective AI-assisted development requir
 CodexSpec structures development into **reviewable checkpoints**:
 
 ```
-Idea → /specify → requirements.md → /generate-spec → spec.md → /spec-to-plan → plan.md → /plan-to-tasks → tasks.md → /implement
-                                                   │                         │                            │
-                                              Review spec               Review plan                  Review tasks
+Idea → /specify           → requirements.md
+     → /generate-spec      → spec.md      → review-spec
+     → /spec-to-design     → design.md    → review-design
+     → /spec-to-plan       → plan.md      → review-plan
+     → /plan-to-tasks      → tasks.md     → review-tasks
+     → /implement-tasks    → code
 ```
 
 Confirmed requirements are the highest-priority feature authority. Derived artifacts carry explicit source links so conflicts can be traced back instead of silently propagated.
@@ -131,6 +134,7 @@ Confirmed requirements are the highest-priority feature authority. Derived artif
 **Every generated artifact has a corresponding review command:**
 
 - `spec.md` → `/codexspec:review-spec`
+- `design.md` → `/codexspec:review-design`
 - `plan.md` → `/codexspec:review-plan`
 - `tasks.md` → `/codexspec:review-tasks`
 - All artifacts → `/codexspec:analyze`
@@ -162,6 +166,7 @@ claude
 > /codexspec:constitution Create principles focused on code quality and testing
 > /codexspec:specify I want to build a todo application
 > /codexspec:generate-spec
+> /codexspec:spec-to-design
 > /codexspec:spec-to-plan
 > /codexspec:plan-to-tasks
 > /codexspec:implement-tasks
@@ -310,9 +315,12 @@ The config command will guide you through:
 CodexSpec breaks development into **reviewable checkpoints**:
 
 ```
-Idea → /specify → requirements.md → /generate-spec → spec.md → /spec-to-plan → plan.md → /plan-to-tasks → tasks.md → /implement
-                                                   │                         │                            │
-                                              Review spec               Review plan                  Review tasks
+Idea → /specify           → requirements.md
+     → /generate-spec      → spec.md      → review-spec
+     → /spec-to-design     → design.md    → review-design
+     → /spec-to-plan       → plan.md      → review-plan
+     → /plan-to-tasks      → tasks.md     → review-tasks
+     → /implement-tasks    → code
 ```
 
 ### Workflow Steps
@@ -322,10 +330,11 @@ Idea → /specify → requirements.md → /generate-spec → spec.md → /spec-t
 | 1. Project Principles        | `/codexspec:constitution`    | `constitution.md`           | ✅           |
 | 2. Requirement Clarification | `/codexspec:specify`         | `requirements.md`           | ✅           |
 | 3. Generate Spec             | `/codexspec:generate-spec`   | `spec.md` + auto-review     | ✅           |
-| 4. Technical Planning        | `/codexspec:spec-to-plan`    | `plan.md` + auto-review     | ✅           |
-| 5. Task Breakdown            | `/codexspec:plan-to-tasks`   | `tasks.md` + auto-review    | ✅           |
-| 6. Cross-Artifact Analysis   | `/codexspec:analyze`         | Analysis report             | ✅           |
-| 7. Implementation            | `/codexspec:implement-tasks` | Code                        | -           |
+| 4. System Design             | `/codexspec:spec-to-design`  | `design.md` + auto-review   | ✅           |
+| 5. Technical Planning        | `/codexspec:spec-to-plan`    | `plan.md` + auto-review     | ✅           |
+| 6. Task Breakdown            | `/codexspec:plan-to-tasks`   | `tasks.md` + auto-review    | ✅           |
+| 7. Cross-Artifact Analysis   | `/codexspec:analyze`         | Analysis report             | ✅           |
+| 8. Implementation            | `/codexspec:implement-tasks` | Code                        | -           |
 
 ### specify vs clarify: When to Use Which?
 
@@ -523,7 +532,8 @@ Implementation follows **conditional TDD workflow**:
 | `/codexspec:constitution`    | Create/update project constitution with cross-artifact validation |
 | `/codexspec:specify`         | Clarify, confirm, and persist requirements in `requirements.md`    |
 | `/codexspec:generate-spec`   | Generate `spec.md` document ★ Auto-review                         |
-| `/codexspec:spec-to-plan`    | Convert spec to technical plan ★ Auto-review                      |
+| `/codexspec:spec-to-design`  | Produce `design.md` (architecture/components/decisions) ★ Auto-review |
+| `/codexspec:spec-to-plan`    | Convert design to implementation plan ★ Auto-review              |
 | `/codexspec:plan-to-tasks`   | Break down plan into traceable, verifiable tasks ★ Auto-review    |
 | `/codexspec:implement-tasks` | Execute tasks (conditional TDD)                                   |
 
@@ -532,6 +542,7 @@ Implementation follows **conditional TDD workflow**:
 | Command                   | Description                            |
 | ------------------------- | -------------------------------------- |
 | `/codexspec:review-spec`  | Review specification (auto or manual)  |
+| `/codexspec:review-design` | Review design (auto or manual)        |
 | `/codexspec:review-plan`  | Review technical plan (auto or manual) |
 | `/codexspec:review-tasks` | Review task breakdown (auto or manual) |
 

{codexspec-0.7.8 → codexspec-0.7.9}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "codexspec"
-version = "0.7.8"
+version = "0.7.9"
 description = "CodexSpec - A Requirements-First SDD toolkit for Claude Code"
 readme = "README.md"
 requires-python = ">=3.11"

{codexspec-0.7.8 → codexspec-0.7.9}/src/codexspec/__init__.py

@@ -44,7 +44,7 @@ from .profile import ensure_profile_scaffold, inject_profile_block
 from .translator import SUPPORTED_LANGUAGES, translate
 
 # Version info
-__version__ = "0.7.8"
+__version__ = "0.7.9"
 __author__ = "CodexSpec Team"
 
 # Constitution file path constants

{codexspec-0.7.8 → codexspec-0.7.9}/src/codexspec/commands/installer.py

@@ -47,11 +47,11 @@ def get_commands_metadata() -> list[CommandMetadata]:
 
     Returns:
         List of CommandMetadata dictionaries sorted by category priority:
-        core (9) -> enhanced (7) -> git (2) -> review (1) -> utility (2)
-        Total: 21 commands
+        core (11) -> enhanced (7) -> git (2) -> review (1) -> utility (2)
+        Total: 23 commands
     """
     return [
-        # Core Commands (9)
+        # Core Commands (11)
         {
             "name": "constitution",
             "display_name": "/codexspec:constitution",
@@ -73,10 +73,17 @@ def get_commands_metadata() -> list[CommandMetadata]:
             "category": "core",
             "file_name": "generate-spec.md",
         },
+        {
+            "name": "spec-to-design",
+            "display_name": "/codexspec:spec-to-design",
+            "description": "将已确认的规格转换为可追溯的设计文档（架构/组件/关键设计决策）",
+            "category": "core",
+            "file_name": "spec-to-design.md",
+        },
         {
             "name": "spec-to-plan",
             "display_name": "/codexspec:spec-to-plan",
-            "description": "将已确认的规格转换为可追溯的技术计划",
+            "description": "将已确认的设计转换为可追溯的实现计划",
             "category": "core",
             "file_name": "spec-to-plan.md",
         },
@@ -94,6 +101,13 @@ def get_commands_metadata() -> list[CommandMetadata]:
             "category": "core",
             "file_name": "review-spec.md",
         },
+        {
+            "name": "review-design",
+            "display_name": "/codexspec:review-design",
+            "description": "审查设计的忠实度、可行性与规划就绪度",
+            "category": "core",
+            "file_name": "review-design.md",
+        },
         {
             "name": "review-plan",
             "display_name": "/codexspec:review-plan",

{codexspec-0.7.8 → codexspec-0.7.9}/src/codexspec/integrations/codex.py

@@ -115,6 +115,7 @@ Use these Codex skills when working on CodexSpec workflows:
 - `$codexspec:constitution` to create or update project principles.
 - `$codexspec:specify` to capture confirmed requirements.
 - `$codexspec:generate-spec` to produce `spec.md`.
+- `$codexspec:spec-to-design` to produce `design.md`.
 - `$codexspec:spec-to-plan` to produce `plan.md`.
 - `$codexspec:plan-to-tasks` to produce `tasks.md`.
 - `$codexspec:implement-tasks` to implement approved tasks.

{codexspec-0.7.8 → codexspec-0.7.9}/templates/commands/analyze.md

@@ -22,7 +22,7 @@ Converse in the interaction language and author artifacts in the document langua
 
 This command detects cross-artifact inconsistencies **and auto-remediates them**. It is not read-only.
 
-- `requirements.md` is the single source of truth. analyze **never modifies `requirements.md`**. Every fix conforms the downstream artifacts (`spec.md`, `plan.md`, `tasks.md`) to `requirements.md`; the fix direction is uniquely determined by the authority hierarchy (requirements > spec > plan > tasks) and never requires inventing intent.
+- `requirements.md` is the single source of truth. analyze **never modifies `requirements.md`**. Every fix conforms the downstream artifacts (`spec.md`, `design.md`, `plan.md`, `tasks.md`) to `requirements.md`; the fix direction is uniquely determined by the authority hierarchy (requirements > spec > design > plan > tasks) and never requires inventing intent.
 - Auto-apply deterministic, authority-directed fixes **by default** — both when invoked manually and when invoked inside the `auto_next` chain — with no confirmation prompt and no human-escalation path.
 
 Resolve the feature by explicit path, then current branch. Ask the user if it is ambiguous; never select the latest feature silently.
@@ -33,10 +33,13 @@ Load:
 
 - `requirements.md`
 - `spec.md`
+- `design.md`
 - `plan.md`
 - `tasks.md`
 - Constitution
 
+A legacy feature may have no `design.md`; when it is absent, analyze the chain without the design link and proceed.
+
 Legacy compatibility: if `requirements.md` is missing, state that the analysis starts at `spec.md` and cannot validate fidelity to the original discussion. In legacy mode there is no source of truth to conform to, so do not auto-modify artifacts; report findings only.
 
 ## End-to-End Traceability
@@ -46,7 +49,8 @@ Build the chain:
 ```text
 confirmed NEED/CON/DEC/OUT
   -> REQ/NFR Sources
-  -> plan Covers
+  -> design Covers
+  -> plan Covers (Covers: REQ; Design: <component>)
   -> task Covers + Plan reference
 ```
 
@@ -54,7 +58,8 @@ Detect:
 
 - Confirmed requirements with no spec coverage
 - Spec requirements with missing or invalid sources
-- Spec requirements with no plan coverage
+- Spec requirements with no design coverage
+- Design components with no plan coverage
 - Plan deliverables with no task coverage
 - Tasks with no upstream authority or implementation-support justification
 - Semantic drift, scope expansion, contradictions, and use of superseded/open entries
@@ -89,7 +94,7 @@ Produce:
 
 - Authority mode
 - End-to-end coverage table
-- Applied remediations: the exact downstream edits made to `spec.md`/`plan.md`/`tasks.md` and why, or "none"
+- Applied remediations: the exact downstream edits made to `spec.md`/`design.md`/`plan.md`/`tasks.md` and why, or "none"
 - Verified defects by severity that were not auto-remediable (for example, a reported-only tie-break conflict)
 - Unmapped or unauthorized items
 - Risk Advisories

{codexspec-0.7.8 → codexspec-0.7.9}/templates/commands/generate-spec.md

@@ -101,8 +101,8 @@ Read `workflow.auto_next` from `.codexspec/config.yml` (default `false`; only th
 
 When `workflow.auto_next` is `true` AND the Automatic Review Loop above concluded in a passing state — the final Overall Status is `PASS` or `PASS_WITH_WARNINGS` — advance the chain automatically:
 
-1. Emit exactly one notice line, in the interaction language, e.g. `auto_next: review passed → invoking /codexspec:spec-to-plan <feature-dir>`.
-2. Invoke `/codexspec:spec-to-plan <feature-dir>` exactly once, then end this command.
+1. Emit exactly one notice line, in the interaction language, e.g. `auto_next: review passed → invoking /codexspec:spec-to-design <feature-dir>`.
+2. Invoke `/codexspec:spec-to-design <feature-dir>` exactly once, then end this command.
 
 Do not auto-advance when `workflow.auto_next` is disabled, or the review loop stopped at `NEEDS_REVISION` or `BLOCKED`, or stopped early per the conditions above; in those cases hand control back to the user exactly as the review loop already does. This advances the chain and does not modify the Output Summary.
 

{codexspec-0.7.8 → codexspec-0.7.9}/templates/commands/implement-tasks.md

@@ -37,6 +37,7 @@ Read:
 
 - `requirements.md`
 - `spec.md`
+- `design.md`
 - `plan.md`
 - `tasks.md`
 - `.codexspec/memory/constitution.md` when present
@@ -46,8 +47,11 @@ Authority order:
 1. Confirmed entries in `requirements.md`
 2. `spec.md`
 3. Constitution and verified repository facts
-4. Approved `plan.md`
-5. `tasks.md`
+4. `design.md`
+5. Approved `plan.md`
+6. `tasks.md`
+
+A legacy feature may have no `design.md`; when it is absent, proceed with `plan.md` as the design-and-plan authority.
 
 When `requirements.md` is absent, use legacy spec-only mode. Treat `spec.md` as
 the temporary highest feature authority and state that fidelity to the original

{codexspec-0.7.8 → codexspec-0.7.9}/templates/commands/plan-to-tasks.md

@@ -33,9 +33,12 @@ Read:
 
 - `requirements.md`
 - `spec.md`
+- `design.md`
 - `plan.md`
 - Constitution and relevant repository conventions
 
+`design.md` (the confirmed design) sits between `spec.md` and `plan.md` in authority; read it as context so tasks trace to the design the plan implements. A legacy feature may have no `design.md`; proceed from `plan.md` in that case.
+
 Legacy compatibility: when `requirements.md` is absent, use `spec.md` as the temporary highest authority and state the limitation.
 
 ## Stop Conditions

codexspec-0.7.9/templates/commands/review-design.md

@@ -0,0 +1,132 @@
+---
+description: Review design fidelity, feasibility, and planning readiness
+argument-hint: "[design.md or feature directory]"
+handoffs:
+  - agent: claude
+    step: Review design against confirmed requirements, spec, and repository facts
+---
+
+# Design Reviewer
+
+## Language Preference
+
+Read `.codexspec/config.yml`. Two independent language controls apply (each falls back to `language.output`, then English):
+
+- **Interaction language** (`language.interaction`): language for all conversation with the user — questions, explanations, status messages, and `codexspec` CLI terminal output.
+- **Document language** (`language.document`): language for generated artifact files (requirements/spec/plan/tasks).
+
+Converse in the interaction language and author artifacts in the document language. Apply the project's translation standard to both: translate by meaning (not word-for-word), keep English for terms with no good native equivalent, and write as if originally in that language.
+
+## User Input
+
+`$ARGUMENTS`
+
+## Review Authority
+
+Resolve by explicit path, then current branch; never silently select the latest feature.
+
+Read `requirements.md`, `spec.md`, `design.md`, the constitution, and only the repository files necessary to verify design claims.
+
+If `requirements.md` is absent, use legacy spec-only mode and disclose that original-discussion fidelity cannot be verified.
+
+Authority order:
+
+1. Confirmed requirements
+2. Specification
+3. Constitution and verified repository facts
+4. Design-level technical decisions
+5. Applicable best practices
+
+## Review Passes
+
+### 1. Fidelity and Coverage
+
+- Verify every `REQ`/`NFR` has design coverage.
+- Verify each component, interface, data change, and design decision has `Covers:`.
+- Detect omitted behavior, semantic changes, scope expansion, and design decisions that override confirmed trade-offs.
+- Verify design-level assumptions remain labeled and do not become product requirements.
+
+### 2. Feasibility and Internal Quality
+
+Report evidence-backed defects such as:
+
+- Referencing nonexistent modules, APIs, paths, or capabilities
+- Contradictory component responsibilities or interfaces
+- Missing design decisions that genuinely block planning
+- Invalid data, compatibility, security, or interface assumptions
+- Complexity that creates concrete risk without serving a confirmed requirement
+
+Data models, API contracts, sequence diagrams, cross-cutting design sections, and explicit interfaces are required only when the feature or repository context makes them necessary.
+
+### 3. Advisories
+
+Put optional best practices in **Risk Advisories** or **Design Opportunities**. Include applicability, actual risk or benefit, and relationship to the user goal.
+
+Advisories do not affect status, do not affect the score, and must not be auto-fixed.
+
+## Finding Validation
+
+Every defect must include:
+
+- **Evidence**
+- **Location**
+- **Mismatch**
+- **Impact**
+- **Remediation**
+
+Merge findings with the same root cause. Do not deduct the same root cause under alignment, architecture, and decision-record planning separately.
+
+Reject findings that are only stylistic preference, generic best practice without applicability, or a demand to replace a confirmed trade-off.
+
+Zero verified defects is a valid result.
+
+## Severity, Status, and Compatibility Score
+
+- Critical: blocks a correct or feasible implementation
+- Warning: likely incorrect implementation or major rework
+- Minor: localized verified defect
+- Advisory: optional and non-scoring
+
+Status:
+
+- Critical present: `BLOCKED`
+- Warning present without Critical: `NEEDS_REVISION`
+- Minor only: `PASS_WITH_WARNINGS`
+- No defects: `PASS`
+
+Compatibility Score:
+
+- No defects: `100`
+- Minor only: `max(80, 100 - 3 × Minor)`
+- Warning present: `max(50, 79 - 8 × (Warning - 1) - 3 × Minor)`
+- Critical present: `max(0, 49 - 15 × (Critical - 1) - 8 × Warning - 3 × Minor)`
+
+Advisory does not affect the score. There are no fixed deductions for omitted template sections.
+
+## Report
+
+Save `<feature-dir>/review-design.md`:
+
+```markdown
+# Design Review Report
+
+## Summary
+- **Overall Status**: PASS / PASS_WITH_WARNINGS / NEEDS_REVISION / BLOCKED
+- **Compatibility Score**: X/100
+- **Authority Mode**: Requirements-first / Legacy spec-only
+- **Readiness**: Ready for Planning / Revision Required
+
+## Requirement Coverage
+| Requirement | Design Reference | Result |
+
+## Verified Defects
+### Critical
+### Warnings
+### Minor
+
+## Risk Advisories
+
+## Design Opportunities
+
+## Score Derivation
+```

{codexspec-0.7.8 → codexspec-0.7.9}/templates/commands/review-plan.md

@@ -25,25 +25,27 @@ Converse in the interaction language and author artifacts in the document langua
 
 Resolve by explicit path, then current branch; never silently select the latest feature.
 
-Read `requirements.md`, `spec.md`, `plan.md`, the constitution, and only the repository files necessary to verify plan claims.
+Read `requirements.md`, `spec.md`, `design.md`, `plan.md`, the constitution, and only the repository files necessary to verify plan claims.
 
-If `requirements.md` is absent, use legacy spec-only mode and disclose that original-discussion fidelity cannot be verified.
+If `requirements.md` is absent, use legacy spec-only mode and disclose that original-discussion fidelity cannot be verified. A legacy feature may also have no `design.md`; when it is absent, review the plan against the spec directly.
 
 Authority order:
 
 1. Confirmed requirements
 2. Specification
 3. Constitution and verified repository facts
-4. Plan-level technical decisions
-5. Applicable best practices
+4. `design.md`
+5. Plan-level technical decisions
+6. Applicable best practices
 
 ## Review Passes
 
 ### 1. Fidelity and Coverage
 
 - Verify every `REQ`/`NFR` has plan coverage.
-- Verify each component or phase has `Covers:`.
-- Detect omitted behavior, semantic changes, scope expansion, and plan decisions that override confirmed trade-offs.
+- Verify the plan covers the confirmed `design.md` components (which cover the requirements) and does not restate or re-architect the design — architecture/interface/data-model decisions belong to `design.md`, not the plan.
+- Verify each plan component or phase carries `Covers: REQ-xxx; Design: <design component>` (or `Covers: REQ-xxx` for a legacy feature with no `design.md`).
+- Detect omitted behavior, semantic changes, scope expansion, and plan decisions that override confirmed trade-offs or the confirmed design.
 - Verify plan-level assumptions remain labeled and do not become product requirements.
 
 ### 2. Feasibility and Internal Quality

{codexspec-0.7.8 → codexspec-0.7.9}/templates/commands/review-tasks.md

@@ -25,18 +25,19 @@ Converse in the interaction language and author artifacts in the document langua
 
 Resolve by explicit path, then current branch; never silently select the latest feature.
 
-Read `requirements.md`, `spec.md`, `plan.md`, `tasks.md`, the constitution, and relevant repository paths.
+Read `requirements.md`, `spec.md`, `design.md`, `plan.md`, `tasks.md`, the constitution, and relevant repository paths.
 
-If `requirements.md` is absent, use legacy spec-only mode and disclose that original-discussion fidelity cannot be verified.
+If `requirements.md` is absent, use legacy spec-only mode and disclose that original-discussion fidelity cannot be verified. A legacy feature may also have no `design.md`; when it is absent, proceed without the design link.
 
 Authority order:
 
 1. Confirmed requirements
 2. Specification
 3. Constitution and verified repository facts
-4. Approved plan
-5. Task list
-6. Applicable best practices
+4. `design.md`
+5. Approved plan
+6. Task list
+7. Applicable best practices
 
 ## Review Passes