create-ai-project 1.23.1 → 1.23.3

package/.claude/agents-en/acceptance-test-generator.md

@@ -68,6 +68,7 @@ For each valid AC from Phase 1:
    - Happy path (1 test mandatory)
    - Error handling (only user-visible errors)
    - Edge cases (only if high business impact)
+   - Boundary path (behavior-changing AC only): when the AC can hold on the main path while a distinct branch, state, input class, lifecycle step, or fallback regresses, capture that boundary as a proof obligation so the test exercises it
 
 2. **Classify test level**:
    - Integration test candidate (feature-level interaction)
@@ -172,6 +173,8 @@ describe('[Feature Name] Integration Test', () => {
   // @category: core-functionality
   // @dependency: PaymentService, OrderRepository, Database
   // @complexity: high
+  // Primary failure mode: payment succeeds but the order row is absent or unpersisted
+  // Proof obligation: the order is persisted only after a successful payment; the external payment gateway is the only boundary that may be mocked
   it.todo('AC1: Successful payment creates persisted order with correct status')
 
   // AC1-error: "Payment failure shows user-friendly error message"
@@ -180,10 +183,16 @@ describe('[Feature Name] Integration Test', () => {
   // @category: core-functionality
   // @dependency: PaymentService, ErrorHandler
   // @complexity: medium
+  // Primary failure mode: payment failure still creates an order, or the error is swallowed without a user-visible message
+  // Proof obligation: a failed payment surfaces an actionable error and leaves no order persisted; only the payment gateway may be mocked
   it.todo('AC1-error: Failed payment displays error without creating order')
 })
 ```
 
+**Proof annotations** (apply to every skeleton, alongside the metadata above): each `it.todo` carries two comment lines that hand the proof contract to the test implementer and to integration-test-reviewer (these map to the task template's Proof Obligations fields):
+- `Primary failure mode`: the specific regression that turns this test red — the behavior the AC promises and would break
+- `Proof obligation`: what the implemented test must assert to prove the claim — the boundary to traverse, the observable state before/after for state-changing ACs, and which boundaries may be mocked and why. For behavior-changing ACs, name the boundary path (branch, state, input class, lifecycle step, or fallback) the test must traverse when the main path alone would stay green through the regression. Phrase it as design intent describing what to assert; the implementer writes the executable assertions and mock setup
+
 ### E2E Test Files
 
 Generate **separate files per lane**: `*.fixture-e2e.test.[ext]` for fixture-e2e, `*.service-e2e.test.[ext]` for service-integration-e2e. Each emitted file MUST carry a `@lane:` header so downstream agents (work-planner, task-decomposer, executor) can route correctly.
@@ -205,6 +214,8 @@ describe('[Feature Name] fixture-e2e', () => {
   // @lane: fixture-e2e
   // @dependency: full-ui (mocked backend)
   // @complexity: medium
+  // Primary failure mode: a step transition or its observable state is lost across the journey
+  // Proof obligation: each step's UI transition and resulting state are asserted in sequence; only the backend is mocked (canned responses)
   it.todo('User Journey: Cart-to-confirmation flow with mocked payment')
 })
 ```
@@ -226,6 +237,8 @@ describe('[Feature Name] service-integration-e2e', () => {
   // @lane: service-integration-e2e
   // @dependency: full-system
   // @complexity: high
+  // Primary failure mode: the order row or downstream event is absent after a real cross-service purchase
+  // Proof obligation: the DB row, published event, and enqueued email are observed against the real local stack; nothing on the asserted path is mocked
   it.todo('User Journey: Complete purchase persists order and publishes downstream event')
 })
 ```
@@ -240,6 +253,8 @@ describe('[Feature Name] service-integration-e2e', () => {
 // ROI: [value] | Test Type: property-based
 // @category: core-functionality
 // fast-check: fc.property(fc.constantFrom([input variations]), (input) => [invariant])
+// Primary failure mode: an input in the generated domain violates the stated invariant
+// Proof obligation: the invariant holds for all generated inputs; no boundary is mocked
 it.todo('[AC#]-property: [invariant in natural language]')
 ```
 
@@ -316,7 +331,7 @@ Upon completion, report in the following JSON format. Detailed meta information
 ## Constraints and Quality Standards
 
 **Required Compliance**:
-- Output `it.todo` skeletons only: each skeleton contains verification points, expected results, and pass criteria as comments inside `it.todo` blocks.
+- Output `it.todo` skeletons only: each skeleton contains verification points, expected results, pass criteria, primary failure mode, and proof obligation as comments inside `it.todo` blocks.
   Implementation code, assertions (`expect`), and mock setup must not be included — downstream consumers parse `it.todo` presence to determine phase placement and review status.
 - Clearly state verification points, expected results, and pass criteria for each test
 - Preserve original AC statements in comments (ensure traceability)

package/.claude/agents-en/code-reviewer.md

@@ -62,6 +62,9 @@ For each acceptance criterion extracted in Step 1:
 - Determine status: fulfilled / partially fulfilled / unfulfilled
 - Record the file path and relevant code location
 - Note any deviations from the Design Doc specification
+- For behavior-changing ACs, confirm the evidence covers the boundary paths, not only the main path: where a distinct branch, state, input class, lifecycle step, or fallback governs the behavior, verify it is exercised. Compare the source/referenced behavior and the implemented behavior at the same granularity; an unsupported change in a boundary dimension is a `dd_violation`
+- Confirm the implementation keeps the core mechanism the AC, Design Doc, or referenced materials explicitly require; cite the source phrase. A simpler substitute that passes tests but drops the required mechanism is a `dd_violation`
+- For changes to persisted, shared, or externally observable state, identify the publication boundary (where the new state becomes observable to another process, component, user, or later step). State that is observable as complete while still partial, uninitialized, stale, or rollback-only is a `reliability` finding, because a downstream consumer can treat the incomplete state as complete and fail
 
 #### 2-2. Identifier Verification
 
@@ -106,6 +109,11 @@ For each function/method in implementation files, check against coding-standards
   - Counts as coverage: the test body executes at least one assertion that exercises the AC's observable behavior. Intentional-absence assertions (e.g., empty list, null result) count when absence is the AC's expectation
   - Non-substantive examples: `skip`/`xit` left on a test that should run, TODO-only or placeholder body, always-true assertions (e.g., `expect(true).toBe(true)`, `expect(arr.length).toBeGreaterThanOrEqual(0)`)
   - Action on non-substantive: record as `coverage_gap` with rationale citing the AC reference and the specific substance issue (file:line)
+- **Proof verification per cited test** (beyond substance):
+  - When applies: a test counts as substantive coverage for an AC marked fulfilled
+  - Primary-failure-mode source: cite the claim's recorded Proof Obligation (task file) or test skeleton annotation; derive from the AC only when neither exists, so the judgment matches what the test author targeted
+  - Counts as proof: the test turns red under that primary failure mode and exercises the claimed boundary directly
+  - Action when unproven: a test that passes yet would stay green if the claimed behavior regressed → record as `coverage_gap` with rationale naming the unproven failure mode (file:line)
 
 #### Finding Classification
 

package/.claude/agents-en/document-reviewer.md

@@ -23,7 +23,7 @@ You are an AI assistant specialized in technical document review.
   - `composite`: Composite perspective review (recommended) - Verifies structure, implementation, and completeness in one execution
   - When unspecified: Comprehensive review
 
-- **doc_type**: Document type (`PRD`/`ADR`/`UISpec`/`DesignDoc`)
+- **doc_type**: Document type (`PRD`/`ADR`/`UISpec`/`DesignDoc`/`WorkPlan`)
 - **target**: Document path to review
 
 - **code_verification**: Code verification results JSON (optional)
@@ -34,6 +34,10 @@ You are an AI assistant specialized in technical document review.
   - When provided, use `focusAreas` as the canonical source for Fact Disposition coverage checks
   - When absent, mark focusArea completeness as unverifiable for this review
 
+- **design_doc**: Design Doc path(s) (optional, WorkPlan review)
+  - When provided, read it as the source for AC / contract / state-transition coverage checks against the plan
+  - When absent, resolve the Design Doc(s) from the work plan's Related Documents section
+
 ## Workflow
 
 ### Step 0: Input Context Analysis (MANDATORY)
@@ -50,6 +54,7 @@ You are an AI assistant specialized in technical document review.
 - Specialized verification based on doc_type
 - For DesignDoc: Verify "Applicable Standards" section exists with explicit/implicit classification
   - Missing or incomplete → `critical` issue; implicit standards without confirmation → `important` issue
+- For WorkPlan: confirm the plan carries the artifacts the semantic gate is judged against — Design-to-Plan Traceability, Failure Mode Checklist, Review Scope, Verification Strategy summary, and Proof Strategy. Read the referenced Design Doc(s) so AC / contract / state-transition coverage can be checked against the plan's tasks
 - If `code_verification` provided: extract discrepancy list and reverse coverage gaps; feed into Gate 1 as pre-verified evidence
 - If `codebase_analysis` provided: extract `focusAreas` and their `evidence` values for Gate 0 / Gate 1 Fact Disposition checks
 
@@ -71,6 +76,13 @@ For DesignDoc, additionally verify:
 - [ ] Fact Disposition Table section exists in the Design Doc
 - [ ] Minimal Surface Alternatives section present with one entry per new in-scope element (persistent state; public-contract elements or cross-boundary fields/props — for backend, fields crossing module/service boundaries; for frontend, public API props of exported reusable components, Context values, or state lifted across ownership boundaries; behavioral mode/flag/variant; reusable abstraction or component split) when the design introduces any. Each entry contains the 5-step output (fixed requirements with AC references — AC ID, AC heading, EARS clause, or constraint ID — from the Design Doc or referenced PRD/UI Spec; alternatives table including at least one subtractive alternative; selected alternative with rationale; rejected alternatives log)
 
+For WorkPlan, additionally verify:
+- [ ] Review Scope recorded (planned-files scope, or base branch + diff range for a revision plan)
+- [ ] Design-to-Plan Traceability table present with every row mapped to a task or carrying a justified gap
+- [ ] Verification Strategy summary and Proof Strategy present
+- [ ] Failure Mode Checklist present
+- [ ] Final phase includes Quality Assurance (acceptance criteria achievement, all tests passing)
+
 #### Gate 1: Quality Assessment (only after Gate 0 passes)
 
 **Comprehensive Review Mode**:
@@ -113,6 +125,14 @@ For DesignDoc, additionally verify:
     - (3) Step 4 rationale either selects the smallest alternative or names a current requirement smaller alternatives fail to satisfy — "useful" / "future-ready" / "convenient" / "users might want" used as primary rationale → `critical` issue (category: `compliance`).
     - (4) Step 5 records the rejected alternatives with brief rationale — missing rejected alternatives log → `important` issue (category: `completeness`). Note: the zero-alternative case is already trapped at `critical` by sub-check (2); sub-check (4) catches the case where alternatives were generated but the log is missing.
 
+- **Work plan semantic gate** (doc_type WorkPlan):
+  - (1) Coverage is checked where each item lives in the plan: each acceptance criterion is covered by a task — evidenced by a Design-to-Plan Traceability row mapping it to a task, or the task's completion criteria or Proof Obligations referencing it; each data contract and state transition has a Design-to-Plan Traceability row mapping to a task or an explicit out-of-scope entry; each quality assurance mechanism appears in the Quality Assurance Mechanisms table with covered files. An item with no such coverage → `critical` issue (category: `completeness`). Distinguish the cause for an uncovered acceptance criterion: when the Design Doc supports it but no task maps to it (plan omission, fixable by re-planning) → `critical`; when the Design Doc or inputs give it no basis (a gap re-planning cannot fix) → the `rejected` trigger per the Verdict mapping below
+  - (2) The early verification point sits in an early phase rather than the final phase — deferral to the final phase → `important` issue (category: `consistency`)
+  - (3) Each cross-boundary, public-boundary, or persisted-state change names a task that verifies it through the real boundary — missing → `important` issue (category: `completeness`)
+  - (4) Each traceability table present (Design-to-Plan, UI Spec Component, Connection Map, ADR Bindings) is filled to a granularity that resolves its target task — under-specified rows → `important` issue (category: `completeness`)
+  - (5) The Failure Mode Checklist covers the plan's applicable domain-independent categories (same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility) — missing applicable category → `recommended` issue (category: `completeness`)
+  - Verdict mapping (WorkPlan): any semantic-gate `critical` issue forces the verdict to at least `needs_revision` — except a coverage gap traceable to a missing or contradictory Design Doc/input element (which re-planning cannot fix) → `rejected`; an `important`-only set caps the verdict at `approved_with_conditions`
+
 **Perspective-specific Mode**:
 - Implement review based on specified mode and focus
 

package/.claude/agents-en/integration-test-reviewer.md

@@ -73,6 +73,15 @@ Verify the following for each test case:
 | Internal Components | Use actual | Unnecessary mocking |
 | Log Output Verification | Use vi.fn() | Mock without verification |
 
+### 5. Claim Proof Adequacy
+
+Take each AC's primary failure mode and proof obligation from the test's skeleton annotation (the `Primary failure mode` / `Proof obligation` comments) as the source of truth — these correspond to the task template's Proof Obligations fields. Confirm each test proves its claim: an assertion observes the promised behavior so the test fails if that behavior regresses. Record a `proof_insufficient` issue for each obligation the test leaves unproven:
+- The test turns red under the recorded primary failure mode (an assertion observes the specific behavior the AC promises, so a regression in that behavior fails the test).
+- When the AC claims a public or integration boundary, the test exercises that boundary directly.
+- When the AC claims a state change, side effect, rollback, non-mutating mode, idempotency, or persistence, the test asserts the observable state before the action, the action, and the observable state after.
+- Each mocked boundary is an external dependency, with the boundary under test left real, and a comment records why that boundary may be mocked.
+- Integration and E2E tests use bounded fixtures and assert outcomes that hold regardless of shared state, real data volume, or execution order.
+
 ## Output Format
 
 ### Output Protocol
@@ -116,7 +125,7 @@ Final message: exactly one JSON object matching the schema below (begins with `{
   "qualityIssues": [
     {
       "severity": "high | medium | low",
-      "category": "aaa_structure | independence | reproducibility | mock_boundary | readability",
+      "category": "aaa_structure | independence | reproducibility | mock_boundary | proof_insufficient | readability",
       "location": "[file:line number]",
       "description": "[Problem description]",
       "suggestion": "[Specific fix proposal]"
@@ -207,4 +216,5 @@ When needs_revision decision, output fix instructions usable in subsequent proce
 
 - [ ] All skeleton comments verified against implementation
 - [ ] Implementation quality evaluated
+- [ ] Each test proves its AC's claim: turns red under the primary failure mode, exercises the claimed boundary, and asserts before/after state for state-changing claims
 - [ ] Mock boundaries verified (integration tests)

package/.claude/agents-en/task-decomposer.md

@@ -104,6 +104,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
    - Concrete implementation steps
    - **Quality Assurance Mechanisms** (derived from work plan header — see Quality Assurance Mechanism Propagation below)
    - **Operation Verification Methods** (derived from Verification Strategy in work plan)
+   - **Proof Obligations** (per claim — see Proof Obligation Propagation below)
    - Completion criteria
 
 6. **Investigation Targets Determination**
@@ -152,6 +153,14 @@ When the work plan includes a Verification Strategy, derive each task's Operatio
    - **Verification level**: Select L1/L2/L3 per implementation-approach skill
 3. **Investigation Targets**: Include resources needed for verification (e.g., existing implementation for comparison, schema definitions, seed data paths)
 
+## Proof Obligation Propagation
+
+Each task that implements a claim carries Proof Obligations (see task template) so downstream review can judge whether the tests prove the claim, not merely run:
+
+1. **Source**: When a test skeleton covers the task, copy its `Primary failure mode` and `Proof obligation` annotations into the task's Proof Obligations. When no skeleton covers the claim, derive the primary failure mode from the AC, and derive the boundary, before/after state assertion, mock boundary rationale, and residual from the AC and the task's target files (mark `N/A` for fields the claim does not exercise — e.g., no state assertion for a non-state-changing claim).
+2. **Per claim**: Record one entry per AC or claim, populating all Proof Obligations fields defined in the task template.
+3. **Apply when claims exist**: Tasks with no behavioral claim (e.g., pure config or scaffolding) omit the section.
+
 ## UI Spec Propagation
 
 When the work plan contains a UI Spec Component → Task Mapping table, propagate component references to each implementation task as follows:
@@ -348,6 +357,7 @@ Please execute decomposed tasks according to the order.
 - [ ] Overall design document creation
 - [ ] Implementation efficiency and rework prevention (pre-identification of common processing, clarification of impact scope)
 - [ ] Investigation Targets specified for every task (specific file paths, not vague categories)
+- [ ] Proof Obligations recorded for each claim-implementing task (primary failure mode + boundary to exercise)
 - [ ] Quality Assurance Mechanisms from work plan header propagated to relevant tasks
 
 ## Task Design Principles

package/.claude/agents-en/task-executor-frontend.md

@@ -94,6 +94,12 @@ Escalation thresholds:
 - Exactly the pair (a+c) or (b+c) → Escalation; any other 2-indicator combination → Continue
 - 1 or fewer indicators match → Continue implementation
 
+### Step4: Core Mechanism Preservation Check (Any YES → Immediate Escalation)
+Preserve the core mechanism the task, AC, Design Doc, or UI Spec requires. Implementation details (variable names, internal logic order, local structure) stay free to change; the required mechanism itself stays intact.
+□ Required core mechanism replaced by a simpler or weaker substitute? (passing tests do not make a substitute acceptable)
+□ Required core mechanism infeasible as specified?
+Any YES → stop and escalate with `escalation_type: "design_compliance_violation"` per the Escalation Response table, mapping the case to the contract fields: `design_doc_expectation` = the required mechanism and the source phrase it cites (task/AC/Design Doc/UI Spec); `actual_situation` = the proposed substitute and the resulting behavioral delta; `why_cannot_implement` = why the required mechanism was replaced or is infeasible as specified; `attempted_approaches[]` = the ways attempted to preserve the required mechanism, or `[]` when infeasibility is known before implementation; `claude_recommendation` = the condition that would lift the block.
+
 ### Boundary Cases and Iron Rule
 
 | Case | Continue | Escalate |
@@ -105,7 +111,7 @@ Escalation thresholds:
 
 **Iron Rule — escalate when objectively undeterminable**: 2+ valid interpretations for a judgment item; pattern unprecedented in past implementation experience; required information not in Design Doc; equivalent engineers would split on the call.
 
-### Implementation Continuable (all Step1-3 checks NO and clearly applicable)
+### Implementation Continuable (all Step1-4 checks NO and clearly applicable)
 Internal detail optimization (variable names, logic order); specs not in Design Doc; safe `unknown` → concrete type guard for external API responses; minor UI/message text adjustments.
 
 ## Responsibilities, Authority, and Boundaries

package/.claude/agents-en/task-executor.md

@@ -94,6 +94,12 @@ Escalation thresholds:
 - Exactly the pair (a+c) or (b+c) → Escalation; any other 2-indicator combination → Continue
 - 1 or fewer indicators match → Continue implementation
 
+### Step4: Core Mechanism Preservation Check (Any YES → Immediate Escalation)
+Preserve the core mechanism the task, AC, Design Doc, or referenced materials require. Implementation details (variable names, internal ordering, local structure) stay free to change; the required mechanism itself stays intact.
+□ Required core mechanism replaced by a simpler or weaker substitute? (passing tests do not make a substitute acceptable)
+□ Required core mechanism infeasible as specified?
+Any YES → stop and escalate with `escalation_type: "design_compliance_violation"` per the Escalation Response table, mapping the case to the contract fields: `design_doc_expectation` = the required mechanism and the source phrase it cites (task/AC/Design Doc/referenced material); `actual_situation` = the proposed substitute and the resulting behavioral delta; `why_cannot_implement` = why the required mechanism was replaced or is infeasible as specified; `attempted_approaches[]` = the ways attempted to preserve the required mechanism, or `[]` when infeasibility is known before implementation; `claude_recommendation` = the condition that would lift the block.
+
 ### Boundary Cases and Iron Rule
 
 | Case | Continue | Escalate |
@@ -105,7 +111,7 @@ Escalation thresholds:
 
 **Iron Rule — escalate when objectively undeterminable**: 2+ valid interpretations for a judgment item; pattern unprecedented in past implementation experience; required information not in Design Doc; equivalent engineers would split on the call.
 
-### Implementation Continuable (all Step1-3 checks NO and clearly applicable)
+### Implementation Continuable (all Step1-4 checks NO and clearly applicable)
 Internal detail optimization (variable names, processing order); specs not in Design Doc; safe `unknown` → concrete type guard; minor UI/message text adjustments.
 
 ## Responsibilities, Authority, and Boundaries

package/.claude/agents-en/technical-designer-frontend.md

@@ -30,29 +30,7 @@ Follow documentation-criteria skill for ADR/Design Doc creation thresholds. If a
 
 ### Gate Ordering [BLOCKING]
 
-The subsections below are not parallel mandates; they form four serial gates. Complete each gate fully before starting the next. Within a gate, all listed subsections are required (subject to each subsection's own conditions).
-
-**Gate 0 — Inputs and Standards** (no upstream dependencies):
-- Agreement Checklist
-- Standards Identification
-
-**Gate 1 — Existing State Analysis** (depends on Gate 0):
-- Existing Code Investigation
-- Fact Disposition (when Codebase Analysis input is provided)
-- Minimal Surface Alternatives (when introducing persistent client/server state, props or fields crossing ownership boundaries — public API props of exported reusable components, Context values, or state lifted across ownership boundaries — behavioral modes/variants that change observable behavior, or reusable component splits)
-
-**Gate 2 — Design Decisions** (depends on Gate 1):
-- Implementation Approach Decision
-- Common ADR Process
-- Data Contracts
-- State Transitions (when applicable)
-
-**Gate 3 — Impact Documentation** (depends on Gate 2):
-- Integration Point Analysis
-- Change Impact Map
-- Interface Change Impact Analysis
-
-Each subsection below carries a `[Gate N — ...]` annotation in its heading. Subsections appear in Gate order (Gate 0 → 1 → 2 → 3); execute them in document order.
+The subsections below are not parallel mandates; they form four serial gates: **Gate 0** Inputs & Standards → **Gate 1** Existing-State Analysis → **Gate 2** Design Decisions → **Gate 3** Impact Documentation. Complete each gate fully before starting the next. Each subsection below carries a `[Gate N — ...]` annotation (with its own applicability condition) in its heading and appears in Gate order; execute them in document order.
 
 ### Agreement Checklist [Gate 0 — Required]
 Must be performed at the beginning of Design Doc creation:
@@ -331,31 +309,7 @@ Consistency first (follow existing React component patterns; document reason whe
 
 **MANDATORY**: implementation samples in ADR/Design Docs MUST comply with frontend-typescript-rules skill. Required: function components (class components deprecated); Props type definitions on all components; custom hooks for logic reuse; strict types (`unknown` + type guards for external API responses, `any` prohibited); Error Boundary / error state management; environment variables — secrets server-side only.
 
-Compliant sample (function component with Props type, custom hook with `unknown` type-guarded fetch):
-
-```typescript
-type ButtonProps = { label: string; onClick: () => void; disabled?: boolean }
-export function Button({ label, onClick, disabled = false }: ButtonProps) {
-  return <button onClick={onClick} disabled={disabled}>{label}</button>
-}
-
-function useUserData(userId: string) {
-  const [user, setUser] = useState<User | null>(null)
-  const [error, setError] = useState<Error | null>(null)
-  useEffect(() => {
-    void (async () => {
-      try {
-        const data: unknown = await (await fetch(`/api/users/${userId}`)).json()
-        if (!isUser(data)) throw new Error('Invalid user data')
-        setUser(data)
-      } catch (e) { setError(e instanceof Error ? e : new Error('Unknown error')) }
-    })()
-  }, [userId])
-  return { user, error }
-}
-```
-
-Non-compliant: class components, `any`, untyped responses without guards, secrets embedded client-side.
+Non-compliant: class components (except Error Boundaries), `any`, untyped responses without guards, secrets embedded client-side.
 
 ## Diagram Creation (mermaid)
 
@@ -394,6 +348,14 @@ Non-compliant: class components, `any`, untyped responses without guards, secret
 
 ## Acceptance Criteria Creation Guidelines
 
+### Value-First Drafting and Boundary Expansion
+
+Draft each AC value-first, then expand it across requirement boundaries before applying the scoping rules below:
+
+1. **Value first**: name the user value, then the observable UI behavior that delivers it, then the technical boundary that realizes it.
+2. **Expand across boundaries** (candidate extraction — the scoping rules below decide which to keep): a behavior can hold on the happy path while regressing on a separate state. For each behavior-changing AC, consider an AC wherever the promised behavior must also hold — single/latest/full list rendering, sibling props or fields, loading/empty/error and later interaction states, stale or missing data, failed fetches or fallback UI, permission/validation gating, input scope and ordering/selection, side effects, and visibility or route boundaries (state becoming observable on another screen, to another component, or after navigation).
+3. **Compare at the same granularity**: when the AC concerns existing or referenced behavior, state the source behavior and the target behavior at the same level of detail, so a reviewer can confirm each boundary is preserved or intentionally changed.
+
 ### AC Scoping for Autonomous Implementation (Frontend)
 
 **Principle**: AC = User-observable behavior in browser verifiable in isolated CI environment. Cover happy path, unhappy path (errors), and edge cases (empty/loading states); prioritize important ACs at the top; document non-functional requirements in a separate section.

package/.claude/agents-en/technical-designer.md

@@ -29,31 +29,7 @@ Follow documentation-criteria skill for ADR/Design Doc creation thresholds. If a
 
 ### Gate Ordering [BLOCKING]
 
-The subsections below are not parallel mandates; they form four serial gates. Complete each gate fully before starting the next. Within a gate, all listed subsections are required (subject to each subsection's own conditions).
-
-**Gate 0 — Inputs and Standards** (no upstream dependencies):
-- Agreement Checklist
-- Standards Identification
-
-**Gate 1 — Existing State Analysis** (depends on Gate 0):
-- Existing Code Investigation
-- Fact Disposition (when Codebase Analysis input is provided)
-- Data Representation Decision (when new or modified data structures are introduced)
-- Minimal Surface Alternatives (when introducing persistent state, public-contract elements or cross-boundary fields, behavioral modes/flags, or reusable abstractions)
-
-**Gate 2 — Design Decisions** (depends on Gate 1):
-- Implementation Approach Decision
-- Common ADR Process
-- Data Contracts
-- State Transitions (when applicable)
-
-**Gate 3 — Impact Documentation** (depends on Gate 2):
-- Integration Points
-- Change Impact Map
-- Field Propagation Map (when fields cross component boundaries)
-- Interface Change Impact Analysis
-
-Each subsection below carries a `[Gate N — ...]` annotation in its heading. Subsections appear in Gate order (Gate 0 → 1 → 2 → 3); execute them in document order.
+The subsections below are not parallel mandates; they form four serial gates: **Gate 0** Inputs & Standards → **Gate 1** Existing-State Analysis → **Gate 2** Design Decisions → **Gate 3** Impact Documentation. Complete each gate fully before starting the next. Each subsection below carries a `[Gate N — ...]` annotation (with its own applicability condition) in its heading and appears in Gate order; execute them in document order.
 
 ### Agreement Checklist [Gate 0 — Required]
 Must be performed at the beginning of Design Doc creation:
@@ -370,6 +346,14 @@ Consistency first (follow existing patterns; document reason when introducing ne
 
 ## Acceptance Criteria Creation Guidelines
 
+### Value-First Drafting and Boundary Expansion
+
+Draft each AC value-first, then expand it across requirement boundaries before applying the rules below:
+
+1. **Value first**: name the user/operator/maintainer value, then the observable behavior that delivers it, then the technical boundary that realizes it.
+2. **Expand across boundaries** (candidate extraction — the rules below decide which to keep): a behavior can hold on the main path while regressing on a separate dimension. For each behavior-changing AC, consider an AC wherever the promised behavior must also hold — single/latest/full collection, sibling fields on the same surface, later lifecycle states and retries, stale/missing/empty values, failed refreshes or unavailable fallbacks, permission/validation/policy boundaries, input scope and selection/ordering/identity keys, side effects, and publication or visibility boundaries (state becoming observable to another process, component, user, or later step).
+3. **Compare at the same granularity**: when the AC concerns existing or referenced behavior, state the source behavior and the target behavior at the same level of detail, so a reviewer can confirm each boundary is preserved or intentionally changed.
+
 ### Writing Measurable ACs
 
 **Core Principle**: AC = User-observable behavior verifiable in isolated environment. Cover happy path, unhappy path, and edge cases. Non-functional requirements (performance, reliability, scalability) live in a separate "Non-functional Requirements" section.
@@ -453,4 +437,4 @@ Mode for documenting existing architecture as-is. Used when creating Design Docs
 ### Reverse-Engineer Mode Quality Standard
 - Every claim cites file:line as evidence
 - Identifiers transcribed exactly from code
-- Test existence confirmed by Glob, not assumed
+- Test existence confirmed by Glob, not assumed

package/.claude/agents-en/work-planner.md

@@ -38,6 +38,9 @@ Choose Strategy A (TDD) if test skeletons are provided, Strategy B (implementati
 **Common rules (all approaches)**:
 - **Include Verification Strategy summary in work plan header** for downstream task reference
 - **Include adopted Quality Assurance Mechanisms in work plan header** for downstream task reference — list each adopted mechanism with tool name, what it enforces, configuration path, and covered files (literal file paths or directory prefixes from Design Doc, or "project-wide" if not scoped to specific files)
+- **Include a Proof Strategy in the work plan header** (see plan template) — name the proof obligation source (test skeleton annotations when skeletons are provided, otherwise each AC's primary failure mode) and state that every claim-implementing task records Proof Obligations for downstream review
+- **Record the Review Scope in the work plan header** — for a fresh pre-implementation plan, the planned-files scope derived from the Design Doc and task target files; for a revision plan over existing work, the base branch and diff range — so the work plan review and downstream verification share one scope
+- **Include a Failure Mode Checklist in the work plan** (see plan template) — enumerate all eight domain-independent failure categories (same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility), mark which apply, and map each applicable one to its covering task(s), keeping entries free of project-specific names
 - Include verification tasks in the phase corresponding to Verification Strategy's verification timing
 - When test skeletons are provided, place integration test implementation in corresponding phases and E2E test execution in the final phase
 - When test skeletons are not provided, include test implementation tasks based on Design Doc acceptance criteria
@@ -364,6 +367,9 @@ When creating work plans, **Phase Structure Diagrams** and **Task Dependency Dia
   - [ ] Every row maps to at least one covering task
 - [ ] Plan header includes `Implementation Readiness: pending` (medium / large only)
 - [ ] Verification Strategy extracted from Design Doc and included in plan header
+- [ ] Proof Strategy included in plan header (proof obligation source + per-task propagation rule)
+- [ ] Review Scope recorded in plan header (base branch / diff range / changed-files scope)
+- [ ] Failure Mode Checklist included, applicable categories mapped to covering tasks, free of project-specific names
 - [ ] Adopted Quality Assurance Mechanisms extracted from Design Doc and included in plan header
 - [ ] Phase structure matches implementation approach (vertical → value unit phases, horizontal → layer phases)
 - [ ] Early verification point placed in Phase 1 (when Verification Strategy specifies one)

package/.claude/agents-ja/acceptance-test-generator.md

@@ -68,6 +68,7 @@ Phase 1から有効な各ACについて:
    - ハッピーパス（1テスト必須）
    - エラーハンドリング（ユーザーから見えるエラーのみ）
    - エッジケース（ビジネス影響が高い場合のみ）
+   - 境界パス（振る舞いを変えるACのみ）: ACがメインパスでは成立しつつ、別個の分岐・状態・入力クラス・ライフサイクルステップ・フォールバックで退行しうる場合、その境界を証明義務として捉え、テストがそこを通過するようにする
 
 2. **テストレベルを分類**:
    - 統合テスト候補（機能レベルの相互作用）
@@ -174,18 +175,26 @@ describe('[機能名] Integration Test', () => {
   // @category: core-functionality
   // @dependency: PaymentService, OrderRepository, Database
   // @complexity: high
+  // 主要な故障モード: 決済は成功したのに注文行が存在しない、または永続化されていない
+  // 証明義務: 注文は決済成功後にのみ永続化される。モックしてよい境界は外部の決済ゲートウェイのみ
   it.todo('AC1: 決済成功で正しいステータスの注文が永続化される')
 
   // AC1-error: "決済失敗でユーザーフレンドリーなエラーメッセージを表示"
   // ROI: 23 (BV:8 × Freq:2 + Legal:0 + Defect:7)
-  // 振る舞い: 決済失敗 → ユーザーに実行可能なエラー表示 → 注文未作成
+  // 振る舞い: 決済失敗 → ユーザーに対処可能なエラー表示 → 注文未作成
   // @category: core-functionality
   // @dependency: PaymentService, ErrorHandler
   // @complexity: medium
+  // 主要な故障モード: 決済失敗でも注文が作成される、またはエラーがユーザーに見える形で表示されず握り潰される
+  // 証明義務: 決済失敗時は対処可能なエラーを提示し、注文を永続化しない。モックしてよいのは決済ゲートウェイのみ
   it.todo('AC1-error: 決済失敗でエラー表示し注文を作成しない')
 })
 ```
 
+**証明注釈**（すべてのスケルトンに、上記メタ情報とともに付与）: 各 `it.todo` は証明コントラクトをテスト実装者と integration-test-reviewer に渡す2行のコメントを持つ（これらは task template の Proof Obligations フィールドに対応する）:
+- `主要な故障モード`: このテストをレッドにする具体的なリグレッション — ACが約束し、壊れると失われる振る舞い
+- `証明義務`: 実装されたテストが主張を証明するためにアサートすべき内容 — 通過する境界、状態変更を伴うACでは操作前後の観測可能な状態、どの境界をなぜモックしてよいか。振る舞いを変えるACでは、メインパスだけでは、そのリグレッションがあってもグリーンのままになる場合に、テストが通過すべき境界パス（分岐・状態・入力クラス・ライフサイクルステップ・フォールバック）を明示する。アサート対象を記述する設計意図として書き、実行可能なアサーションとモック設定は実装者が書く
+
 ### E2Eテストファイル群
 
 レーンごとに**別ファイル**で生成する: fixture-e2eは `*.fixture-e2e.test.[ext]`、service-integration-e2eは `*.service-e2e.test.[ext]`。各出力ファイルには下流エージェント（work-planner、task-decomposer、executor）が正しくルーティングできるよう `@lane:` ヘッダを必ず付与する。
@@ -207,6 +216,8 @@ describe('[機能名] fixture-e2e', () => {
   // @lane: fixture-e2e
   // @dependency: full-ui (mocked backend)
   // @complexity: medium
+  // 主要な故障モード: ジャーニー中のステップ遷移またはその観測可能な状態が失われる
+  // 証明義務: 各ステップの UI 遷移と結果状態を順に検証する。モックするのはバックエンドのみ（固定レスポンス）
   it.todo('ユーザージャーニー: モック決済でのカートから確認までのフロー')
 })
 ```
@@ -228,6 +239,8 @@ describe('[機能名] service-integration-e2e', () => {
   // @lane: service-integration-e2e
   // @dependency: full-system
   // @complexity: high
+  // 主要な故障モード: 実サービス間の購入後に注文行または下流イベントが存在しない
+  // 証明義務: DB行・発行イベント・キュー投入メールを実ローカルスタックに対して観測する。アサート対象の経路上は何もモックしない
   it.todo('ユーザージャーニー: 購入完了で注文が永続化され下流イベントが発行される')
 })
 ```
@@ -242,6 +255,8 @@ describe('[機能名] service-integration-e2e', () => {
 // ROI: [値] | テスト種別: property-based
 // @category: core-functionality
 // fast-check: fc.property(fc.constantFrom([入力バリエーション]), (input) => [不変条件])
+// 主要な故障モード: 生成ドメイン内のある入力が記述された不変条件に違反する
+// 証明義務: 生成された全入力で不変条件が成立する。境界はモックしない
 it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 ```
 
@@ -318,7 +333,7 @@ it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 ## 制約と品質基準
 
 **必須準拠事項**:
-- `it.todo`スケルトンのみ出力: 各スケルトン内にコメントとして検証観点、期待結果、合格基準を記述。
+- `it.todo`スケルトンのみ出力: 各スケルトン内にコメントとして検証観点、期待結果、合格基準、主要な故障モード、証明義務を記述。
   実装コード、アサーション(`expect`)、モックセットアップは含めない — 下流の処理で`it.todo`の有無によりフェーズ配置やレビュー判定が行われる。
 - 各テストの検証観点、期待結果、合格基準を明確に記述
 - コメントに元のAC文を保持（トレーサビリティ確保）

package/.claude/agents-ja/code-reviewer.md

@@ -62,6 +62,9 @@ Step 1で抽出した各受入条件について:
 - ステータスを判定: fulfilled / partially fulfilled / unfulfilled
 - ファイルパスと関連コード箇所を記録
 - Design Doc仕様からの逸脱を記録
+- 振る舞いを変えるACでは、エビデンスがメインパスだけでなく境界パスもカバーしていることを確認する。別個の分岐・状態・入力クラス・ライフサイクルステップ・フォールバックが振る舞いを左右する箇所では、それが実際に通過されていることを検証する。参照元（source）/参照先の振る舞いと実装された振る舞いを同一粒度で比較し、境界次元における根拠のない変更は `dd_violation` とする
+- 実装が AC・Design Doc・参照資料が明示的に要求する中核メカニズムを保持していることを確認し、出所となる文言を引用する。テストは通るが要求された中核メカニズムを落とす単純な代替は `dd_violation` とする
+- 永続化・共有・外部から観測可能な状態への変更では、公開境界（新しい状態が別プロセス・コンポーネント・ユーザー・後続ステップから観測可能になる箇所）を特定する。部分的・未初期化・stale・ロールバックのみでありながら完了として観測可能な状態は `reliability` の検出事項とする。下流の利用者が不完全な状態を完了とみなして失敗しうるためである
 
 #### 2-2. 識別子の検証
 
@@ -106,6 +109,11 @@ Step 1で抽出した各識別子仕様（リソース名、エンドポイン
   - カバレッジとして数える条件: テスト本体で実行されるアサーションのうち少なくとも1つが、AC の観測可能な振る舞いを検証している。意図的な不在を検証するアサーション（例: 空のリスト、null 結果）は、AC が不在を期待する場合に該当する
   - 非実体的な例: 実行されるべきテストに `skip`/`xit` が残っている、TODO のみ・プレースホルダーのみの本体、常に真となるアサーション（例: `expect(true).toBe(true)`、`expect(arr.length).toBeGreaterThanOrEqual(0)`）
   - 非実体的な場合のアクション: `coverage_gap` として記録し、rationale に該当する AC の参照と具体的な実体性の問題（file:line）を記載する
+- **引用された各テストの証明検証（実体性を超えて）**:
+  - 適用対象: fulfilled と判定した AC の実体的なカバレッジとして数えられるテスト
+  - 主要な故障モードの出所: 主張に記録された Proof Obligation（タスクファイル）またはテストスケルトンの注釈を参照する。いずれも存在しない場合のみ AC から導出し、判定がテスト作成者の狙いと一致するようにする
+  - 証明として数える条件: テストがその主要な故障モードでレッドになり、主張された境界を直接通過する
+  - 未証明の場合のアクション: テストはパスするのに、主張された振る舞いがリグレッションしてもグリーンのまま → `coverage_gap` として記録し、rationale に未証明の故障モードを明記（file:line）
 
 #### 検出事項の分類
 

package/.claude/agents-ja/document-reviewer.md

@@ -23,7 +23,7 @@ skills: documentation-criteria, technical-spec, project-context, typescript-rule
   - `composite`: 複合観点レビュー（推奨）- 構造・実装・完全性を一度に検証
   - 未指定時: 総合的レビュー
 
-- **doc_type**: ドキュメントタイプ（`PRD`/`UISpec`/`ADR`/`DesignDoc`）
+- **doc_type**: ドキュメントタイプ（`PRD`/`UISpec`/`ADR`/`DesignDoc`/`WorkPlan`）
 - **target**: レビュー対象のドキュメントパス
 
 - **code_verification**: コード検証結果のJSON（任意）
@@ -34,6 +34,10 @@ skills: documentation-criteria, technical-spec, project-context, typescript-rule
   - 提供された場合、`focusAreas`をFact Dispositionカバレッジチェックの正典ソースとして使用
   - 未提供の場合、focusAreaの完全性は本レビューでは検証不能として扱う
 
+- **design_doc**: Design Docのパス（任意、WorkPlanレビュー用）
+  - 提供された場合、計画に対するAC / コントラクト / 状態遷移のカバレッジチェックのソースとして読み込む
+  - 未提供の場合、作業計画書の「関連ドキュメント」セクションからDesign Docを解決する
+
 ## 作業フロー
 
 ### ステップ0: 入力コンテキスト分析（必須）
@@ -50,6 +54,7 @@ skills: documentation-criteria, technical-spec, project-context, typescript-rule
 - doc_typeに基づく特化した検証
 - DesignDocの場合:「適用基準」セクションの存在をexplicit/implicit分類付きで確認
   - 欠落・不完全 → `critical`、implicit基準の未確認 → `important`
+- WorkPlanの場合: セマンティックゲートの判定対象となる成果物が計画に含まれることを確認 — 設計-計画トレーサビリティ、故障モードチェックリスト、レビュースコープ、検証戦略の要約、証明戦略。参照されているDesign Docを読み込み、AC / コントラクト / 状態遷移のカバレッジを計画のタスクに対して確認できるようにする
 - `code_verification`が提供された場合: 不整合リストと逆方向カバレッジのギャップを抽出し、Gate 1の事前検証エビデンスとして組み込む
 - `codebase_analysis`が提供された場合: `focusAreas`とその`evidence`値を抽出し、Gate 0 / Gate 1のFact Dispositionチェックに使用
 
@@ -71,6 +76,13 @@ DesignDocの場合、追加で以下を確認:
 - [ ] Fact Disposition TableセクションがDesign Docに存在する
 - [ ] Minimal Surface Alternatives セクションが存在し、新規に導入される適用対象要素（永続状態 / 公開コントラクト要素または境界を越えるフィールド・Props — バックエンドではモジュール/サービス境界を越えるフィールド、フロントエンドではエクスポートされた再利用可能コンポーネントの公開 API Props・Context 値・所有境界を越えて持ち上げられた状態 / 振る舞いモード・フラグ・バリアント / 再利用可能な抽象またはコンポーネント分割）ごとに1エントリ持つ（適用対象要素を導入する場合）。各エントリには5ステップの結果が含まれる（確定要件 — Design Docまたは参照PRD/UI SpecのAC参照（AC ID、AC見出し、EARS節、または制約ID）、削減的な代替案を1つ以上含む比較表、根拠付きの選定結果、不採用案の記録）
 
+WorkPlanの場合、追加で以下を確認:
+- [ ] レビュースコープが記録されている（変更予定ファイルの範囲、または改訂計画ではベースブランチ + diff範囲）
+- [ ] 設計-計画トレーサビリティ表が存在し、各行がタスクにマッピングされているか正当化されたギャップを持つ
+- [ ] 検証戦略の要約と証明戦略が存在する
+- [ ] 故障モードチェックリストが存在する
+- [ ] 最終フェーズに品質保証が含まれる（受入基準の達成、全テストのパス）
+
 #### Gate 1: 品質評価（Gate 0通過後のみ実施）
 
 **総合レビューモード**:
@@ -113,6 +125,14 @@ DesignDocの場合、追加で以下を確認:
     - (3) ステップ4 の根拠が、最小の代替案を選定するか、より小さい代替案では満たせない現要件を名指している — 「便利」「将来対応」「実装が楽」「ユーザーが欲しがるかも」が主たる根拠として使われている → `critical`（カテゴリ: `compliance`）。
     - (4) ステップ5 で不採用案が簡潔な根拠とともに記録されている — 不採用案ログの欠落 → `important`（カテゴリ: `completeness`）。注: 代替案ゼロのケースはサブチェック(2)で先に `critical` として検出される。サブチェック(4)は代替案は生成されたが記録が抜けているケースを検出する。
 
+- **作業計画書セマンティックゲート**（doc_type WorkPlan）:
+  - (1) カバレッジは各項目が計画内で存在する場所で確認する: 各受入基準がタスクでカバーされている — 設計-計画トレーサビリティの行がそのACをタスクにマッピングしているか、タスクの完了基準または Proof Obligations がそのACを参照していることで示される。各データコントラクトと状態遷移は、設計-計画トレーサビリティの行でタスクにマッピングされるか、明示的なスコープ外エントリを持つ。各品質保証メカニズムは、カバー対象ファイルとともに品質保証メカニズム表に現れる。いずれのカバレッジもない項目 → `critical`（カテゴリ: `completeness`）。カバーされない受入基準は原因を区別する: Design Docが裏付けるのにタスクがマッピングされていない（計画の漏れ、再計画で修正可能）→ `critical`、Design Docや入力に裏付けがない（再計画でも修正不能なギャップ）→ 下記Verdictマッピングの`rejected`トリガー
+  - (2) 早期検証ポイントが最終フェーズではなく早期フェーズに置かれている — 最終フェーズへの後回し → `important`（カテゴリ: `consistency`）
+  - (3) 境界横断・公開境界・永続状態の各変更が、それを実境界経由で検証するタスクを名指している — 欠落 → `important`（カテゴリ: `completeness`）
+  - (4) 存在する各トレーサビリティ表（設計-計画、UI Specコンポーネント、Connection Map、ADR Bindings）が対象タスクを解決できる粒度で埋められている — 粒度不足の行 → `important`（カテゴリ: `completeness`）
+  - (5) 故障モードチェックリストが計画の該当するドメイン非依存カテゴリ（same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility）をカバーしている — 該当カテゴリの欠落 → `recommended`（カテゴリ: `completeness`）
+  - Verdictマッピング（WorkPlan）: セマンティックゲートの`critical`はいずれもverdictを最低でも`needs_revision`にする — ただしDesign Doc/入力要素の欠落や矛盾に起因するカバレッジギャップ（再計画で修正不能）→ `rejected`、`important`のみの場合はverdictを`approved_with_conditions`までに制限する
+
 **観点特化モード**:
 - 指定されたmodeとfocusに基づいてレビューを実施
 

package/.claude/agents-ja/integration-test-reviewer.md

@@ -73,6 +73,15 @@ skills: integration-e2e-testing, typescript-testing, project-context
 | 内部コンポーネント | 実物使用 | 不要なモック化 |
 | ログ出力検証 | vi.fn()使用 | 検証なしのモック |
 
+### 5. 主張証明の妥当性
+
+各ACの主要な故障モードと証明義務は、テストのスケルトン注釈（「主要な故障モード」/「証明義務」コメント）を出所とする — これらは task template の Proof Obligations フィールドに対応する。各テストが主張を証明していることを確認する: アサーションが約束された振る舞いを観測し、その振る舞いがリグレッションするとテストが失敗する。テストが未証明のまま残す各義務について `proof_insufficient` を記録する:
+- テストが記録された主要な故障モードでレッドになる（アサーションがACの約束する具体的な振る舞いを観測するため、その振る舞いのリグレッションでテストが失敗する）。
+- ACが公開境界または統合境界を主張する場合、テストはその境界を直接通過する。
+- ACが状態変更・副作用・ロールバック・非変更モード・冪等性・永続化を主張する場合、テストは操作前の観測可能な状態、操作、操作後の観測可能な状態をアサートする。
+- モックする各境界は外部依存であり、テスト対象の境界は実物のまま残し、その境界をモックしてよい理由をコメントで記録する。
+- 統合テストとE2Eテストは範囲を限定した fixture を用い、共有状態・実データ量・実行順序によらず成立する結果をアサートする。
+
 ## 出力フォーマット
 
 ### 出力プロトコル
@@ -116,7 +125,7 @@ skills: integration-e2e-testing, typescript-testing, project-context
   "qualityIssues": [
     {
       "severity": "high | medium | low",
-      "category": "aaa_structure | independence | reproducibility | mock_boundary | readability",
+      "category": "aaa_structure | independence | reproducibility | mock_boundary | proof_insufficient | readability",
       "location": "[ファイル:行番号]",
       "description": "[問題の説明]",
       "suggestion": "[具体的な修正提案]"
@@ -207,4 +216,5 @@ needs_revision判定時、後続処理で使用できる修正指示を出力:
 
 - [ ] すべてのスケルトンコメントを実装と照合
 - [ ] 実装品質を評価
+- [ ] 各テストがACの主張を証明している: 主要な故障モードでレッドになり、主張された境界を通過し、状態変更を伴う主張では操作前後の状態をアサートする
 - [ ] Mock境界を検証（統合テスト）