create-sdd-project 0.13.1 → 0.14.0

package/README.md

@@ -354,7 +354,7 @@ Quality gates (tests, lint, build, validators) **always run** regardless of leve
 Every ticket includes a `## Merge Checklist Evidence` table that the agent must fill before requesting merge approval. This mechanism:
 
 - **Survives context compaction** — the ticket is always re-read via product tracker, so the empty evidence table acts as a persistent reminder
-- **Forces sequential execution** — agent must read `references/merge-checklist.md`, execute 9 actions (0–8), and record evidence
+- **Forces sequential execution** — agent must read `references/merge-checklist.md`, execute 10 actions (0–9), and record evidence
 - **Works at all tiers** — Simple tasks get a lite ticket with the same evidence table
 
 Validated across 16+ features with 87% first-attempt pass rate (failures led to iterative improvements in v0.8.7–v0.9.8).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-sdd-project",
-  "version": "0.13.1",
+  "version": "0.14.0",
   "description": "Create a new SDD DevFlow project with AI-assisted development workflow",
   "bin": {
     "create-sdd-project": "bin/cli.js"

package/template/.claude/agents/production-code-validator.md

@@ -66,6 +66,15 @@ Scan code systematically to identify and report issues that should never reach p
 - Mismatch between spec-defined request/response schemas and actual implementation
 - **Ticket accuracy**: verify acceptance criteria test count matches actual test count
 
+### 9. Data File & Seed Validation
+
+Scan JSON files, seed scripts, and data fixtures for data quality issues:
+
+- **Case consistency in string arrays**: If a field contains an array of strings (e.g., `aliases`, `tags`, `keywords`), verify all values follow the same casing convention. Flag mixed casing (e.g., `["admin", "Admin"]`). Arrays of display names or titles may use Title Case by design — use context to avoid false positives.
+- **Duplicate detection in ID fields**: Scan objects in arrays for duplicate values in fields that should be unique (e.g., `id`, `externalId`, `slug`, `code`). Flag exact duplicates.
+- **Required field presence**: If objects in the same array have inconsistent keys (some have a field, others don't), flag the missing fields. All objects in a homogeneous array should have the same shape.
+- **Value range checks**: Flag negative numbers in fields where negatives are unlikely (e.g., `calories`, `proteins`, `portionGrams`). Flag suspiciously high values that look like placeholder data. Use field semantics for context.
+
 ## Output Format
 
 For each issue found:

package/template/.claude/skills/development-workflow/SKILL.md

@@ -50,6 +50,7 @@ Read the **Autonomy Level** from `CLAUDE.md` section 2.
 - **Auto** = proceed without asking; log in product tracker → "Auto-Approved Decisions" table
 - **Required** = ask user explicitly; do NOT continue without approval
 - **Quality gates always run** regardless of level (tests, lint, build, validators)
+- **Steps are strictly sequential.** Do NOT start a later step before the current checkpoint is approved — even when the checkpoint is Auto (auto-approval still happens in order, not in parallel). In particular, do NOT generate the Implementation Plan (Step 2) while Spec Approval (Step 0) is still pending. Reason: if the spec review finds issues, any plan built on the flawed spec must be discarded and redone — parallelizing wastes work and risks shipping a plan that doesn't match the final spec.
 
 ---
 
@@ -74,7 +75,7 @@ Ask user to classify complexity before starting. See `references/complexity-guid
 5. **Cross-Model Spec Review:** Run `/review-spec`. If at least one external CLI is available (`gemini`, `codex`), this provides independent validation from other models. If no external CLIs are detected, skip this step (the self-review above is sufficient).
 6. **Design Review (optional):** If this feature includes UI changes, mention to the user: "This feature has UI changes. Want to invoke `ui-ux-designer` for design notes?" If yes, use Task tool with `ui-ux-designer` agent. If `docs/specs/design-guidelines.md` does not exist yet, suggest creating it first.
 
-**→ CHECKPOINT: Spec Approval** — Update tracker (Active Session + Features table): step `0/6 (Spec)`
+**→ CHECKPOINT: Spec Approval** — Update tracker (Active Session + Features table): step `0/6 (Spec)`. Update ticket Status to `Spec`.
 
 ---
 
@@ -91,7 +92,7 @@ See `references/branching-strategy.md` for details.
 3. **Simple:** Generate a **lite ticket** at `docs/tickets/<feature-id>-<short-desc>.md` using `references/ticket-template.md`. Fill the header and a one-line `## Spec > Description`. Set `## Implementation Plan` to `N/A — Simple task`. Fill lightweight Acceptance Criteria and Definition of Done. Set Workflow Checklist to Steps 1, 3, 4, 5 only. Leave Completion Log and Merge Checklist Evidence empty (filled in later steps). **Verify the ticket contains ALL 7 sections.**
 4. **Std/Cplx:** Copy ALL sections from `references/ticket-template.md` (Spec, Implementation Plan, Acceptance Criteria, Definition of Done, Workflow Checklist, Completion Log) → fill `## Spec` section. Do NOT omit empty sections — they are filled in later steps. **After generating the ticket, verify it contains ALL 7 sections in this exact order: Spec → Implementation Plan → Acceptance Criteria → Definition of Done → Workflow Checklist → Completion Log → Merge Checklist Evidence. If any section is missing, add it now.**
 5. **Complex:** Also review `decisions.md` for related ADRs
-6. Update product tracker → Active Session: feature, step `1/6 (Setup)`, branch, complexity. Update Features table: status `in-progress`, step `1/6`
+6. Update product tracker → Active Session: feature, step `1/6 (Setup)`, branch, complexity. Update Features table: status `in-progress`, step `1/6`. Update ticket Status to `In Progress`.
 
 **→ CHECKPOINT: Ticket Approval** (Std/Cplx only — Simple skips to Step 3)
 
@@ -110,7 +111,7 @@ See `references/branching-strategy.md` for details.
    - Over-engineering or unnecessary abstractions?
    Update the plan with any fixes found before proceeding.
 5. **Cross-Model Plan Review:** Run `/review-plan`. If at least one external CLI is available (`gemini`, `codex`), this provides independent validation from other models. If no external CLIs are detected, skip this step (the self-review above is sufficient).
-6. Update tracker: step `2/6 (Plan)` (Active Session + Features table)
+6. Update tracker: step `2/6 (Plan)` (Active Session + Features table). Update ticket Status to `Planning`.
 
 **→ CHECKPOINT: Plan Approval**
 
@@ -134,7 +135,7 @@ See `references/branching-strategy.md` for details.
 
 **Commits:** Commit freely during implementation (one per logical unit is fine). Final history cleanup happens via squash merge in Step 5.
 
-Update tracker (Active Session + Features table): step `3/6 (Implement)`, context summary. Mark ticket Workflow Checklist `[x]` for Step 3.
+Update tracker (Active Session + Features table): step `3/6 (Implement)`, context summary. Mark ticket Workflow Checklist `[x]` for Step 3. Update ticket Status to `In Progress`.
 
 ---
 
@@ -149,7 +150,7 @@ Update tracker (Active Session + Features table): step `3/6 (Implement)`, contex
 
 **Commit format:** `<type>(<scope>): <description>` + `Co-Authored-By: Claude <noreply@anthropic.com>`
 
-Update tracker (Active Session + Features table): step `4/6 (Finalize)`. Mark ticket Workflow Checklist `[x]` for Step 4.
+Update tracker (Active Session + Features table): step `4/6 (Finalize)`. Mark ticket Workflow Checklist `[x]` for Step 4. Update ticket Status to `In Progress`.
 
 ---
 
@@ -157,6 +158,8 @@ Update tracker (Active Session + Features table): step `4/6 (Finalize)`. Mark ti
 
 **Target branch** from `key_facts.md` → same as base branch (Step 1).
 
+Update ticket Status to `Review`.
+
 1. Push branch, create PR (use `references/pr-template.md`)
 2. **Std/Cplx:** Run `code-review-specialist` via Task tool — **do NOT skip**
 3. **Std/Cplx:** Also run `qa-engineer` via Task tool

package/template/.claude/skills/development-workflow/references/merge-checklist.md

@@ -49,16 +49,30 @@ Commit ALL documentation updates from actions 0–4. Use commit message: `docs:
 
 Run `git status`. **No unstaged or untracked files allowed.** If any remain, stage and commit them.
 
-## Action 7: Fill Merge Checklist Evidence
+## Action 7: Verify branch is up to date with target
 
-In the ticket, fill the `## Merge Checklist Evidence` table. For each action (0–6), mark `[x]` and write the actual evidence (not placeholders). Example:
+Determine the target branch from `docs/project_notes/key_facts.md` → `branching-strategy` (github-flow → `main`, gitflow → `develop`).
+
+1. Fetch latest: `git fetch origin <target-branch>`
+2. Check divergence: `git merge-base --is-ancestor origin/<target-branch> HEAD`
+   - If the command **succeeds** (exit code 0) → the feature branch already contains all target branch commits. Proceed to Action 8.
+   - If the command **fails** (exit code 1) → the feature branch has diverged.
+3. **If diverged:** Merge the target branch into the feature branch:
+   - `git merge origin/<target-branch>`
+   - If **conflicts** occur: resolve them, run quality gates (`npm test`, lint, build) again, and commit the merge.
+   - If no conflicts: the merge commit is created automatically.
+4. After merging, verify clean working tree again (`git status`).
+
+## Action 8: Fill Merge Checklist Evidence
+
+In the ticket, fill the `## Merge Checklist Evidence` table. For each action (0–7), mark `[x]` and write the actual evidence (not placeholders). Example:
 
 | Action | Done | Evidence |
 |--------|:----:|----------|
 | 0. Validate ticket structure | [x] | Sections verified: Spec, Plan, AC, DoD, Workflow, Log, Evidence |
 | 1. Mark all items | [x] | AC: 12/12, DoD: 7/7, Workflow: 0-5/6 |
 
-## Action 8: Request merge approval
+## Action 9: Request merge approval
 
 Verify the Merge Checklist Evidence table is fully filled (all rows `[x]` with real evidence).
 

package/template/.claude/skills/development-workflow/references/ticket-template.md

@@ -2,7 +2,7 @@
 
 **Feature:** [ID] | **Type:** [Backend/Frontend/Fullstack]-[Feature/Bugfix/Refactor] | **Priority:** [High/Medium/Low]
 **Status:** In Progress | **Branch:** feature/[FEATURE-ID]-[short-description]
-<!-- Valid Status values: In Progress | Ready for Merge | Done -->
+<!-- Valid Status values: Spec | In Progress | Planning | Review | Ready for Merge | Done -->
 **Created:** [YYYY-MM-DD] | **Dependencies:** [List or "None"]
 
 ---
@@ -101,6 +101,7 @@ This creates a feedback loop for improving future reviews. -->
 | 4. Update decisions.md | [ ] | ADR-XXX added / N/A |
 | 5. Commit documentation | [ ] | Commit: (hash) |
 | 6. Verify clean working tree | [ ] | `git status`: clean |
+| 7. Verify branch up to date | [ ] | merge-base: up to date / merged origin/<branch> |
 
 ---
 

package/template/.gemini/agents/production-code-validator.md

@@ -16,6 +16,8 @@ Scan code systematically for issues that should never reach production:
 7. **Code Quality**: Unused imports, missing types, overly long functions
 8. **Spec Drift** (BLOCKING): Enumerate every route in code vs `api-spec.yaml` — any mismatch is HIGH. Check components vs `ui-components.md`, schemas vs `shared/src/schemas/`. Verify ticket test counts match actual
 
+9. **Data File & Seed Validation**: Scan JSON files, seed scripts, and data fixtures for: case consistency in string arrays (e.g., `aliases` all lowercase), duplicate IDs in arrays, inconsistent object shapes, negative numbers in fields that should be non-negative, suspiciously high placeholder values
+
 ## Output Format
 
 For each issue:

package/template/.gemini/skills/development-workflow/SKILL.md

@@ -50,6 +50,7 @@ Read the **Autonomy Level** from `GEMINI.md`.
 - **Auto** = proceed without asking; log in product tracker → "Auto-Approved Decisions" table
 - **Required** = ask user explicitly; do NOT continue without approval
 - **Quality gates always run** regardless of level (tests, lint, build, validators)
+- **Steps are strictly sequential.** Do NOT start a later step before the current checkpoint is approved — even when the checkpoint is Auto (auto-approval still happens in order, not in parallel). In particular, do NOT generate the Implementation Plan (Step 2) while Spec Approval (Step 0) is still pending. Reason: if the spec review finds issues, any plan built on the flawed spec must be discarded and redone — parallelizing wastes work and risks shipping a plan that doesn't match the final spec.
 
 ---
 
@@ -74,7 +75,7 @@ Ask user to classify complexity before starting. See `references/complexity-guid
 5. **Cross-Model Spec Review:** Run `/review-spec`. If at least one external CLI is available (`claude`, `codex`), this provides independent validation from other models. If no external CLIs are detected, skip this step (the self-review above is sufficient).
 6. **Design Review (optional):** If this feature includes UI changes, mention to the user: "This feature has UI changes. Want to invoke `ui-ux-designer` for design notes?" If yes, follow the `ui-ux-designer` agent instructions in `.gemini/agents/`. If `docs/specs/design-guidelines.md` does not exist yet, suggest creating it first.
 
-**→ CHECKPOINT: Spec Approval** — Update tracker (Active Session + Features table): step `0/6 (Spec)`
+**→ CHECKPOINT: Spec Approval** — Update tracker (Active Session + Features table): step `0/6 (Spec)`. Update ticket Status to `Spec`.
 
 ---
 
@@ -91,7 +92,7 @@ See `references/branching-strategy.md` for details.
 3. **Simple:** Generate a **lite ticket** at `docs/tickets/<feature-id>-<short-desc>.md` using `references/ticket-template.md`. Fill the header and a one-line `## Spec > Description`. Set `## Implementation Plan` to `N/A — Simple task`. Fill lightweight Acceptance Criteria and Definition of Done. Set Workflow Checklist to Steps 1, 3, 4, 5 only. Leave Completion Log and Merge Checklist Evidence empty (filled in later steps). **Verify the ticket contains ALL 7 sections.**
 4. **Std/Cplx:** Copy ALL sections from `references/ticket-template.md` (Spec, Implementation Plan, Acceptance Criteria, Definition of Done, Workflow Checklist, Completion Log) → fill `## Spec` section. Do NOT omit empty sections — they are filled in later steps. **After generating the ticket, verify it contains ALL 7 sections in this exact order: Spec → Implementation Plan → Acceptance Criteria → Definition of Done → Workflow Checklist → Completion Log → Merge Checklist Evidence. If any section is missing, add it now.**
 5. **Complex:** Also review `decisions.md` for related ADRs
-6. Update product tracker → Active Session: feature, step `1/6 (Setup)`, branch, complexity. Update Features table: status `in-progress`, step `1/6`
+6. Update product tracker → Active Session: feature, step `1/6 (Setup)`, branch, complexity. Update Features table: status `in-progress`, step `1/6`. Update ticket Status to `In Progress`.
 
 **→ CHECKPOINT: Ticket Approval** (Std/Cplx only — Simple skips to Step 3)
 
@@ -110,7 +111,7 @@ See `references/branching-strategy.md` for details.
    - Over-engineering or unnecessary abstractions?
    Update the plan with any fixes found before proceeding.
 5. **Cross-Model Plan Review:** Run `/review-plan`. If at least one external CLI is available (`claude`, `codex`), this provides independent validation from other models. If no external CLIs are detected, skip this step (the self-review above is sufficient).
-6. Update tracker: step `2/6 (Plan)` (Active Session + Features table)
+6. Update tracker: step `2/6 (Plan)` (Active Session + Features table). Update ticket Status to `Planning`.
 
 **→ CHECKPOINT: Plan Approval**
 
@@ -134,7 +135,7 @@ See `references/branching-strategy.md` for details.
 
 **Commits:** Commit freely during implementation (one per logical unit is fine). Final history cleanup happens via squash merge in Step 5.
 
-Update tracker (Active Session + Features table): step `3/6 (Implement)`, context summary. Mark ticket Workflow Checklist `[x]` for Step 3.
+Update tracker (Active Session + Features table): step `3/6 (Implement)`, context summary. Mark ticket Workflow Checklist `[x]` for Step 3. Update ticket Status to `In Progress`.
 
 ---
 
@@ -149,7 +150,7 @@ Update tracker (Active Session + Features table): step `3/6 (Implement)`, contex
 
 **Commit format:** `<type>(<scope>): <description>`
 
-Update tracker (Active Session + Features table): step `4/6 (Finalize)`. Mark ticket Workflow Checklist `[x]` for Step 4.
+Update tracker (Active Session + Features table): step `4/6 (Finalize)`. Mark ticket Workflow Checklist `[x]` for Step 4. Update ticket Status to `In Progress`.
 
 ---
 
@@ -157,6 +158,8 @@ Update tracker (Active Session + Features table): step `4/6 (Finalize)`. Mark ti
 
 **Target branch** from `key_facts.md` → same as base branch (Step 1).
 
+Update ticket Status to `Review`.
+
 1. Push branch, create PR (use `references/pr-template.md`)
 2. **Std/Cplx:** Follow `code-review-specialist` instructions in `.gemini/agents/` — **do NOT skip**
 3. **Std/Cplx:** Also follow `qa-engineer` instructions in `.gemini/agents/`

package/template/.gemini/skills/development-workflow/references/merge-checklist.md

@@ -49,16 +49,30 @@ Commit ALL documentation updates from actions 0–4. Use commit message: `docs:
 
 Run `git status`. **No unstaged or untracked files allowed.** If any remain, stage and commit them.
 
-## Action 7: Fill Merge Checklist Evidence
+## Action 7: Verify branch is up to date with target
 
-In the ticket, fill the `## Merge Checklist Evidence` table. For each action (0–6), mark `[x]` and write the actual evidence (not placeholders). Example:
+Determine the target branch from `docs/project_notes/key_facts.md` → `branching-strategy` (github-flow → `main`, gitflow → `develop`).
+
+1. Fetch latest: `git fetch origin <target-branch>`
+2. Check divergence: `git merge-base --is-ancestor origin/<target-branch> HEAD`
+   - If the command **succeeds** (exit code 0) → the feature branch already contains all target branch commits. Proceed to Action 8.
+   - If the command **fails** (exit code 1) → the feature branch has diverged.
+3. **If diverged:** Merge the target branch into the feature branch:
+   - `git merge origin/<target-branch>`
+   - If **conflicts** occur: resolve them, run quality gates (`npm test`, lint, build) again, and commit the merge.
+   - If no conflicts: the merge commit is created automatically.
+4. After merging, verify clean working tree again (`git status`).
+
+## Action 8: Fill Merge Checklist Evidence
+
+In the ticket, fill the `## Merge Checklist Evidence` table. For each action (0–7), mark `[x]` and write the actual evidence (not placeholders). Example:
 
 | Action | Done | Evidence |
 |--------|:----:|----------|
 | 0. Validate ticket structure | [x] | Sections verified: Spec, Plan, AC, DoD, Workflow, Log, Evidence |
 | 1. Mark all items | [x] | AC: 12/12, DoD: 7/7, Workflow: 0-5/6 |
 
-## Action 8: Request merge approval
+## Action 9: Request merge approval
 
 Verify the Merge Checklist Evidence table is fully filled (all rows `[x]` with real evidence).
 

package/template/.gemini/skills/development-workflow/references/ticket-template.md

@@ -2,7 +2,7 @@
 
 **Feature:** [ID] | **Type:** [Backend/Frontend/Fullstack]-[Feature/Bugfix/Refactor] | **Priority:** [High/Medium/Low]
 **Status:** In Progress | **Branch:** feature/[FEATURE-ID]-[short-description]
-<!-- Valid Status values: In Progress | Ready for Merge | Done -->
+<!-- Valid Status values: Spec | In Progress | Planning | Review | Ready for Merge | Done -->
 **Created:** [YYYY-MM-DD] | **Dependencies:** [List or "None"]
 
 ---
@@ -101,6 +101,7 @@ This creates a feedback loop for improving future reviews. -->
 | 4. Update decisions.md | [ ] | ADR-XXX added / N/A |
 | 5. Commit documentation | [ ] | Commit: (hash) |
 | 6. Verify clean working tree | [ ] | `git status`: clean |
+| 7. Verify branch up to date | [ ] | merge-base: up to date / merged origin/<branch> |
 
 ---