prizmkit 1.1.8 → 1.1.10

package/bundled/skills/prizmkit-plan/SKILL.md

@@ -1,111 +1,103 @@
 ---
 name: "prizmkit-plan"
-description: "Specify and plan features: natural language → spec.md → plan.md with architecture and executable tasks. Supports feature, refactor, and bugfix modes. Use before /prizmkit-implement. Trigger on: 'specify', 'plan', 'new feature', 'I want to add/build...', 'architect', 'design', 'break it down', 'create tasks'. (project)"
+description: "Specify and plan tasks: natural language → spec.md & plan.md with architecture and executable tasks. Use before /prizmkit-implement. Trigger on: 'specify', 'plan', 'new task', 'I want to add/build...', 'architect', 'design', 'break it down', 'create tasks'. (project)"
 ---
 
 # PrizmKit Plan
 
+A universal spec + plan generator. Takes a natural-language description of ANY development task (new feature, refactoring, bug fix, migration, etc.) and produces `spec.md` (WHAT/WHY) and `plan.md` (HOW) with executable tasks.
+
 ### When to Use
-- New feature — user says "specify", "plan", "new feature", "I want to add..."
+- Any non-trivial development task that benefits from written specification and planning
 - Before `/prizmkit-implement` — to create the spec + task breakdown
-- When a feature idea needs to go from concept to executable plan
+- User says "specify", "plan", "new task", "I want to add...", "architect", "design", "break it down"
 
 ### When NOT to Use
-- Bug fix with clear root cause → fast path (skip Phase 0, simplified plan → implement → commit)
-- Config tweaks, typo fixes → edit directly
-- User already has a detailed spec → start from Phase 1
+- Config tweaks, typo fixes, trivial one-line changes → edit directly
+- Simple changes where the developer already knows exactly what to do and the scope is ≤10 lines in a single file
+
+## Input
+
+| Parameter | Required | Description |
+|-----------|----------|-------------|
+| `description` | Yes | Natural-language description of the task |
+| `artifact_dir` | No | Directory to write spec.md + plan.md into. If omitted, auto-generates under `.prizmkit/specs/` (see Phase 0 Step 2). |
 
 ## Execution
 
-### Phase 0: Specify (WHAT)
+### Phase 0: Specify (→ spec.md)
 
-Transforms natural language into a structured spec. Skip this phase when:
-- A `spec.md` already exists for this feature
-- Running in refactor mode (input is `refactor-analysis.md`)
-- Running in bugfix mode (input is `fix-plan.md` or caller-provided description)
+**Skip condition**: If `spec.md` already exists in the artifact directory, skip to Phase 1.
 
 **Steps:**
 
-1. Ask user for feature description (natural language)
-2. Auto-generate 2-4 word feature slug from description
-3. Determine next feature number by scanning `.prizmkit/specs/`:
-   - List existing `###-*` directories, find highest numeric prefix
-   - Next = highest + 1 (zero-padded to 3 digits)
-   - If empty or doesn't exist, start at `001`
-4. Create directory: `.prizmkit/specs/###-feature-name/`
-5. Load project context (use first available):
-   - If `context-snapshot.md` exists in the feature dir → read Section 3 'Prizm Context' (skip re-reading .prizm-docs/)
-   - Otherwise → read `.prizm-docs/root.prizm` and relevant L1/L2 docs
-6. Generate `spec.md` from template (`${SKILL_DIR}/assets/spec-template.md`):
-   - Feature title and description
-   - User stories (As a... I want... So that...) with acceptance criteria (Given/When/Then)
-   - Scope boundaries (In scope / Out of scope)
-   - Dependencies and constraints
+1. Gather input: read the task description. If no description is provided and interactive session is available, ask the user; otherwise abort with an error.
+2. Determine artifact directory:
+   - If `artifact_dir` is provided → use it directly
+   - If not provided → scan `.prizmkit/specs/` for existing `###-*` directories, find highest numeric prefix, next = highest + 1 (zero-padded to 3 digits; start at `001` if empty). Create `.prizmkit/specs/###-task-slug/`
+   - Auto-generate 2-10 word task slug from description
+3. Load project context: read `.prizm-docs/root.prizm` and relevant L1/L2 docs
+4. Generate `spec.md` from template (`${SKILL_DIR}/assets/spec-template.md`):
+   - Fill sections based on the task description — all sections are optional, include only what is relevant
    - `[NEEDS CLARIFICATION]` markers for all ambiguous items
-7. **Database design detection**: If feature involves data persistence (new entities, fields, schema changes), add a `## Data Model` section to spec.md — scan existing schema files to extract naming conventions, ID strategy, constraint patterns. Mark uncertain decisions with `[NEEDS CLARIFICATION]`.
-8. Run quality validation (max 3 iterations): all stories have criteria? scope defined? DB conventions documented?
-9. **Auto-clarification**: If any `[NEEDS CLARIFICATION]` markers remain, enter interactive clarification immediately.
+5. **Database design detection**: If changes involve data persistence (new entities, fields, schema changes), add `## Data Model` section — scan existing schema files to extract naming conventions, ID strategy, constraint patterns. Mark uncertain decisions with `[NEEDS CLARIFICATION]`.
+6. Run quality validation : all goals have criteria? scope defined? DB conventions documented (if applicable)?
+7. **Auto-clarification**: If any `[NEEDS CLARIFICATION]` markers remain and interactive session is available, enter interactive clarification.
    → Read `${SKILL_DIR}/references/clarify-guide.md` for question strategy and update rules.
+   If non-interactive, resolve ambiguities by choosing the most conservative option and annotating the decision.
    Resolve all markers before proceeding to Phase 1.
 
-**Writing principles**: Focus on WHAT and WHY, never HOW. Every user story needs acceptance criteria. Scope boundaries must be explicit. Mark all genuine ambiguities — the clarification phase resolves them.
+**Writing principles**: Focus on WHAT and WHY, never HOW. Every goal needs acceptance criteria. Scope boundaries must be explicit. Mark all genuine ambiguities — the clarification phase resolves them.
 
-### Phase 1: Design (HOW)
+### Phase 1: Design (spec.md → plan.md)
 
-**Precondition:**
-
-| Mode | Required Input | Directory |
-|---|---|---|
-| **Feature** (default) | `spec.md` (from Phase 0) + `.prizm-docs/root.prizm` | `.prizmkit/specs/###-feature-name/` |
-| **Refactor** | `refactor-analysis.md` | `.prizmkit/refactor/<refactor-slug>/` |
-| **Bugfix** | `fix-plan.md` or caller-provided description | `.prizmkit/bugfix/<BUG_ID>/` |
-
-If no input document exists, prompt user to describe the feature (triggers Phase 0).
+**Precondition**: `spec.md` exists in the artifact directory.
 
 **Steps:**
 
-1. Read the input document (spec.md / refactor-analysis.md / fix-plan.md)
-2. Load project context if not already loaded in Phase 0:
-   - If `context-snapshot.md` exists → read it for docs + code structure
-   - Otherwise → read `.prizm-docs/root.prizm` and relevant L1/L2 docs
+1. Read `spec.md` from the artifact directory
+2. Load project context if not already loaded in Phase 0: read `.prizm-docs/root.prizm` and relevant L1/L2 docs
 3. Resolve any remaining `[NEEDS CLARIFICATION]` by proposing solutions
 4. Generate `plan.md` from template (`${SKILL_DIR}/assets/plan-template.md`):
-   - Architecture approach, component design
+   - Change approach (how the changes integrate with existing system)
+   - Component / file changes
    - Data model changes (with **database design gate** — read ALL existing schema files, ensure new schema follows existing patterns, resolve all DB ambiguities inline before proceeding)
    - Interface design (API endpoints, request/response formats)
-   - Integration points, testing strategy, risk assessment
-5. Cross-check: every user story maps to plan components — unmapped stories = coverage gaps
+   - Testing strategy
+   - Risk assessment
+   - Behavior preservation strategy (if the task modifies existing behavior — include what must remain unchanged and how to verify)
+5. Cross-check: every goal in spec.md maps to plan components — unmapped goals = coverage gaps
 6. Check alignment with `.prizm-docs/root.prizm` RULES section
-7. **Deployment strategy check:**
+7. **Deployment strategy check** (skip if no deployment impact):
    - Read `.prizmkit/config.json` `deploy_strategy` field
-   - No strategy → ask user, write to config.json
-   - Strategy exists + new tech stack detected → ask about new component only
-   - Skipped in fast-path mode (bug fixes / simple refactors)
+   - No strategy and new infra needed → ask user, write to config.json
 
-### Phase 2: Task Generation
+### Phase 2: Task Generation (plan.md → Tasks section)
 
-1. Ask user for strategy (or infer): MVP-first / Incremental / Parallel
-2. Append `## Tasks` section to `plan.md` using tasks template in `${SKILL_DIR}/assets/plan-template.md`:
-   - Phases: Setup (T-001~T-009) → Foundational (T-010~T-099) → User Stories (T-100+) → Polish (T-900+)
-   - Each task: `- [ ] [T-NNN] [P?] [US?] Description — file: path/to/file`
+1. If interactive session is available, ask user for strategy; otherwise infer automatically: MVP-first / Incremental / Parallel
+2. Append `## Tasks` section to `plan.md` using template in `${SKILL_DIR}/assets/plan-template.md`:
+   - Phases: Setup (T-001~T-009) → Foundation (T-010~T-099) → Core (T-100+) → Polish (T-900+)
+   - Each task: `- [ ] [T-NNN] [P?] [G-N?] Description — file: path/to/file`
    - Checkpoint tasks between phases for validation
-3. Verify coverage:
-   - Every user story → at least one task
-   - Every task → a target file path
-   - Risk assessment → at least one risk with mitigation
-4. Output: `plan.md` path, summary of design decisions, task count
+   - Organize Core tasks by goals (G-1, G-2, ...) or by logical grouping appropriate to the task
+3. Verify consistency and coverage → read `${SKILL_DIR}/references/verification-checklist.md` and run all checks. Fix any issues inline before output.
+4. Output: `plan.md` path, summary of design decisions, task count.
 
 **HANDOFF:** `/prizmkit-implement`
 
-## Example
+## Examples
+
+### Example 1: New Feature
 
 **Input:** "I want users to upload avatars"
 
 **Phase 0 output:** `.prizmkit/specs/003-user-avatar/spec.md`
 ```markdown
-# Feature: User Avatar Upload
-## User Stories
-### US-1: Upload Avatar
+# User Avatar Upload
+## Overview
+Allow registered users to upload and manage profile pictures.
+## Goals
+### G-1: Upload Avatar
 As a registered user, I want to upload a profile picture,
 so that other users can visually identify me.
 **Acceptance Criteria:**
@@ -119,26 +111,75 @@ so that other users can visually identify me.
 
 **Phase 1-2 output:** `plan.md` excerpt:
 ```markdown
-## Architecture Approach
-Extend existing user profile module. Add S3 integration for file storage.
-
 ## Tasks
-### Phase: Data Layer (T-010~T-019)
-- [ ] [T-010] [US-1] Add avatar_url field to User model — file: src/models/user.ts
-- [ ] [T-011] [US-1] Create S3 upload utility — file: src/lib/s3.ts
-### Phase: API [P] (T-100~T-109)
-- [ ] [T-100] [P] [US-1] POST /api/avatar upload endpoint — file: src/routes/avatar.ts
+### Phase: Foundation (T-010~T-019)
+- [ ] [T-010] [G-1] Add avatar_url field to User model — file: src/models/user.ts
+- [ ] [T-011] [G-1] Create S3 upload utility — file: src/lib/s3.ts
+### Phase: Core [P] (T-100~T-109)
+- [ ] [T-100] [P] [G-1] POST /api/avatar upload endpoint — file: src/routes/avatar.ts
+```
+
+### Example 2: Refactoring
+
+**Input:** "Extract shared auth middleware from the API routes"
+
+**Phase 0 output:** `.prizmkit/specs/004-extract-auth-middleware/spec.md`
+```markdown
+# Extract Auth Middleware
+## Overview
+Consolidate duplicated authentication logic scattered across route files into a single shared middleware.
+## Goals
+### G-1: Extract Shared Authentication Logic
+Consolidate duplicated auth checks from 5 route files into a single middleware module.
+**Acceptance Criteria:**
+- All existing auth-related tests pass without modification
+- Auth logic exists in exactly one file (src/middleware/auth.ts)
+- No route file contains inline token verification
+## Scope
+- **In scope:** src/routes/users.ts, orders.ts, admin.ts, payments.ts, profile.ts
+- **Out of scope:** Authorization (role-based access), rate limiting
+## Behavior Preservation
+- All 23 existing API tests must pass unchanged
+- Response formats and HTTP status codes must not change
+- Error message strings must remain identical
+```
+
+### Example 3: Bug Fix
+
+**Input:** "Login page crashes when API returns 401"
+
+**Phase 0 output:** `.prizmkit/specs/005-login-401-crash/spec.md`
+```markdown
+# Fix: Login Crash on 401 Response
+## Overview
+Login page throws unhandled exception when auth API returns 401, causing a white screen.
+## Goals
+### G-1: Handle 401 Response Gracefully
+When the auth API returns 401, display an error message instead of crashing.
+**Acceptance Criteria:**
+- Given user submits invalid credentials, When API returns 401, Then error message "Invalid credentials" is displayed
+- Given user submits invalid credentials, When API returns 401, Then no unhandled exception is thrown
+## Root Cause
+- Error classification: Runtime
+- Root cause: `AuthService.handleLogin()` at src/services/auth.ts:42 does not handle null token
+- Affected files: src/services/auth.ts (L42), src/pages/login.tsx (L28)
+## Scope
+- **In scope:** Null handling in auth service, error display in login page
+- **Out of scope:** Other HTTP error codes (403, 500), auth flow redesign
+## Behavior Preservation
+- All existing login success tests must pass unchanged
+- Auth token flow for valid credentials must not change
 ```
 
-## Templates
+## References
 
 - Spec template: `${SKILL_DIR}/assets/spec-template.md`
 - Plan template: `${SKILL_DIR}/assets/plan-template.md`
+- Clarification guide: `${SKILL_DIR}/references/clarify-guide.md`
+- Verification checklist: `${SKILL_DIR}/references/verification-checklist.md`
 
 ## Output
 
-| Mode | Directory | Files |
-|---|---|---|
-| Feature | `.prizmkit/specs/###-feature-name/` | `spec.md` + `plan.md` |
-| Refactor | `.prizmkit/refactor/<refactor-slug>/` | `plan.md` |
-| Bugfix | `.prizmkit/bugfix/<BUG_ID>/` | `plan.md` |
+| Directory | Files |
+|---|---|
+| `artifact_dir` (provided or auto-generated `.prizmkit/specs/###-slug/`) | `spec.md` + `plan.md` |

package/bundled/skills/prizmkit-plan/assets/plan-template.md

@@ -1,7 +1,7 @@
-# Implementation Plan: [FEATURE_TITLE]
+# Plan: [TITLE]
 
-## Architecture Approach
-[How this feature integrates with existing system architecture]
+## Change Approach
+[Description of the technical approach — how these changes integrate with the existing system]
 
 ## Component Design
 
@@ -11,8 +11,17 @@
 ### Modified Components
 - [Component]: [What changes and why]
 
+## Behavior Preservation Strategy
+<!-- Include when the task modifies existing behavior. Delete if not applicable (e.g., greenfield feature). -->
+<!-- Strategy: one of test-gate / snapshot / manual -->
+<!-- test-gate: all tests must pass after each task -->
+<!-- snapshot: before-after comparison of outputs -->
+<!-- manual: reviewer verification at checkpoints -->
+- Strategy: [test-gate / snapshot / manual]
+- Baseline: [describe green test suite or snapshot state]
+
 ## Data Model
-<!-- Skip this section if the feature does not involve database changes -->
+<!-- Include when changes involve database / data persistence. Delete if not applicable. -->
 <!-- IMPORTANT: Read existing schema/model files BEFORE designing new tables -->
 
 ### Existing Schema Audit
@@ -57,8 +66,7 @@
 | [Risk] | [H/M/L] | [Plan] |
 
 ## Deployment Considerations
-<!-- Skip this section if the feature does not affect deployment (no new services, infra, or environment changes) -->
-<!-- Only fill when: new external service added, new database/cache introduced, new env vars required, or infra topology changes -->
+<!-- Include when there is deployment impact (new services, infra, environment changes). Delete if not applicable. -->
 
 ### New Infrastructure Requirements
 - [Component]: [Deployment target from config deploy_strategy] — [any special config needed]
@@ -76,30 +84,32 @@
 - [ ] CI/CD pipeline update needed
 
 ## Pre-Implementation Gates
-- [ ] Spec coverage: all user stories mapped to components
-- [ ] Data model reviewed — existing schema conventions documented and followed
-- [ ] All Data Model `[NEEDS CLARIFICATION]` items resolved (mandatory for DB features)
-- [ ] API contracts defined
+- [ ] Spec coverage: all goals mapped to components
+- [ ] Data model reviewed — existing schema conventions documented and followed (if applicable)
+- [ ] All `[NEEDS CLARIFICATION]` items resolved
 - [ ] Testing approach agreed
+- [ ] Behavior preservation strategy defined (if modifying existing behavior)
+- [ ] Root cause confirmed with reproduction test design (if fixing a defect)
 
 ## Tasks
 
 ### Strategy: [MVP-first | Incremental | Parallel]
 
 ### Phase: Setup
-- [ ] [T-001] Project scaffolding — file: [path]
+- [ ] [T-001] [Description] — file: [path]
 
-### Phase: Foundational
-- [ ] [T-010] [Data model / Schema changes] — file: [path]
+### Phase: Foundation
+- [ ] [T-010] [Description] — file: [path]
 
-### Phase: User Story 1 — [Title]
-- [ ] [T-100] [P] [US1] [Task description] — file: [path]
+### Phase: Core
+<!-- Organize by goals (G-1, G-2, ...) or by logical grouping appropriate to the task -->
+- [ ] [T-100] [P] [G-1] [Task description] — file: [path]
 
 ### Phase: Polish
-- [ ] [T-900] Final integration test
+- [ ] [T-900] Final verification
 - [ ] [T-901] Documentation update
 
 ### Checkpoints
 - [ ] [CP-1] After Setup: project builds and tests pass
-- [ ] [CP-2] After Foundational: data model verified
-- [ ] [CP-3] After each US: acceptance criteria pass
+- [ ] [CP-2] After Foundation: base changes verified
+- [ ] [CP-3] After each Core group: acceptance criteria pass

package/bundled/skills/prizmkit-plan/assets/spec-template.md

@@ -1,17 +1,19 @@
-# Feature: [FEATURE_TITLE]
+# [TITLE]
 
 ## Overview
-[One paragraph describing the feature purpose and business value]
+[One paragraph describing the purpose and motivation]
 
-## User Stories
+## Goals
 
-### US1: [Story Title]
-**As a** [role]
-**I want** [capability]
-**So that** [benefit]
+### G-1: [Goal Title]
+[Goal description — use whatever format best suits the task:
+  - User Story format: "As a [role], I want [capability], so that [benefit]."
+  - Objective format: "Objective: [change to make]. Target state: [desired outcome]."
+  - Fix format: "Fix: [symptom]. Root cause: [brief cause]."
+  - Or any other clear format.]
 
 **Acceptance Criteria:**
-- [ ] Given [context], When [action], Then [expected result]
+- [ ] [Criterion 1 — Given/When/Then, or a concrete verifiable statement]
 
 ## Scope
 
@@ -21,14 +23,27 @@
 ### Out of Scope
 - [Item 1]
 
+## Behavior Preservation
+<!-- Include this section when the task modifies existing behavior (refactoring, bug fixes, migrations, etc.). Delete if not applicable. -->
+- [What behavior / contracts / interfaces must remain unchanged]
+- [Existing test suites that must continue to pass]
+
+## Root Cause
+<!-- Include this section when the task is fixing a defect. Delete if not applicable. -->
+- Error classification: [Runtime / Network / Auth / Data / Logic / Config / External]
+- Root cause: [specific code location and mechanism]
+- Affected files: [file list with line numbers]
+- Impact: [blast radius — which modules / features are affected]
+
 ## Dependencies
 - [Dependency 1]: [Why needed]
 
-## Data Model (if feature involves database changes)
+## Data Model
+<!-- Include this section when changes involve database / data persistence. Delete if not applicable. -->
 
 ### Existing Schema Reference
 <!-- Read existing schema/model files BEFORE designing new tables. Document observed conventions here. -->
-- Tables reviewed: [list existing tables related to this feature]
+- Tables reviewed: [list existing tables related to this change]
 - Naming convention: [snake_case/camelCase — match existing]
 - ID strategy: [UUID/auto-increment — match existing]
 - Timestamp pattern: [created_at/updated_at — match existing]
@@ -50,7 +65,9 @@
 [NEEDS CLARIFICATION]: [Ambiguous item]
 
 ## Review Checklist
-- [ ] All user stories have acceptance criteria
+- [ ] All goals have acceptance criteria
 - [ ] Scope boundaries are clearly defined
 - [ ] Dependencies are identified
 - [ ] No implementation details (WHAT not HOW)
+- [ ] Behavior preservation defined (if modifying existing behavior)
+- [ ] Root cause identified with evidence (if fixing a defect)

package/bundled/skills/prizmkit-plan/references/clarify-guide.md

@@ -9,7 +9,7 @@ Invoked automatically during `/prizmkit-plan` Phase 0 (specify) when `[NEEDS CLA
 **Ask one question at a time.** Batching questions produces lower-quality answers.
 
 For each question:
-1. Cite the exact location in spec.md (e.g., "§3.2 says...")
+1. Cite the exact location in spec.md (e.g., "§Goals G-1 says..." or "§Scope says...")
 2. State what is ambiguous and why it matters for implementation
 3. Provide a **recommended answer** with rationale — gives the user a concrete starting point to accept, modify, or reject
 
@@ -45,7 +45,7 @@ If the user says "done", "stop", or "enough" — end immediately and output a su
 ## Example Exchange
 
 **Question:**
-> §3.2 says "User can upload files" but doesn't specify file types or size limits.
+> §Goals G-1 says "User can upload files" but doesn't specify file types or size limits.
 >
 > **Recommended:** Accept JPEG, PNG, PDF up to 10MB — covers common use cases without straining storage.
 >
@@ -53,7 +53,7 @@ If the user says "done", "stop", or "enough" — end immediately and output a su
 
 **User:** "Also allow SVG, make it 25MB"
 
-**Action:** Update spec.md §3.2 → `File upload: JPEG, PNG, PDF, SVG. Max 25MB per file.` Remove marker.
+**Action:** Update spec.md §Goals G-1 → `File upload: JPEG, PNG, PDF, SVG. Max 25MB per file.` Remove marker.
 
 **Follow-up question triggered by answer:**
 > SVGs can contain embedded scripts (XSS risk). Should uploaded SVGs be sanitized (strip `<script>` + event handlers), or restricted to trusted users only?

package/bundled/skills/prizmkit-plan/references/verification-checklist.md

@@ -0,0 +1,60 @@
+# Verification Checklist — Spec & Plan Consistency
+
+Run this checklist after generating the Tasks section in plan.md. Fix any issues inline before outputting the final plan.
+
+---
+
+## Coverage
+
+- [ ] Every goal (G-N) in spec.md has at least one task in plan.md
+- [ ] Every task has a target file path (`— file: path/to/file`)
+- [ ] Risk assessment contains at least one risk with a mitigation plan
+- [ ] If spec includes `## Behavior Preservation` → at least one verification task exists
+- [ ] If spec includes `## Root Cause` → at least one reproduction test task exists
+
+## Duplication Detection
+
+- [ ] No near-duplicate requirements exist across spec.md sections (same intent, different wording)
+- [ ] If duplicates found, consolidate to the clearer phrasing and remove the other
+
+## Orphan Detection
+
+- [ ] No task exists without a mapped goal (orphan task)
+- [ ] No plan component exists without a corresponding spec requirement
+
+## Ambiguity Scan
+
+- [ ] No unresolved `[NEEDS CLARIFICATION]`, TBD, TODO, or `???` markers remain
+- [ ] No vague criteria without measurable thresholds (e.g., "fast", "secure", "scalable", "intuitive" — replace with concrete numbers or conditions)
+
+## Terminology Consistency
+
+- [ ] Same concept uses the same name in both spec.md and plan.md (no terminology drift)
+- [ ] Data entities referenced in plan.md exist in spec.md (and vice versa)
+
+## Task Ordering
+
+- [ ] No task references the output of a later task without an explicit dependency note
+- [ ] Foundation tasks precede Core tasks that depend on them
+- [ ] Checkpoint tasks exist between phases
+
+## Rules Alignment
+
+- [ ] No spec or plan element conflicts with `.prizm-docs/root.prizm` RULES MUST/NEVER directives
+- [ ] Tech stack choices in plan.md match `.prizm-docs/root.prizm` TECH_STACK (if defined)
+
+## Database Design (skip if no Data Model section)
+
+- [ ] New entity/field naming follows conventions documented in "Existing Schema Audit"
+- [ ] All fields have explicit nullability (NOT NULL or nullable)
+- [ ] Foreign key constraints and indexes are defined
+- [ ] ID strategy and timestamp patterns match existing tables
+- [ ] No unresolved questions remain in Data Model "Unresolved Questions" section
+- [ ] Style Conformance Checklist in plan.md is fully checked
+
+## Action on Failure
+
+If any check fails:
+1. Fix the issue directly in spec.md or plan.md
+2. Re-run the failed checks only
+3. Do not proceed to output until all checks pass