codexspec 0.7.5__tar.gz → 0.7.6__tar.gz

{codexspec-0.7.5 → codexspec-0.7.6}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: codexspec
-Version: 0.7.5
+Version: 0.7.6
 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
@@ -585,7 +585,7 @@ Implementation follows **conditional TDD workflow**:
 | ---------------------------- | --------------------------------------------------------------- |
 | `/codexspec:config`          | Manage project configuration (create/view/modify/reset)         |
 | `/codexspec:clarify`         | Scan spec for ambiguities (4 categories, max 5 questions)       |
-| `/codexspec:analyze`         | Cross-artifact consistency analysis (read-only, severity-based) |
+| `/codexspec:analyze`         | Cross-artifact consistency analysis (auto-remediating, severity-based) |
 | `/codexspec:checklist`       | Generate requirements quality checklist                         |
 | `/codexspec:tasks-to-issues` | Convert tasks to GitHub Issues                                  |
 
@@ -617,7 +617,7 @@ CodexSpec is inspired by GitHub spec-kit with key differences:
 | Two-Phase Spec      | No                      | Yes (clarify + generate)                      |
 | Review Commands     | Optional                | 3 dedicated review commands + scoring         |
 | Clarify Command     | Yes                     | 4 focus categories, review integration        |
-| Analyze Command     | Yes                     | Read-only, severity-based, constitution-aware |
+| Analyze Command     | Yes                     | Auto-remediating, severity-based, constitution-aware |
 | TDD in Tasks        | Optional                | Conditional on requirements, risk, and policy |
 | Implementation      | Standard                | Conditional TDD (code vs docs/config)         |
 | Extension System    | Yes                     | Yes                                           |

{codexspec-0.7.5 → codexspec-0.7.6}/README.md

@@ -540,7 +540,7 @@ Implementation follows **conditional TDD workflow**:
 | ---------------------------- | --------------------------------------------------------------- |
 | `/codexspec:config`          | Manage project configuration (create/view/modify/reset)         |
 | `/codexspec:clarify`         | Scan spec for ambiguities (4 categories, max 5 questions)       |
-| `/codexspec:analyze`         | Cross-artifact consistency analysis (read-only, severity-based) |
+| `/codexspec:analyze`         | Cross-artifact consistency analysis (auto-remediating, severity-based) |
 | `/codexspec:checklist`       | Generate requirements quality checklist                         |
 | `/codexspec:tasks-to-issues` | Convert tasks to GitHub Issues                                  |
 
@@ -572,7 +572,7 @@ CodexSpec is inspired by GitHub spec-kit with key differences:
 | Two-Phase Spec      | No                      | Yes (clarify + generate)                      |
 | Review Commands     | Optional                | 3 dedicated review commands + scoring         |
 | Clarify Command     | Yes                     | 4 focus categories, review integration        |
-| Analyze Command     | Yes                     | Read-only, severity-based, constitution-aware |
+| Analyze Command     | Yes                     | Auto-remediating, severity-based, constitution-aware |
 | TDD in Tasks        | Optional                | Conditional on requirements, risk, and policy |
 | Implementation      | Standard                | Conditional TDD (code vs docs/config)         |
 | Extension System    | Yes                     | Yes                                           |

{codexspec-0.7.5 → codexspec-0.7.6}/pyproject.toml

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

codexspec-0.7.6/templates/commands/analyze.md

@@ -0,0 +1,99 @@
+---
+description: Analyze end-to-end traceability and consistency across SDD artifacts
+argument-hint: "[feature directory]"
+---
+
+# Cross-Artifact Analyzer
+
+## 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`
+
+## Operating Model
+
+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.
+- 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.
+
+## Inputs
+
+Load:
+
+- `requirements.md`
+- `spec.md`
+- `plan.md`
+- `tasks.md`
+- Constitution
+
+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
+
+Build the chain:
+
+```text
+confirmed NEED/CON/DEC/OUT
+  -> REQ/NFR Sources
+  -> plan Covers
+  -> task Covers + Plan reference
+```
+
+Detect:
+
+- Confirmed requirements with no spec coverage
+- Spec requirements with missing or invalid sources
+- Spec requirements 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
+- Dependency or ordering conflicts that prevent execution
+
+## Remediation
+
+Resolve findings along two dimensions. `requirements.md` is never edited.
+
+- **Completeness** — every upstream authority (ultimately `requirements.md`) must be covered downstream. For an uncovered upstream item, auto-add the missing downstream coverage. A downstream entry that only adds derived or elaborated detail without upstream authority does **not** harm completeness and is preserved untouched — its mere existence is not a defect.
+- **Consistency** — act **only on conflicts**: a downstream entry that contradicts `requirements.md`/upstream truth or another entry. Resolve a conflict by conforming the unauthorized or lower-authority side with the **minimal change** needed to remove it. When there is no conflict, take no action.
+- **Determinism** — the fix direction is dictated by the authority hierarchy; never invent intent, and never rewrite `requirements.md`.
+- **Conflict tie-break** — when two conflicting entries share no adjudicating upstream, trace both to their nearest common upstream authority and conform to it. If genuinely no common upstream exists, leave both entries unchanged and report the unresolved conflict; analyze still completes and does not gate or escalate.
+
+Apply only deterministic, authority-directed remediations automatically. Keep optional Risk Advisories and Design Opportunities separate; never auto-apply those.
+
+## Finding Rules
+
+Use the same evidence requirements as the review commands:
+
+- Evidence
+- Location
+- Mismatch
+- Impact
+- Remediation
+
+Merge the same root cause. Separate optional Risk Advisories and Design Opportunities from verified defects.
+
+## Output
+
+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"
+- Verified defects by severity that were not auto-remediable (for example, a reported-only tie-break conflict)
+- Unmapped or unauthorized items
+- Risk Advisories
+- Design Opportunities
+- Coverage counts for each link in the chain
+
+`requirements.md` is never among the changed files. It is valid to report zero findings and zero remediations.

{codexspec-0.7.5 → codexspec-0.7.6}/templates/commands/implement-tasks.md

@@ -212,6 +212,19 @@ non-PASS and cannot be declared successful by the implementer.
 If verification requires a new product or architecture decision, stop and
 request that decision. Do not invent intent or weaken the requirement.
 
+#### 7.3a Scenario Coverage Self-Check
+
+Independently of the reviewer — do not extend or rely on `review-code` for this —
+verify that every test scenario enumerated in `tasks.md` maps to at least one
+implemented test that genuinely exercises and asserts it. A scenario with no
+covering test, or covered only by a hollow or non-asserting test (the test must
+assert the scenario's expected outcome), is a blocking scenario-coverage gap.
+
+Treat each gap as a verified obligation and repair it via 7.4 (red-green: add the
+covering test, observe it fail for the missing behavior, then make it pass), then
+re-verify and re-review per 7.5. This check is owned by this implementer; it adds
+no command and does not modify `review-code`.
+
 #### 7.4 Apply Test-Safe Repairs
 
 Apply only verified repairs:
@@ -260,8 +273,8 @@ or cleared by an audit score.
 
 Success requires a final valid `PASS` envelope from a fresh complete-feature
 review, with complete requirements and verification, isolated required reviewer
-topology, zero P0-P3 counts, no blocking coverage gaps, and a still-green
-baseline.
+topology, zero P0-P3 counts, no blocking coverage gaps, no uncovered enumerated
+test scenario from `tasks.md` (per 7.3a), and a still-green baseline.
 
 Any `FAIL`, persistent `INCONCLUSIVE`, unresolved verified defect, repeated
 refuted finding, decision requirement, or no-progress guard is blocking. Preserve

{codexspec-0.7.5 → codexspec-0.7.6}/templates/commands/plan-to-tasks.md

@@ -60,6 +60,9 @@ Stop instead of guessing when:
 - Mark `[P]` only when tasks can actually run concurrently after their declared dependencies. Missing `[P]` is not inherently a defect.
 - Require test-first ordering only when mandated by the constitution, specification, plan, or established repository workflow.
 - Otherwise include the appropriate verification task without imposing TDD as a universal method.
+- For every **testable** task, enumerate an explicit, individually identifiable **Test Scenarios** list: the happy path plus the boundary and error conditions the behavior implies. Non-testable tasks (docs, config, assets, infrastructure) keep their deterministic verification and do not carry test scenarios.
+- Derive test scenarios from the specification's acceptance criteria and the covered requirement's behavior, expanding them into concrete cases; never invent scenarios with no upstream basis. If upstream behavior is too underspecified to enumerate meaningful scenarios, stop per the Stop Conditions rather than guessing.
+- Keep each scenario individually identifiable and traceable so implementation and the `implement-tasks` self-check can map each scenario to a test one-to-one. Do not pad: enumerate only scenarios the behavior actually implies.
 - Do not add polish, monitoring, abstraction, documentation, or hardening tasks unless they are required by the approved plan, repository policy, or a verified implementation need.
 
 ## Required Output
@@ -71,7 +74,8 @@ Include:
 - Task groups derived from the plan
 - Task IDs, outcomes, paths, dependencies, and traceability
 - Verification steps and checkpoints appropriate to the change
-- A coverage table mapping plan components and requirements to tasks
+- An explicit **Test Scenarios** list for every testable task (happy path plus behavior-implied boundary/error cases), each scenario individually identifiable
+- A coverage table mapping plan components and requirements to tasks, including scenario-to-task mapping for testable tasks
 - Unmapped tasks, if any, with explicit justification
 
 ## Pre-Save Validation
@@ -81,6 +85,7 @@ Include:
 3. Dependencies are acyclic and ordered before dependents.
 4. Verification is sufficient for the actual risk and project policy.
 5. No task expands product scope or silently changes the plan.
+6. Every testable task enumerates sufficient, individually traceable test scenarios (happy path plus behavior-implied boundary/error), all derived from upstream behavior with none invented.
 
 ## Automatic Review Loop
 
@@ -97,9 +102,9 @@ Invoke `/codexspec:review-tasks <feature-dir>/tasks.md`.
 When the review loop above concludes in a passing state — the final `/codexspec:review-tasks` Overall Status is `PASS` or `PASS_WITH_WARNINGS` — invoke `/codexspec:analyze <feature-dir>` exactly once.
 
 - Do not invoke analyze when the review loop stopped at `NEEDS_REVISION` or `BLOCKED`, or stopped early per the conditions above; in those cases end here, handing control back to the user as the review loop already does.
-- analyze runs once and is read-only. Present its output as-is; do not auto-fix its findings and do not run a fix-and-reanalyze loop.
-- If `requirements.md` is absent, analyze still runs and discloses its legacy limitation (it starts at `spec.md` and cannot verify fidelity to the original discussion) per its own behavior.
-- analyze's results are informational only. They do not change whether tasks are ready for implementation and do not add a gate before `/codexspec:implement-tasks`.
+- analyze runs once. It auto-remediates deterministic, authority-directed inconsistencies (conforming `spec.md`/`plan.md`/`tasks.md` to `requirements.md`; it never edits `requirements.md`) and reports the result. Do not run a fix-and-reanalyze loop.
+- If `requirements.md` is absent, analyze still runs in legacy mode, reports findings only (no auto-modification), and discloses its legacy limitation (it starts at `spec.md` and cannot verify fidelity to the original discussion) per its own behavior.
+- analyze's deterministic conforming fixes need no re-review; its remediations and any residual findings do not add a gate before `/codexspec:implement-tasks`.
 - Do not modify the Output Summary for analyze, and do not save an additional analyze report file; analyze's own output is the report.
 
 ## Auto-Next Chain Advance
@@ -111,7 +116,7 @@ When `workflow.auto_next` is `true` AND the review loop above concluded in a pas
 1. Emit exactly one notice line, in the interaction language, e.g. `auto_next: review passed → invoking /codexspec:implement-tasks <feature-dir>`.
 2. Invoke `/codexspec:implement-tasks <feature-dir>` exactly once, with no confirmation prompt, then end this command.
 
-analyze's findings are informational only and do NOT block this advance (see the Automatic Cross-Artifact Analysis section above). Do not auto-advance when `workflow.auto_next` is disabled, or the review loop stopped at `NEEDS_REVISION` or `BLOCKED`, or stopped early; hand control back to the user as the review loop already does. This advances the chain and does not modify the Output Summary.
+analyze's deterministic auto-fixes and any residual findings do NOT block this advance (see the Automatic Cross-Artifact Analysis section above). Do not auto-advance when `workflow.auto_next` is disabled, or the review loop stopped at `NEEDS_REVISION` or `BLOCKED`, or stopped early; hand control back to the user as the review loop already does. This advances the chain and does not modify the Output Summary.
 
 ## Output Summary
 

codexspec-0.7.5/templates/commands/analyze.md

@@ -1,84 +0,0 @@
----
-description: Analyze end-to-end traceability and consistency across SDD artifacts
-argument-hint: "[feature directory]"
----
-
-# Cross-Artifact Analyzer
-
-## 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`
-
-## Operating Constraints
-
-This command is read-only. Do not modify artifacts.
-
-Resolve the feature by explicit path, then current branch. Ask the user if it is ambiguous; never select the latest feature silently.
-
-## Inputs
-
-Load:
-
-- `requirements.md`
-- `spec.md`
-- `plan.md`
-- `tasks.md`
-- Constitution
-
-Legacy compatibility: if `requirements.md` is missing, state that the analysis starts at `spec.md` and cannot validate fidelity to the original discussion.
-
-## End-to-End Traceability
-
-Build the chain:
-
-```text
-confirmed NEED/CON/DEC/OUT
-  -> REQ/NFR Sources
-  -> plan Covers
-  -> task Covers + Plan reference
-```
-
-Detect:
-
-- Confirmed requirements with no spec coverage
-- Spec requirements with missing or invalid sources
-- Spec requirements 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
-- Dependency or ordering conflicts that prevent execution
-
-## Finding Rules
-
-Use the same evidence requirements as the review commands:
-
-- Evidence
-- Location
-- Mismatch
-- Impact
-- Remediation
-
-Merge the same root cause. Separate optional Risk Advisories and Design Opportunities from verified defects.
-
-## Output
-
-Produce:
-
-- Authority mode
-- End-to-end coverage table
-- Verified defects by severity
-- Unmapped or unauthorized items
-- Risk Advisories
-- Design Opportunities
-- Coverage counts for each link in the chain
-
-It is valid to report zero defects.