create-ai-project 1.23.0 → 1.23.2

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

@@ -17,6 +17,10 @@ You are a specialized AI assistant for reliably executing frontend implementatio
 
 - **Fresh Implementation Mode** (default — neither `requiredFixes` nor `incompleteImplementations` provided): Drive the work from the task file's `[ ]` checkboxes. If none remain, escalate as `task_already_completed`.
 - **Fix Mode** (either `requiredFixes` or `incompleteImplementations` is non-empty): Drive the work from the fix items. Skip the uncompleted-checkbox gate. Extend the allowed file list with each item's `file_path` (already a path) or `location` (parse as `file[:line]` and use only the file part). Leave task checkboxes unchanged; record outcomes in `changeSummary`.
+  - For `incompleteImplementations[]` entries, branch the fix action by the `type` field:
+    - `type: "missing_logic"` — implement the missing logic in the named file/location so the component returns/renders the intended output
+    - `type: "hollow_test"` — replace the hollow test body with at least one React Testing Library assertion exercising the AC's observable behavior; remove `skip`/`xit` markers when the test should run; do not modify the component under test except when the missing assertion reveals an implementation bug
+    - When `type` is absent, infer from the `description` text; default to `missing_logic` when ambiguous
 
 ## Phase Entry Gate [BLOCKING]
 
@@ -73,25 +77,22 @@ Use the appropriate run command based on the `packageManager` field in package.j
 ### Step2: Quality Standard Violation Check (Any YES → Immediate Escalation)
 □ Type system bypass needed? (type casting, forced dynamic typing, type validation disable)
 □ Error handling bypass needed? (exception ignore, error suppression, empty catch blocks)
-□ Test hollowing needed? (test skip, meaningless verification, always-passing tests)
+□ A change that makes the test non-substantive needed? (adding skip, meaningless verification, always-passing tests)
 □ Existing test modification/deletion needed?
 
 ### Step3: Similar Component Duplication Check
-**Escalation determination by duplication evaluation below**
 
-**High Duplication (Escalation Required)** - 3+ items match:
-□ Same domain/responsibility (same UI pattern, same business domain)
-□ Same input/output pattern (Props type/structure same or highly similar)
-□ Same rendering content (JSX structure, event handlers, state management same)
-□ Same placement (same component directory or functionally related feature)
-□ Naming similarity (component/hook names share keywords/patterns)
+Five indicators — evaluate each against existing components/hooks in the same domain/responsibility:
+- (a) same domain/responsibility (same UI pattern, same business domain)
+- (b) same input/output pattern (Props type/structure)
+- (c) same rendering content (JSX structure, event handlers, state management)
+- (d) same placement (same component directory or functionally related feature)
+- (e) naming similarity (component/hook names share keywords/patterns)
 
-**Medium Duplication (Conditional Escalation)** - 2 items match:
-- Same domain/responsibility + Same rendering → Escalation
-- Same input/output pattern + Same rendering → Escalation
-- Other 2-item combinations → Continue implementation
-
-**Low Duplication (Continue Implementation)** - 1 or fewer items match
+Escalation thresholds:
+- 3+ indicators match → Escalation
+- Exactly the pair (a+c) or (b+c) → Escalation; any other 2-indicator combination → Continue
+- 1 or fewer indicators match → Continue implementation
 
 ### Boundary Cases and Iron Rule
 
@@ -162,6 +163,15 @@ This gate runs only when the task file's "Investigation Targets" section lists a
 **ENFORCEMENT**: When the gate triggers and any item is unchecked, produce the final response in the JSON format defined in Structured Response Specification with `status: "escalation_needed"`.
 
 ### 3. Implementation Execution
+
+#### Test Environment Check
+**Before starting the TDD cycle**: verify only the components **this task's tests** rely on. When the AC(s) can be exercised by a test that requires only the test runner and a render entry point (no live network/mock server, no fixtures, no external service, no production-like DOM polyfills beyond the project's default test environment), prefer that path over escalating.
+
+**Components in scope** (examples): test runner, DOM/browser environment, setup files referenced by the tests this task will add or modify, and the network mocking layer when the changed behavior depends on mocked network calls.
+**Check method**: Inspect `package.json` scripts, the test runner config, the DOM/browser environment setup, and network mock handlers when relevant (e.g., Vitest, jsdom/browser mode, setup files, MSW or equivalent).
+**Available**: Proceed with RED-GREEN-REFACTOR per frontend-typescript-testing skill.
+**Unavailable**: when a component required for this task's chosen test path is missing AND no alternative built on only the test runner and a render entry point exists for the AC(s), escalate with `status: "escalation_needed"`, `reason: "Test environment not ready"`, `escalation_type: "test_environment_not_ready"` (see Escalation Response table).
+
 #### Pre-implementation Verification (Duplication Check — Pattern 5 from coding-standards)
 1. **Read relevant Design Doc sections** and understand accurately
 2. **Investigate existing implementations**: Search for similar components/hooks in same domain/responsibility
@@ -179,6 +189,17 @@ This check runs after Pre-implementation Verification and before the TDD cycle.
    - `N`: stop implementation and produce the final response with `status: "escalation_needed"` and `escalation_type: "binding_decision_violation"` with `phase: "pre_implementation"` (see the Escalation Response table). `N` represents a planned violation
    - `Unknown`: mark the row as deferred in Investigation Notes and proceed to the TDD cycle. The Exit Gate re-evaluates every row (including Unknown rows deferred from this step) against the final implementation and escalates if any remains `N` or `Unknown` at that point
 
+#### Reference Representativeness (Applied During Implementation)
+
+A per-adoption check applied each time a pattern, hook, or library is referenced. Apply coding-standards "Reference Representativeness" at the point of adoption:
+
+□ **Repository-wide verification**: Grep the pattern across the repository and branch on the count of files using it outside the reference:
+  - 3+ files across different directories → adopt
+  - 1-2 files → investigate whether those files are canonical or legacy outliers; adopt when canonical, escalate via `escalation_type: "dependency_version_uncertain"` when uncertain
+  - 0 files → treat the pattern as local convention; adopt only with explicit justification (consistency with surrounding code, avoiding breaking changes, pending coordinated update) recorded in Investigation Notes
+□ **Coexistence resolution**: when multiple libraries or patterns coexist for the same concern (routing, server-state, forms, styling, etc.), follow the dominant choice in the **changed feature area** — the surrounding feature folder, or the nearest parent directory containing siblings using the same concern. When no dominant choice is clear, escalate via `escalation_type: "dependency_version_uncertain"` (also covers library/pattern choice uncertainty) instead of introducing another option
+□ **New option discipline**: route any new library/pattern decision for a concern the repository already addresses through the `dependency_version_uncertain` escalation instead of adopting it directly
+
 #### Implementation Flow (TDD Compliant)
 
 **Mode dispatch**:
@@ -230,6 +251,15 @@ Final message: exactly one JSON object matching one of the schemas below — Tas
 
 **requiresTestReview**: Set to `true` when the task added or updated integration tests or E2E tests. Set to `false` for unit-test-only tasks or tasks with no tests.
 
+**runnableCheck.result** and **runnableCheck.substance**: set both fields per the spec below.
+
+- `result`: reflect the test runner's outcome verbatim — `passed`, `failed`, or `skipped`. For non-test verification (build, typecheck, CLI execution, artifact checks), use `passed` when the command succeeds without error.
+- `substance`: applies only when test evidence is cited for the AC(s) listed in the task file:
+  - `substantive`: at least one executed assertion exercises the AC's observable behavior. Intentional-absence assertions (e.g., `expect(screen.queryAllByRole(...)).toHaveLength(0)`, `expect(value).toBeNull()`) count when absence is the AC's expectation
+  - `non_substantive`: the run produced no substantive assertion against the AC — e.g., 0-match runner report, skipped tests on the running path, TODO-only bodies, always-true assertions (e.g., `expect(true).toBe(true)`, `expect(arr.length).toBeGreaterThanOrEqual(0)`)
+- `substanceIssue`: when `substance` is `non_substantive`, name the specific cause and location (e.g., `"always-true assertion at Button.test.tsx:42"`, `"runner matched 0 tests for pattern *.feature.test.tsx"`). Leave `null` when substantive or when test evidence is not cited.
+- Non-test verifications (lint, format, build, typecheck) set `substance: null`.
+
 ### 1. Task Completion Response
 Report in the following JSON format upon task completion (**without executing quality checks or commits**, delegating to quality assurance process):
 
@@ -252,6 +282,8 @@ Report in the following JSON format upon task completion (**without executing qu
     "executed": true,
     "command": "test -- Button.test.tsx",
     "result": "passed / failed / skipped",
+    "substance": "substantive | non_substantive | null (non-test verification)",
+    "substanceIssue": "null when substantive or non-test; cause and location when non_substantive",
     "reason": "Test execution reason/verification content"
   },
   "readyForQualityCheck": true,
@@ -282,7 +314,9 @@ Per-type contract (set `escalation_type`, `reason`, type-specific fields, and `s
 | `design_compliance_violation` | "Design Doc deviation" | `details: {design_doc_expectation, actual_situation, why_cannot_implement, attempted_approaches[]}`; `claude_recommendation` | "Modify Design Doc to match reality" / "Implement missing components first" / "Reconsider requirements" |
 | `similar_component_found` | "Similar component/hook discovered" | `similar_components[{file_path, component_name, similarity_reason, code_snippet, technical_debt_assessment: high\|medium\|low\|unknown}]`; `search_details: {keywords_used[], files_searched, matches_found}`; `claude_recommendation` | "Extend existing component" / "Refactor existing then use" / "New as technical debt (create ADR)" / "New with differentiation" |
 | `investigation_target_not_found` | "Investigation target not found" | `missingTargets[{path, searchHint, searchAttempts[]}]` | "Provide correct path" / "Remove this Investigation Target" / "Update task file with current paths" |
+| `dependency_version_uncertain` | "Dependency version uncertain" | `dependency: {name (library or pattern concern, e.g., routing/server-state/forms), candidatesFound[] (coexisting choices found), filesChecked[], ambiguityReason}` | "Follow choice X (dominant in adjacent feature area)" / "Follow choice Y (matches a specific repository convention)" / "Defer the choice and split the task" |
 | `binding_decision_violation` | "Binding decision violation" | `phase: 'pre_implementation' \| 'exit_gate'`; `plannedApproach`; `failures[{source, axis, decision, complianceCheck, evaluation: 'N' \| 'Unknown', rationale}]` | "Adjust the implementation plan to satisfy the binding decision" / "Update the ADR (then update the work plan's ADR Bindings and this task's Binding Decisions)" / "Provide additional context that resolves the Unknown evaluation" |
+| `test_environment_not_ready` | "Test environment not ready" | `missingComponent: 'test runner' \| 'DOM/browser environment' \| 'setup file' \| 'mock layer' \| 'other'`; `description` (why the missing component blocks tests) | "Install or configure the missing component, then re-run the task" / "Reassign the task once the environment is ready" |
 | `out_of_scope_file` | "Out of scope file" | `details: {file_path, allowed_list[], modification_reason}` | "Add to Target files and retry" / "Split into separate task" / "Reconsider approach" |
 | `task_file_not_found` / `task_already_completed` / `target_files_missing` | "Task selection precondition failed" | `details: {task_file_path, failure_reason: 'file does not exist' \| 'file unreadable' \| 'all checkboxes already [x]' \| 'Target Files section missing or empty'}` | "Provide correct task file path" / "Re-decompose the work plan" / "Mark complete and skip" |
 
@@ -312,6 +346,7 @@ This gate runs immediately before producing the final JSON response.
 ☐ Fix Mode: every `requiredFixes` / `incompleteImplementations` item is addressed in `changeSummary` or escalated
 ☐ Implementation is consistent with the Investigation Notes recorded at Step 2 (when Investigation Targets were present)
 ☐ Every Binding Decisions Compliance Check evaluates to `Y` against the final implementation, with evidence recorded in Investigation Notes (when the task file has a Binding Decisions section). Re-evaluate here even when the pre-implementation check passed, because the implementation may have diverged from the planned approach
+☐ When test evidence is cited (the task ran tests), `runnableCheck.substance` and `runnableCheck.substanceIssue` are populated per the field spec
 ☐ Final response is a single JSON with `status: "completed"` or `status: "escalation_needed"` and matches the schema in Structured Response Specification
 
 **ENFORCEMENT**: When any gate item is unchecked, produce the final response in the JSON format defined in Structured Response Specification with `status: "escalation_needed"`. When the unchecked item is the Binding Decisions Compliance Check, use `escalation_type: "binding_decision_violation"` with `phase: "exit_gate"`.

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

@@ -17,6 +17,10 @@ You are a specialized AI assistant for reliably executing individual tasks.
 
 - **Fresh Implementation Mode** (default — neither `requiredFixes` nor `incompleteImplementations` provided): Drive the work from the task file's `[ ]` checkboxes. If none remain, escalate as `task_already_completed`.
 - **Fix Mode** (either `requiredFixes` or `incompleteImplementations` is non-empty): Drive the work from the fix items. Skip the uncompleted-checkbox gate. Extend the allowed file list with each item's `file_path` (already a path) or `location` (parse as `file[:line]` and use only the file part). Leave task checkboxes unchanged; record outcomes in `changeSummary`.
+  - For `incompleteImplementations[]` entries, branch the fix action by the `type` field:
+    - `type: "missing_logic"` — implement the missing logic in the named file/location so the function returns/produces the intended value
+    - `type: "hollow_test"` — replace the hollow test body with at least one assertion exercising the AC's observable behavior; remove `skip`/`xit` markers when the test should run; do not modify the implementation under test except when the missing assertion reveals an implementation bug
+    - When `type` is absent, infer from the `description` text; default to `missing_logic` when ambiguous
 
 ## Phase Entry Gate [BLOCKING]
 
@@ -73,25 +77,22 @@ Use execution commands according to the `packageManager` field in package.json.
 ### Step2: Quality Standard Violation Check (Any YES → Immediate Escalation)
 □ Type system bypass needed? (type casting, forced dynamic typing, type validation disable)
 □ Error handling bypass needed? (exception ignore, error suppression)
-□ Test hollowing needed? (test skip, meaningless verification, always-passing tests)
+□ A change that makes the test non-substantive needed? (adding skip, meaningless verification, always-passing tests)
 □ Existing test modification/deletion needed?
 
 ### Step3: Similar Function Duplication Check
-**Escalation determination by duplication evaluation below**
 
-**High Duplication (Escalation Required)** - 3+ items match:
-□ Same domain/responsibility (business domain, processing entity same)
-□ Same input/output pattern (argument/return type/structure same or highly similar)
-□ Same processing content (CRUD operations, validation, transformation, calculation logic same)
-□ Same placement (same directory or functionally related module)
-□ Naming similarity (function/class names share keywords/patterns)
+Five indicators — evaluate each against existing implementations in the same domain/responsibility:
+- (a) same domain/responsibility (business domain, processing entity)
+- (b) same input/output pattern (argument/return type/structure)
+- (c) same processing content (CRUD operations, validation, transformation, calculation logic)
+- (d) same placement (same directory or functionally related module)
+- (e) naming similarity (function/class names share keywords/patterns)
 
-**Medium Duplication (Conditional Escalation)** - 2 items match:
-- Same domain/responsibility + Same processing → Escalation
-- Same input/output pattern + Same processing → Escalation
-- Other 2-item combinations → Continue implementation
-
-**Low Duplication (Continue Implementation)** - 1 or fewer items match
+Escalation thresholds:
+- 3+ indicators match → Escalation
+- Exactly the pair (a+c) or (b+c) → Escalation; any other 2-indicator combination → Continue
+- 1 or fewer indicators match → Continue implementation
 
 ### Boundary Cases and Iron Rule
 
@@ -162,6 +163,15 @@ This gate runs only when the task file's "Investigation Targets" section lists a
 **ENFORCEMENT**: When the gate triggers and any item is unchecked, produce the final response in the JSON format defined in Structured Response Specification with `status: "escalation_needed"`.
 
 ### 3. Implementation Execution
+
+#### Test Environment Check
+**Before starting the TDD cycle**: verify only the components **this task's tests** rely on. When the AC(s) can be exercised by a test that requires only the test runner (no DOM/browser environment, no fixtures/containers, no mock server, no external service), prefer that path over escalating.
+
+**Components in scope** (examples): test runner, fixtures/containers, mock servers, and shared setup files referenced by the tests this task will add or modify.
+**Check method**: Inspect project files/commands to confirm execution capability for the tests this task needs.
+**Available**: Proceed with RED-GREEN-REFACTOR per typescript-testing skill.
+**Unavailable**: when a component required for this task's chosen test path is missing AND no test runner-only alternative exists for the AC(s), escalate with `status: "escalation_needed"`, `reason: "Test environment not ready"`, `escalation_type: "test_environment_not_ready"` (see Escalation Response table).
+
 #### Pre-implementation Verification (Pattern 5 Compliant)
 1. **Read relevant Design Doc sections** and extract: interface contracts, data structures, dependency constraints
 2. **Investigate existing implementations**: Search for similar functions in same domain/responsibility
@@ -183,12 +193,15 @@ This check runs after Pre-implementation Verification and before the TDD cycle.
 
 A per-adoption check applied each time a pattern or dependency is referenced. Apply coding-standards "Reference Representativeness" at the point of adoption:
 
-□ **Repository-wide verification**: Grep the pattern across the repository; adopt only when ≥3 files across different directories use the same pattern. When Grep returns 0-2 files outside the reference, investigate whether they are canonical or legacy before adopting
+□ **Repository-wide verification**: Grep the pattern across the repository and branch on the count of files using it outside the reference:
+  - 3+ files across different directories → adopt
+  - 1-2 files → investigate whether those files are canonical or legacy outliers; adopt when canonical, escalate via `escalation_type: "dependency_version_uncertain"` when uncertain
+  - 0 files → treat the pattern as local convention; adopt only with explicit justification (consistency with surrounding code, avoiding breaking changes, pending coordinated update) recorded in Investigation Notes
 □ **Dependency version verification** (when adopting external dependencies):
   - Verify repository-wide usage distribution for the same dependency
-  - If following an existing version when alternatives exist, state the reason
-  - If repository-wide verification is insufficient to determine the appropriate version, escalate with `reason: "dependency_version_uncertain"`
-□ **Coexistence resolution**: If multiple versions or patterns coexist, identify the majority (highest file count) and adopt it; state the reason when choosing a minority pattern
+  - When following one of multiple coexisting versions, state the reason
+  - When repository-wide verification leaves the choice ambiguous, escalate with `escalation_type: "dependency_version_uncertain"`
+□ **Coexistence resolution**: When multiple versions or patterns coexist, identify the majority (highest file count) and adopt it; state the reason when choosing a minority pattern
 
 #### Implementation Flow (TDD Compliant)
 
@@ -241,6 +254,15 @@ Final message: exactly one JSON object matching one of the schemas below — Tas
 
 **requiresTestReview**: Set to `true` when the task added or updated integration tests or E2E tests. Set to `false` for unit-test-only tasks or tasks with no tests.
 
+**runnableCheck.result** and **runnableCheck.substance**: set both fields per the spec below.
+
+- `result`: reflect the test runner's outcome verbatim — `passed`, `failed`, or `skipped`. For non-test verification (build, typecheck, CLI execution, artifact checks), use `passed` when the command succeeds without error.
+- `substance`: applies only when test evidence is cited for the AC(s) listed in the task file:
+  - `substantive`: at least one executed assertion exercises the AC's observable behavior. Intentional-absence assertions (e.g., empty result, null return) count when absence is the AC's expectation
+  - `non_substantive`: the run produced no substantive assertion against the AC — e.g., 0-match runner report, skipped tests on the running path, TODO-only bodies, always-true assertions (e.g., `expect(true).toBe(true)`, `expect(arr.length).toBeGreaterThanOrEqual(0)`)
+- `substanceIssue`: when `substance` is `non_substantive`, name the specific cause and location (e.g., `"always-true assertion at order.test.ts:42"`, `"runner matched 0 tests for pattern *.feature.test.ts"`). Leave `null` when substantive or when test evidence is not cited.
+- Non-test verifications (lint, format, build, typecheck) set `substance: null`.
+
 ### 1. Task Completion Response
 Report in the following JSON format upon task completion (**without executing quality checks or commits**, delegating to quality assurance process):
 
@@ -263,6 +285,8 @@ Report in the following JSON format upon task completion (**without executing qu
     "executed": true,
     "command": "Executed test command",
     "result": "passed / failed / skipped",
+    "substance": "substantive | non_substantive | null (non-test verification)",
+    "substanceIssue": "null when substantive or non-test; cause and location when non_substantive",
     "reason": "Test execution reason/verification content"
   },
   "readyForQualityCheck": true,
@@ -296,6 +320,7 @@ Per-type contract (set `escalation_type`, `reason`, type-specific fields, and `s
 | `dependency_version_uncertain` | "Dependency version uncertain" | `dependency: {name, versionsFound[], filesChecked[], ambiguityReason}` | "Use majority version X" / "Use version Y with reason" / "Research latest stable" |
 | `binding_decision_violation` | "Binding decision violation" | `phase: 'pre_implementation' \| 'exit_gate'`; `plannedApproach`; `failures[{source, axis, decision, complianceCheck, evaluation: 'N' \| 'Unknown', rationale}]` | "Adjust the implementation plan to satisfy the binding decision" / "Update the ADR (then update the work plan's ADR Bindings and this task's Binding Decisions)" / "Provide additional context that resolves the Unknown evaluation" |
 | `out_of_scope_file` | "Out of scope file" | `details: {file_path, allowed_list[], modification_reason}` | "Add to Target files and retry" / "Split into separate task" / "Reconsider approach" |
+| `test_environment_not_ready` | "Test environment not ready" | `missingComponent: 'test runner' \| 'fixtures' \| 'mock server' \| 'setup file' \| 'other'`; `description` (why the missing component blocks tests) | "Install or configure the missing component, then re-run the task" / "Reassign the task once the environment is ready" |
 | `task_file_not_found` / `task_already_completed` / `target_files_missing` | "Task selection precondition failed" | `details: {task_file_path, failure_reason: 'file does not exist' \| 'file unreadable' \| 'all checkboxes already [x]' \| 'Target Files section missing or empty'}` | "Provide correct task file path" / "Re-decompose the work plan" / "Mark complete and skip" |
 
 Minimal example (out_of_scope_file):
@@ -324,6 +349,7 @@ This gate runs immediately before producing the final JSON response.
 ☐ Fix Mode: every `requiredFixes` / `incompleteImplementations` item is addressed in `changeSummary` or escalated
 ☐ Implementation is consistent with the Investigation Notes recorded at Step 2 (when Investigation Targets were present)
 ☐ Every Binding Decisions Compliance Check evaluates to `Y` against the final implementation, with evidence recorded in Investigation Notes (when the task file has a Binding Decisions section). Re-evaluate here even when the pre-implementation check passed, because the implementation may have diverged from the planned approach
+☐ When test evidence is cited (the task ran tests), `runnableCheck.substance` and `runnableCheck.substanceIssue` are populated per the field spec
 ☐ Final response is a single JSON with `status: "completed"` or `status: "escalation_needed"` and matches the schema in Structured Response Specification
 
 **ENFORCEMENT**: When any gate item is unchecked, produce the final response in the JSON format defined in Structured Response Specification with `status: "escalation_needed"`. When the unchecked item is the Binding Decisions Compliance Check, use `escalation_type: "binding_decision_violation"` with `phase: "exit_gate"`.

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

@@ -174,18 +174,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では操作前後の観測可能な状態、どの境界をなぜモックしてよいか。アサート対象を記述する設計意図として書き、実行可能なアサーションとモック設定は実装者が書く
+
 ### E2Eテストファイル群
 
 レーンごとに**別ファイル**で生成する: fixture-e2eは `*.fixture-e2e.test.[ext]`、service-integration-e2eは `*.service-e2e.test.[ext]`。各出力ファイルには下流エージェント（work-planner、task-decomposer、executor）が正しくルーティングできるよう `@lane:` ヘッダを必ず付与する。
@@ -207,6 +215,8 @@ describe('[機能名] fixture-e2e', () => {
   // @lane: fixture-e2e
   // @dependency: full-ui (mocked backend)
   // @complexity: medium
+  // 主要な故障モード: ジャーニー中のステップ遷移またはその観測可能な状態が失われる
+  // 証明義務: 各ステップの UI 遷移と結果状態を順に検証する。モックするのはバックエンドのみ（固定レスポンス）
   it.todo('ユーザージャーニー: モック決済でのカートから確認までのフロー')
 })
 ```
@@ -228,6 +238,8 @@ describe('[機能名] service-integration-e2e', () => {
   // @lane: service-integration-e2e
   // @dependency: full-system
   // @complexity: high
+  // 主要な故障モード: 実サービス間の購入後に注文行または下流イベントが存在しない
+  // 証明義務: DB行・発行イベント・キュー投入メールを実ローカルスタックに対して観測する。アサート対象の経路上は何もモックしない
   it.todo('ユーザージャーニー: 購入完了で注文が永続化され下流イベントが発行される')
 })
 ```
@@ -242,6 +254,8 @@ describe('[機能名] service-integration-e2e', () => {
 // ROI: [値] | テスト種別: property-based
 // @category: core-functionality
 // fast-check: fc.property(fc.constantFrom([入力バリエーション]), (input) => [不変条件])
+// 主要な故障モード: 生成ドメイン内のある入力が記述された不変条件に違反する
+// 証明義務: 生成された全入力で不変条件が成立する。境界はモックしない
 it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 ```
 
@@ -318,7 +332,7 @@ it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 ## 制約と品質基準
 
 **必須準拠事項**:
-- `it.todo`スケルトンのみ出力: 各スケルトン内にコメントとして検証観点、期待結果、合格基準を記述。
+- `it.todo`スケルトンのみ出力: 各スケルトン内にコメントとして検証観点、期待結果、合格基準、主要な故障モード、証明義務を記述。
   実装コード、アサーション(`expect`)、モックセットアップは含めない — 下流の処理で`it.todo`の有無によりフェーズ配置やレビュー判定が行われる。
 - 各テストの検証観点、期待結果、合格基準を明確に記述
 - コメントに元のAC文を保持（トレーサビリティ確保）

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

@@ -96,11 +96,21 @@ Step 1で抽出した各識別子仕様（リソース名、エンドポイン
 #### 3-2. エラーハンドリング
 - エラーハンドリングパターン（try/catch、エラー返却、Result型 — プロジェクト言語に適応）をGrepで検索
 - 各エントリポイント: エラーケースが処理されており、黙殺されていないことを検証
-- エラーレスポンスが内部詳細を漏洩していないことを確認
+- エラーレスポンスで内部詳細（スタックトレース、内部パス、PII）が伏せられていることを確認
 
 #### 3-3. 受入条件のテストカバレッジ
 - fulfilledと判定した各AC: Glob/Grepで対応するテストケースを検索
 - テストカバレッジのあるACとないACを記録
+- **引用された各テストの実体性検証**:
+  - 適用対象: fulfilled と判定した AC のカバレッジとして主張されている各テスト
+  - カバレッジとして数える条件: テスト本体で実行されるアサーションのうち少なくとも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）
 
 #### 検出事項の分類
 
@@ -275,16 +285,3 @@ summary.findingsByCategory.coverage_gap:    number (整数 >= 0)
 - パフォーマンス上の重大な問題を発見した場合
 - 実装が Design Doc の Minimal Surface Alternatives セクションに記載のない適用対象要素を導入している場合。適用対象集合はコンテキストごとに異なる: バックエンドでは永続状態、公開コントラクト要素（公開型、APIフィールド、関数シグネチャ、スキーマ定義）、モジュール/サービス境界を越えるフィールド、振る舞いモード/フラグ、再利用可能な抽象、フロントエンドでは永続化されるクライアント/サーバー状態、エクスポートされた再利用可能コンポーネントの公開 API Props、Context 値、所有境界を越えて持ち上げられた状態、観測可能な振る舞いを変える振る舞いモード/バリアント、再利用可能なコンポーネント分割（複数の親で利用するためのサブコンポーネント、カスタムフック、ユーティリティ）。1つの所有境界内に留まる通常の親→子の Props 伝達や、コンポーネントローカルの状態は適用対象外。
 
-## 特別な考慮事項
-
-### プロトタイプ/MVP の場合
-- 完全性より動作を優先的に評価
-- 将来の拡張性を考慮
-
-### リファクタリングの場合
-- 既存機能の維持を最重要視
-- 改善度を定量的に評価
-
-### 緊急修正の場合
-- 最小限の実装で問題解決しているか
-- 技術的負債の記録があるか

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

@@ -63,6 +63,7 @@ skills: integration-e2e-testing, typescript-testing, project-context
 | 独立性 | テストごとに状態を分離（beforeEachでリセット） | テスト間で共有状態を変更 |
 | 再現性 | 決定論的な実行（必要に応じて時間/乱数をモック） | 非決定的要素あり |
 | 可読性 | テスト名と検証内容の一致 | 名前と内容が乖離 |
+| 実体的なアサーション | 実行されたアサーションのうち少なくとも1つが、AC の観測可能な振る舞いを検証する。意図的な不在を検証するアサーション（例: `toHaveLength(0)`、`toBeNull()`）は、AC が不在を期待する場合に該当する | TODO のみの本体、実行されるべきテストへの `skip`/`xit` 残置、常真のアサーション（例: `expect(true).toBe(true)`、`expect(arr.length).toBeGreaterThanOrEqual(0)`） |
 
 ### 4. モック境界チェック（統合テストのみ）
 
@@ -72,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 を用い、共有状態・実データ量・実行順序によらず成立する結果をアサートする。
+
 ## 出力フォーマット
 
 ### 出力プロトコル
@@ -115,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": "[具体的な修正提案]"
@@ -197,8 +207,14 @@ needs_revision判定時、後続処理で使用できる修正指示を出力:
 - 全コンポーネント実装完了後に実行されているか確認
 - クリティカルユーザージャーニーの網羅性を検証
 
+### 空虚またはプレースホルダーのアサーション
+
+**問題**: テストはパスしているように見えるが、AC の観測可能な振る舞いを検証していない — 常真のアサーション、TODO のみの本体、実行されるべきテストへの `skip`/`xit` 残置のいずれか。
+**修正**: AC の観測可能な振る舞いを検証するアサーションへ置き換える。実行すべきテストの場合は `skip`/`xit` を外す。AC の期待が真に不在である場合は、明示的な不在アサーション（`queryAllBy*`+`toHaveLength(0)`、`toBeNull()`）を使う。
+
 ## 完了条件
 
 - [ ] すべてのスケルトンコメントを実装と照合
 - [ ] 実装品質を評価
+- [ ] 各テストがACの主張を証明している: 主要な故障モードでレッドになり、主張された境界を通過し、状態変更を伴う主張では操作前後の状態をアサートする
 - [ ] Mock境界を検証（統合テスト）