create-ai-project 1.24.1 → 1.24.2

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

@@ -127,8 +127,10 @@ For each function/method in implementation files, check against coding-standards
 - **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
+  - Task Proof Obligations in scope: when the task file is available, apply this proof check to each of its Proof Obligations — including any derived from a Failure Mode Checklist category rather than an AC — using that obligation's own primary failure mode and boundary
+  - When `taskFiles` are absent: AC-less obligations (Failure Mode Checklist categories) cannot be discovered from the Design Doc or AC tests, so do not treat task Proof Obligations as fully verified — record a `coverage_gap` noting task Proof Obligations were not checked (limited review), unless the caller states there are no task Proof Obligations
   - 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)
+  - Action when unproven: a test that passes yet would stay green if the claimed behavior or mapped failure-mode condition regressed → record as `coverage_gap` with rationale naming the unproven failure mode (file:line)
 
 #### Finding Classification
 
@@ -139,7 +141,7 @@ Classify each quality finding into one of:
 | **dd_violation** | Implementation contradicts or deviates from Design Doc specification | Wrong identifier, missing specified behavior, incorrect data flow |
 | **maintainability** | Code structure impedes future changes or comprehension | Long functions, deep nesting, multiple responsibilities, unclear naming |
 | **reliability** | Missing safeguards that could cause runtime failures | Unhandled error paths, missing validation at boundaries, silent failures |
-| **coverage_gap** | Acceptance criteria lack corresponding test verification | AC fulfilled in code but no test exercises it |
+| **coverage_gap** | Acceptance criteria or task Proof Obligations lack corresponding test verification | AC or Proof Obligation fulfilled in code but no test exercises it |
 | **adjacent_residual** | A case sharing the change's path, contract, persisted state, or external boundary still carries the class of defect the change addressed | Fallback path left unfixed, sibling state transition still stale, another consumer of a changed contract not updated |
 
 Each finding must include a `rationale` field:
@@ -149,7 +151,7 @@ Each finding must include a `rationale` field:
 | **dd_violation** | What the Design Doc specifies vs what the code does, with exact references |
 | **maintainability** | What specific maintenance or comprehension risk this creates |
 | **reliability** | What failure scenario is unguarded and under what conditions it could occur |
-| **coverage_gap** | Which AC is untested and why test coverage matters for this specific case |
+| **coverage_gap** | Which AC or Proof Obligation is untested and why test coverage matters for this specific case |
 | **adjacent_residual** | Which adjacent case shares the path/contract/state/boundary and how it still exhibits the defect class |
 
 ### 4. Check Architecture Compliance
@@ -265,6 +267,7 @@ Identifier mismatches automatically lower the verdict by one level (e.g., pass
 - [ ] All acceptance criteria individually evaluated with confidence levels
 - [ ] All identifier specifications verified against implementation code
 - [ ] Quality findings classified with category and rationale
+- [ ] Task Proof Obligations verified when `taskFiles` provided; when absent and not confirmed empty by the caller, recorded as a `coverage_gap` / limited review rather than reported complete
 - [ ] Compliance rate and identifier match rate calculated
 - [ ] Verdict determined
 

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

@@ -130,7 +130,7 @@ For WorkPlan, additionally verify:
   - (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`)
+  - (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-sort-key ordering) — missing applicable category → `recommended` issue (category: `completeness`)
   - (6) Binding observable values are carried with content fidelity, not only coverage: for each Design Doc observable contract that encodes a binding value (a column/label set and order, a derived-display rule, or a state-lifecycle negative), the plan's Reference Contract Values table carries the value verbatim from the Design Doc and maps it to a covering task. Re-derive each such value from the Design Doc and compare against the plan; a value reduced to a label, summarized, or absent while the Design Doc specifies it is a content-fidelity gap → `critical` 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`
 

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

@@ -19,6 +19,7 @@ You are an AI assistant specialized in verifying integration/E2E test implementa
 
 - **testFile**: Path to the test file to review (required)
 - **designDocPath**: Path to related Design Doc (optional)
+- **taskFiles**: Path(s) to the task file(s) the tests cover (`docs/plans/tasks/…`) (optional). Source of each task's Proof Obligations, including obligations derived from a Failure Mode Checklist category that carry no AC and so appear in no skeleton annotation
 
 ## Main Responsibilities
 
@@ -75,10 +76,10 @@ Verify the following for each test case:
 
 ### 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.
+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. When `taskFiles` are provided, also read each task's Proof Obligations and merge them in: the skeleton annotation is authoritative where it covers an obligation, and any task Proof Obligation with no matching skeleton annotation — such as a Failure Mode Checklist category that carries no AC — is added to the obligations under review. When `taskFiles` are absent you cannot discover AC-less obligations from the test file alone, so do not report full proof adequacy: cap the proof-adequacy result at `needs_improvement` and record that task Proof Obligations were not verified, unless the caller states the reviewed tests carry no task Proof Obligations. Confirm each test proves its claim or task Proof Obligation: 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, including a merged task Proof Obligation that no test covers:
+- The test turns red under the recorded primary failure mode (an assertion observes the specific promised behavior or failure-mode condition, so a regression in it fails the test).
+- When the AC or task Proof Obligation claims a public or integration boundary, the test exercises that boundary directly.
+- When the AC or task Proof Obligation 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.
 
@@ -185,5 +186,6 @@ 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
+- [ ] Each test proves its AC's claim or task Proof Obligation: turns red under the primary failure mode, exercises the claimed boundary, and asserts before/after state for state-changing claims
+- [ ] Task Proof Obligations checked when `taskFiles` provided; when absent and not confirmed empty by the caller, proof adequacy reported as `needs_improvement` rather than passed
 - [ ] Mock boundaries verified (integration tests)

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

@@ -159,9 +159,18 @@ When the work plan includes a Verification Strategy, derive each task's Operatio
 
 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.
+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). A Failure Mode Checklist category mapped to this task is a further source — see Failure Mode Propagation below.
+2. **Per claim**: Record one entry per AC, claim, or mapped Failure Mode category, populating all Proof Obligations fields defined in the task template.
+3. **Apply when claims exist**: Tasks with neither a behavioral claim nor a mapped Failure Mode Checklist category (e.g., pure config or scaffolding) omit the section.
+
+## Failure Mode Propagation
+
+When the work plan contains a Failure Mode Checklist, propagate each applicable category to the task(s) it maps to, so the failure mode reaches the executor as a provable obligation rather than a plan-only declaration:
+
+1. **Lookup by task ID**: For each Checklist row marked `Applies? = yes`, locate the task(s) listed in the "Covered By Task(s)" column.
+2. **Add a Proof Obligation per category**: Ensure each matched task carries a Proof Obligation whose `Primary failure mode` is that category, instantiated for the task's target (e.g., `missing-sort-key ordering` → "rows lacking the sort key are misplaced or reorder nondeterministically in this task's listing"). Populate the remaining Proof Obligations fields from the AC and target files per Proof Obligation Propagation above. When no AC covers the category, set `Claim` to the failure-mode condition the task must prevent and `State assertion` to `N/A` unless the task changes state.
+3. **Merge into the existing entry**: When an AC-derived Proof Obligation already covers the same failure mode for that task, keep the single entry rather than adding a parallel one.
+4. **Apply only when provided**: Run this propagation only when the work plan contains a Failure Mode Checklist with applicable categories.
 
 ## UI Spec Propagation
 
@@ -390,6 +399,7 @@ Please execute decomposed tasks according to the order.
 - [ ] Proof Obligations recorded for each claim-implementing task (primary failure mode + boundary to exercise)
 - [ ] Change Category set for bug-fix / regression / state-change / boundary-change tasks, with adjacent path/boundary owners added to Investigation Targets
 - [ ] Reference Contract Values rows propagated to matching tasks as Reference Contracts, value copied verbatim (when work plan has the table)
+- [ ] Failure Mode Checklist applicable categories propagated to covering tasks as Proof Obligations (when work plan has the table)
 - [ ] Quality Assurance Mechanisms from work plan header propagated to relevant tasks
 
 ## Task Design Principles

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

@@ -349,7 +349,8 @@ Draft each AC value-first, then expand it across requirement boundaries before a
 
 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.
+3. **Expand mode × branch combinations**: when the change adds a mode, toggle, or variant that overlays an existing branch (sort, filter, view, or display), expand the combination of the new value with each existing branch value — a mode can take effect on one branch while silently no-opping on the others.
+4. **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)
 

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

@@ -345,7 +345,8 @@ Draft each AC value-first, then expand it across requirement boundaries before a
 
 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.
+3. **Expand mode × branch combinations**: when the change adds a mode, flag, or variant that overlays an existing branch axis (selection, ordering, filtering, or display), expand the combination of the new value with each existing axis value — a mode can take effect on one branch while silently no-opping on the others.
+4. **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
 

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

@@ -38,9 +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
+- **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, plus any applicable Failure Mode Checklist categories mapped to tasks) and state that every task that implements a claim or covers an applicable Failure Mode Checklist category 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 a Failure Mode Checklist in the work plan** (see plan template) — enumerate all nine domain-independent failure categories (same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility, missing-sort-key ordering), 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
@@ -98,7 +98,7 @@ Map each extracted item to a covering task. Items may be covered by a dedicated
 
 If an item has no covering task, set Gap Status to `gap` with justification in Notes. **When the Traceability table contains any `gap` entry, the plan is in draft status.** Output the plan as draft, but do not finalize it until the user has confirmed each justified gap. Unjustified gaps (no Notes) are errors — add a covering task or provide justification before proceeding.
 
-**Carry binding observable values verbatim.** Identify binding observable values from the Design Doc directly, not from the Traceability table's summarized DD Item, so the exact column/label order and derived-display rules are not lost to a summary. A binding observable value is a column/label set and order (Contract Type `structure-order`), a derived-display rule — a display value derived from another field — (`derived-display`), or a state-lifecycle negative — a condition under which the state must stay unused — (`state-lifecycle-negative`). Copy each value **verbatim from the Design Doc** into the plan's **Reference Contract Values** table (see plan template), one row per value with its Contract Type token, mapped to the covering task(s). Preserve the full value, so the covering task is later checked against this exact value rather than a re-derived summary. This table covers DD-derived observable contracts only; serialized boundaries go in the Connection Map (step 5b) and ADR-derived structural decisions in the ADR Bindings table.
+**Carry binding observable values verbatim.** Identify binding observable values from the Design Doc directly, not from the Traceability table's summarized DD Item, so the exact column/label order and derived-display rules are not lost to a summary. A binding observable value is a column/label set and order (Contract Type `structure-order`), a derived-display rule — a display value derived from another field — (`derived-display`), or a state-lifecycle negative — a condition under which the state must stay unused — (`state-lifecycle-negative`). Copy each value **verbatim from the Design Doc** into the plan's **Reference Contract Values** table (see plan template), one row per value with its Contract Type token, mapped to the covering task(s). Preserve the full value, so the covering task is later checked against this exact value rather than a re-derived summary. When the Design Doc introduces client/session/UI state with a reset or clear operation, the condition that the state returns to its unused/default value on that reset is itself a `state-lifecycle-negative` — record it as a row even when no other binding value applies. This table covers DD-derived observable contracts only; serialized boundaries go in the Connection Map (step 5b) and ADR-derived structural decisions in the ADR Bindings table.
 
 ### 5a. Map UI Spec Components to Tasks (when UI Spec provided)
 

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

@@ -127,8 +127,10 @@ ACループとは独立に実行するため、ACに紐づかない観測可能
 - **引用された各テストの証明検証（実体性を超えて）**:
   - 適用対象: fulfilled と判定した AC の実体的なカバレッジとして数えられるテスト
   - 主要な故障モードの出所: 主張に記録された Proof Obligation（タスクファイル）またはテストスケルトンの注釈を参照する。いずれも存在しない場合のみ AC から導出し、判定がテスト作成者の狙いと一致するようにする
+  - スコープ内のタスク Proof Obligations: タスクファイルが利用可能な場合、その各 Proof Obligation（ACではなく故障モードチェックリストのカテゴリ由来のものを含む）に、その義務固有の主要な故障モードと境界を用いてこの証明検証を適用する
+  - `taskFiles` がない場合: ACを持たない義務（故障モードチェックリストのカテゴリ）は Design Doc やACテストからは発見できないため、タスクの Proof Obligations を完全に検証済みとは扱わない — タスクの Proof Obligations を未確認である旨（限定的レビュー）を記して `coverage_gap` として記録する。ただし、タスクの Proof Obligations が存在しないと呼び出し側が明示した場合を除く
   - 証明として数える条件: テストがその主要な故障モードでレッドになり、主張された境界を直接通過する
-  - 未証明の場合のアクション: テストはパスするのに、主張された振る舞いがリグレッションしてもグリーンのまま → `coverage_gap` として記録し、rationale に未証明の故障モードを明記（file:line）
+  - 未証明の場合のアクション: テストはパスするのに、主張された振る舞いまたはマッピングされた故障モード条件がリグレッションしてもグリーンのまま → `coverage_gap` として記録し、rationale に未証明の故障モードを明記（file:line）
 
 #### 検出事項の分類
 
@@ -139,7 +141,7 @@ ACループとは独立に実行するため、ACに紐づかない観測可能
 | **dd_violation** | 実装がDesign Doc仕様と矛盾または逸脱 | 識別子の不一致、指定された振る舞いの欠落、データフローの誤り |
 | **maintainability** | コード構造が将来の変更や理解を妨げる | 長い関数、深いネスト、複数の責務、不明瞭な命名 |
 | **reliability** | 実行時障害を引き起こし得る安全策の欠如 | 未処理のエラーパス、境界での検証漏れ、黙殺されるエラー |
-| **coverage_gap** | 受入条件に対応するテスト検証が存在しない | コードでは充足されているがテストで検証されていないAC |
+| **coverage_gap** | 受入条件またはタスクの Proof Obligations に対応するテスト検証が存在しない | コードでは充足されているがテストで検証されていないACまたは Proof Obligation |
 | **adjacent_residual** | 変更の経路・契約・永続状態・外部境界を共有するケースが、変更が対処した欠陥と同一クラスの欠陥を依然として抱えている | フォールバックパスが未修正、兄弟の状態遷移が依然 stale、変更された契約の別の利用者が未更新 |
 
 各検出事項に`rationale`フィールドを含めること:
@@ -149,7 +151,7 @@ ACループとは独立に実行するため、ACに紐づかない観測可能
 | **dd_violation** | Design Docの仕様とコードの実装の差異を正確な参照とともに |
 | **maintainability** | どのような保守・理解上のリスクが生じるか |
 | **reliability** | どのような障害シナリオが保護されておらず、どの条件で発生し得るか |
-| **coverage_gap** | どのACがテストされておらず、なぜこのケースでテストカバレッジが重要か |
+| **coverage_gap** | どのACまたは Proof Obligation がテストされておらず、なぜこのケースでテストカバレッジが重要か |
 | **adjacent_residual** | どの隣接ケースが経路/契約/状態/境界を共有し、どのように欠陥クラスを依然として示しているか |
 
 ### 4. アーキテクチャ準拠の確認
@@ -265,6 +267,7 @@ summary.findingsByCategory.adjacent_residual: number (整数 >= 0)
 - [ ] すべてのACを信頼度付きで個別に評価
 - [ ] すべての識別子仕様を実装コードに対して検証
 - [ ] 品質検出事項をカテゴリとrationaleで分類
+- [ ] `taskFiles` が提供された場合はタスクの Proof Obligations を検証済み。ない場合で呼び出し側が空と確認していないときは、完全としてではなく `coverage_gap` / 限定的レビューとして記録
 - [ ] 準拠率と識別子一致率を算出
 - [ ] verdictを判定
 

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

@@ -130,7 +130,7 @@ WorkPlanの場合、追加で以下を確認:
   - (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`）
+  - (5) 故障モードチェックリストが計画の該当するドメイン非依存カテゴリ（same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility, missing-sort-key ordering）をカバーしている — 該当カテゴリの欠落 → `recommended`（カテゴリ: `completeness`）
   - (6) 拘束的観測値がカバレッジだけでなく内容忠実性をもって保持されている: 拘束的値をエンコードする各Design Doc観測可能契約（列/ラベルの集合と順序、派生表示ルール、状態ライフサイクルの否定条件）について、計画のReference Contract Values表がその値をDesign Docから逐語で転記し、カバーするタスクにマッピングしている。各値をDesign Docから再導出して計画と比較する; Design Docが指定しているのに値がラベルに縮約・要約・欠落している場合は内容忠実性のギャップ → `critical`（カテゴリ: `completeness`）
   - Verdictマッピング（WorkPlan）: セマンティックゲートの`critical`はいずれもverdictを最低でも`needs_revision`にする — ただしDesign Doc/入力要素の欠落や矛盾に起因するカバレッジギャップ（再計画で修正不能）→ `rejected`、`important`のみの場合はverdictを`approved_with_conditions`までに制限する
 

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

@@ -19,6 +19,7 @@ skills: integration-e2e-testing, typescript-testing, project-context
 
 - **testFile**: レビュー対象のテストファイルパス（必須）
 - **designDocPath**: 関連するDesign Docのパス（オプション）
+- **taskFiles**: テストがカバーするタスクファイルのパス（`docs/plans/tasks/…`）（オプション）。各タスクの Proof Obligations の取得元。ACを持たず（したがってスケルトン注釈に現れない）故障モードチェックリストのカテゴリ由来の義務を含む
 
 ## 主な責務
 
@@ -75,10 +76,10 @@ skills: integration-e2e-testing, typescript-testing, project-context
 
 ### 5. 主張証明の妥当性
 
-各ACの主要な故障モードと証明義務は、テストのスケルトン注釈（「主要な故障モード」/「証明義務」コメント）を出所とする — これらは task template の Proof Obligations フィールドに対応する。各テストが主張を証明していることを確認する: アサーションが約束された振る舞いを観測し、その振る舞いがリグレッションするとテストが失敗する。テストが未証明のまま残す各義務について `proof_insufficient` を記録する:
-- テストが記録された主要な故障モードでレッドになる（アサーションがACの約束する具体的な振る舞いを観測するため、その振る舞いのリグレッションでテストが失敗する）。
-- ACが公開境界または統合境界を主張する場合、テストはその境界を直接通過する。
-- ACが状態変更・副作用・ロールバック・非変更モード・冪等性・永続化を主張する場合、テストは操作前の観測可能な状態、操作、操作後の観測可能な状態をアサートする。
+各ACの主要な故障モードと証明義務は、テストのスケルトン注釈（「主要な故障モード」/「証明義務」コメント）を出所とする — これらは task template の Proof Obligations フィールドに対応し、そのフィールドにはACではなく故障モードチェックリストのカテゴリ由来の義務も含まれうる。`taskFiles` が与えられた場合、各タスクの Proof Obligations も読み込んでマージする: スケルトン注釈は、それがカバーする義務については権威を持ち、対応するスケルトン注釈を持たないタスクの Proof Obligation — 例えばACを持たない故障モードチェックリストのカテゴリ — はレビュー対象の義務に加える。`taskFiles` がない場合、ACを持たない義務をテストファイルだけからは発見できないため、証明妥当性を完全には報告しない: 証明妥当性の結果を `needs_improvement` で頭打ちにし、タスクの Proof Obligations を未検証である旨を記録する。ただし、レビュー対象のテストにタスクの Proof Obligations が存在しないと呼び出し側が明示した場合を除く。各テストが主張またはタスクの Proof Obligation を証明していることを確認する: アサーションが約束された振る舞いを観測し、その振る舞いがリグレッションするとテストが失敗する。テストが未証明のまま残す各義務（どのテストもカバーしないマージされたタスクの Proof Obligation を含む）について `proof_insufficient` を記録する:
+- テストが記録された主要な故障モードでレッドになる（アサーションが約束された具体的な振る舞いまたは故障モード条件を観測するため、そのリグレッションでテストが失敗する）。
+- ACまたはタスクの Proof Obligation が公開境界または統合境界を主張する場合、テストはその境界を直接通過する。
+- ACまたはタスクの Proof Obligation が状態変更・副作用・ロールバック・非変更モード・冪等性・永続化を主張する場合、テストは操作前の観測可能な状態、操作、操作後の観測可能な状態をアサートする。
 - モックする各境界は外部依存であり、テスト対象の境界は実物のまま残し、その境界をモックしてよい理由をコメントで記録する。
 - 統合テストとE2Eテストは範囲を限定した fixture を用い、共有状態・実データ量・実行順序によらず成立する結果をアサートする。
 
@@ -185,5 +186,6 @@ needs_revision判定時、後続処理で使用できる修正指示を出力:
 
 - [ ] すべてのスケルトンコメントを実装と照合
 - [ ] 実装品質を評価
-- [ ] 各テストがACの主張を証明している: 主要な故障モードでレッドになり、主張された境界を通過し、状態変更を伴う主張では操作前後の状態をアサートする
+- [ ] 各テストがACの主張またはタスクの Proof Obligation を証明している: 主要な故障モードでレッドになり、主張された境界を通過し、状態変更を伴う主張では操作前後の状態をアサートする
+- [ ] `taskFiles` が提供された場合はタスクの Proof Obligations を確認済み。ない場合で呼び出し側が空と確認していないときは、証明妥当性を passed ではなく `needs_improvement` として報告
 - [ ] Mock境界を検証（統合テスト）

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

@@ -159,9 +159,18 @@ implementation-approachスキルで決定された実装戦略パターンに基
 
 主張を実装する各タスクは Proof Obligations（task template参照）を持ち、下流のレビューがテストが主張を証明しているか（単に実行されるだけでないか）を判定できるようにする:
 
-1. **出所**: テストスケルトンがタスクをカバーしている場合、その「主要な故障モード」と「証明義務」の注釈をタスクの Proof Obligations に転記する。スケルトンが主張をカバーしていない場合、主要な故障モードをACから導出し、境界・操作前後の状態アサーション・モック境界の根拠・残余をACとタスクの対象ファイルから導出する（その主張に該当しないフィールドは `N/A` とする — 例: 状態を変更しない主張では状態アサーションなし）。
-2. **主張ごと**: ACまたは主張ごとに1エントリを記録し、task template で定義された Proof Obligations の全フィールドを埋める。
-3. **主張がある場合に適用**: 振る舞いの主張を持たないタスク（純粋な設定やスキャフォールディング等）は本セクションを省略する。
+1. **出所**: テストスケルトンがタスクをカバーしている場合、その「主要な故障モード」と「証明義務」の注釈をタスクの Proof Obligations に転記する。スケルトンが主張をカバーしていない場合、主要な故障モードをACから導出し、境界・操作前後の状態アサーション・モック境界の根拠・残余をACとタスクの対象ファイルから導出する（その主張に該当しないフィールドは `N/A` とする — 例: 状態を変更しない主張では状態アサーションなし）。このタスクにマッピングされた故障モードチェックリストのカテゴリも出所の一つである — 後述の「故障モード伝播」参照。
+2. **主張ごと**: AC・主張・マッピングされた故障モードカテゴリごとに1エントリを記録し、task template で定義された Proof Obligations の全フィールドを埋める。
+3. **主張がある場合に適用**: 振る舞いの主張も、マッピングされた故障モードチェックリストのカテゴリも持たないタスク（純粋な設定やスキャフォールディング等）は本セクションを省略する。
+
+## 故障モード伝播
+
+作業計画書に故障モードチェックリストが含まれる場合、該当する各カテゴリを、それがマッピングされるタスクに伝播する。これにより、故障モードは計画上の宣言にとどまらず、証明可能な義務として executor に届く:
+
+1. **タスクIDで照合**: 「該当?」列が yes と記された各チェックリスト行について、「カバーするタスク」列に記載されたタスクを特定する。
+2. **カテゴリごとに Proof Obligation を追加**: マッチした各タスクに、その `主要な故障モード` をそのカテゴリとする Proof Obligation を持たせ、タスクの対象に即して具体化する（例: `missing-sort-key ordering` → 「このタスクのリストで、ソートキーを持たない行が誤配置されるか非決定的に並び替わる」）。残りの Proof Obligations フィールドは上記「証明義務の伝播」に従いACと対象ファイルから埋める。そのカテゴリをカバーするACがない場合、`主張` をそのタスクが防ぐべき故障モード条件とし、`状態アサーション` はタスクが状態を変更しない限り `N/A` とする。
+3. **既存エントリへの統合**: AC由来の Proof Obligation が既にそのタスクの同じ故障モードをカバーしている場合、並行して追加せず単一エントリのまま保つ。
+4. **提供時のみ適用**: この伝播は、該当するカテゴリを持つ故障モードチェックリストが作業計画書に含まれる場合のみ実行する。
 
 ## UI Spec伝播
 
@@ -390,6 +399,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 - [ ] 主張を実装する各タスクに Proof Obligations を記録（主要な故障モード + 検証する境界）
 - [ ] bug-fix / regression / state-change / boundary-change のタスクに Change Category を設定し、隣接する経路/境界のオーナーを Investigation Targets に追加済み
 - [ ] Reference Contract Values行を該当タスクにReference Contractsとして伝播し、値を逐語コピー済み（作業計画書に表がある場合）
+- [ ] 故障モードチェックリストの該当カテゴリを、カバーするタスクに Proof Obligations として伝播済み（作業計画書に表がある場合）
 - [ ] 作業計画書ヘッダーの品質保証メカニズムを該当タスクに伝播済み
 
 ## タスク設計の原則

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

@@ -349,7 +349,8 @@ UI Specが存在する場合（`docs/ui-spec/{feature-name}-ui-spec.md`）:
 
 1. **価値起点**: まずユーザーにとっての価値を挙げ、次にそれを実現する観察可能なUIの振る舞い、最後にそれを支える技術的境界を特定する。
 2. **境界への展開**（候補抽出 — 採否は下記のスコーピングルールが決定）: ある振る舞いはハッピーパスでは成立しつつ、別の状態で退行しうる。振る舞いを変えるACごとに、約束した振る舞いが成立すべき箇所すべてでACを検討する — 単一/最新/全件のリスト描画、隣接する Props やフィールド、ローディング/空/エラーおよび後続のインタラクション状態、stale または欠損データ、フェッチ失敗やフォールバックUI、権限/バリデーションのゲーティング、入力スコープと順序/選択、副作用、可視性やルートの境界（状態が別画面・別コンポーネント・ナビゲーション後に観察可能になる箇所）。
-3. **同一粒度での比較**: ACが既存または参照先の振る舞いに関わる場合、参照元（source）の振る舞いと対象（target）の振る舞いを同じ詳細度で記述し、各境界が保持されているか意図的に変更されたかをレビュアーが確認できるようにする。
+3. **mode × branch の組み合わせを展開**: 変更が既存の分岐（ソート・フィルタ・ビュー・表示）に重なる mode・トグル・バリアントを追加する場合、新しい値と各既存分岐の値との組み合わせを展開する — mode はある分岐では効きつつ、他の分岐では黙って no-op しうる。
+4. **同一粒度での比較**: ACが既存または参照先の振る舞いに関わる場合、参照元（source）の振る舞いと対象（target）の振る舞いを同じ詳細度で記述し、各境界が保持されているか意図的に変更されたかをレビュアーが確認できるようにする。
 
 ### 自律実装のためのACスコーピング（フロントエンド）
 

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

@@ -345,7 +345,8 @@ Design Doc作成時に必ず含める:
 
 1. **価値起点**: まずユーザー/オペレーター/保守者にとっての価値を挙げ、次にそれを実現する観測可能な振る舞い、最後にそれを支える技術的境界を特定する。
 2. **境界への展開**（候補抽出 — 採否は下記ルールが決定）: ある振る舞いはメインパスでは成立しつつ、別の次元で退行しうる。振る舞いを変えるACごとに、約束した振る舞いが成立すべき箇所すべてでACを検討する — 単一/最新/全件のコレクション、同一サーフェス上の隣接フィールド、後続のライフサイクル状態やリトライ、stale/欠損/空の値、リフレッシュ失敗やフォールバック不在、権限/バリデーション/ポリシーの境界、入力スコープと選択/順序/識別キー、副作用、公開・可視性の境界（状態が別プロセス・コンポーネント・ユーザー・後続ステップから観測可能になる箇所）。
-3. **同一粒度での比較**: ACが既存または参照先の振る舞いに関わる場合、参照元（source）の振る舞いと対象（target）の振る舞いを同じ詳細度で記述し、各境界が保持されているか意図的に変更されたかをレビュアーが確認できるようにする。
+3. **mode × branch の組み合わせを展開**: 変更が既存の分岐軸（選択・順序・フィルタリング・表示）に重なる mode・フラグ・バリアントを追加する場合、新しい値と各既存軸の値との組み合わせを展開する — mode はある分岐では効きつつ、他の分岐では黙って no-op しうる。
+4. **同一粒度での比較**: ACが既存または参照先の振る舞いに関わる場合、参照元（source）の振る舞いと対象（target）の振る舞いを同じ詳細度で記述し、各境界が保持されているか意図的に変更されたかをレビュアーが確認できるようにする。
 
 ### 測定可能なACの書き方
 

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

@@ -38,9 +38,9 @@ Design Doc、UI Spec、PRD、ADR（提供されている場合）を読み込み
 **全アプローチ共通**:
 - **検証戦略の要約を作業計画書ヘッダーに記載**（後続タスクへの参照用）
 - **採用した品質保証メカニズムを作業計画書ヘッダーに記載**（後続タスクへの参照用） — 各メカニズムについてツール名、検証内容、設定パス、カバー範囲（Design Docのファイルパスまたはディレクトリプレフィックス、スコープが限定されない場合は "project-wide"）を記載
-- **証明戦略を作業計画書ヘッダーに記載**（plan template参照） — 証明義務の出所（スケルトンが提供される場合はテストスケルトンの注釈、なければ各ACの主要な故障モード）を明示し、振る舞いの主張を持つ各タスクが、下流のレビュー用に Proof Obligations を記録する旨を記載する
+- **証明戦略を作業計画書ヘッダーに記載**（plan template参照） — 証明義務の出所（スケルトンが提供される場合はテストスケルトンの注釈、なければ各ACの主要な故障モード、加えてタスクにマッピングされた該当する故障モードチェックリストのカテゴリ）を明示し、主張を実装する、または該当する故障モードチェックリストのカテゴリをカバーする各タスクが、下流のレビュー用に Proof Obligations を記録する旨を記載する
 - **レビュースコープを作業計画書ヘッダーに記録** — 実装前の新規計画では Design Doc とタスク対象ファイルから導出した変更予定ファイルの範囲、既存作業に対する改訂計画ではベースブランチと diff範囲を記録し、作業計画書レビューと下流検証が同一スコープを共有できるようにする
-- **故障モードチェックリストを作業計画書に含める**（plan template参照） — ドメイン非依存の8つの故障カテゴリ（same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility）をすべて列挙し、該当するものに印を付け、該当する各カテゴリをカバーするタスクにマッピングする。エントリにはプロジェクト固有の名称を含めない
+- **故障モードチェックリストを作業計画書に含める**（plan template参照） — ドメイン非依存の9つの故障カテゴリ（same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility, missing-sort-key ordering）をすべて列挙し、該当するものに印を付け、該当する各カテゴリをカバーするタスクにマッピングする。エントリにはプロジェクト固有の名称を含めない
 - 検証戦略の実行タイミングに対応するフェーズに検証タスクを配置
 - テストスケルトンが提供されている場合、統合テスト実装を対応するフェーズに配置し、E2Eテスト実行を最終フェーズに配置
 - テストスケルトンが提供されていない場合、Design DocのACに基づくテスト実装タスクを含める
@@ -92,7 +92,7 @@ service-integration-e2e gap:
 
 カバーするタスクがない項目はギャップステータスを`gap`とし、備考に理由を記載する。**トレーサビリティ表に`gap`が1件でも含まれる場合、計画書はドラフト状態とする。** ドラフトとして出力するが、ユーザーが各ギャップを確認するまで確定しない。理由なしのギャップ（備考が空）はエラーとして扱い、カバーするタスクを追加するか理由を記載してから進める。
 
-**拘束的観測値は逐語のまま転記する。** 拘束的観測値とは、列/ラベルの集合と順序（Contract Type は `structure-order`）、派生表示ルール（別フィールドから導出される表示値である `derived-display`）、または状態ライフサイクルの否定条件（状態が未使用のままでなければならない条件である `state-lifecycle-negative`）を指す。要約を経由すると正確な列/ラベルの順序や派生表示ルールが失われるため、これらは設計-計画トレーサビリティ表の要約されたDD項目からではなく、Design Docから直接特定する。各値はDesign Docから逐語でコピーして計画書の**Reference Contract Values**表（plan template参照）に記録し、値ごとに1行を、そのContract Typeトークンとともにカバーするタスクにマッピングする。値は全文を保持する。これにより、後続のタスクは要約を再構成するのではなく、この正確な値そのものと突き合わせて検証できる。本表が扱うのはDD由来の観測可能契約のみである。シリアライズ境界はConnection Map（ステップ5b）が、ADR由来の構造的決定はADR Bindings表が扱う。
+**拘束的観測値は逐語のまま転記する。** 拘束的観測値とは、列/ラベルの集合と順序（Contract Type は `structure-order`）、派生表示ルール（別フィールドから導出される表示値である `derived-display`）、または状態ライフサイクルの否定条件（状態が未使用のままでなければならない条件である `state-lifecycle-negative`）を指す。要約を経由すると正確な列/ラベルの順序や派生表示ルールが失われるため、これらは設計-計画トレーサビリティ表の要約されたDD項目からではなく、Design Docから直接特定する。各値はDesign Docから逐語でコピーして計画書の**Reference Contract Values**表（plan template参照）に記録し、値ごとに1行を、そのContract Typeトークンとともにカバーするタスクにマッピングする。値は全文を保持する。これにより、後続のタスクは要約を再構成するのではなく、この正確な値そのものと突き合わせて検証できる。Design Docがリセットまたはクリア操作を持つクライアント/セッション/UI状態を導入する場合、そのリセットで状態が未使用/デフォルト値に戻る条件はそれ自体が `state-lifecycle-negative` であり、他に拘束的観測値がなくても1行として記録する。本表が扱うのはDD由来の観測可能契約のみである。シリアライズ境界はConnection Map（ステップ5b）が、ADR由来の構造的決定はADR Bindings表が扱う。
 
 ### 5a. UI Specコンポーネントのタスクへのマッピング（UI Spec提供時）
 

package/.claude/skills-en/documentation-criteria/references/design-template.md

@@ -281,11 +281,13 @@ A boundary here includes a **serialized boundary** — a value encoded on one si
 
 ### Client State Design (when feature includes frontend)
 
-| State Category | State | Management Method | Sync Strategy |
-|---------------|-------|-------------------|---------------|
-| Server state | [Fetched data] | [Cache library / custom hook] | [Polling / WebSocket / manual refresh] |
-| Local UI state | [Modal open, tab selection] | [useState / useReducer] | - |
-| Temporary state | [Form input, draft] | [useState / form library] | [Auto-save / manual save] |
+| State Category | State | Management Method | Sync Strategy | Reset/Clear Behavior |
+|---------------|-------|-------------------|---------------|----------------------|
+| Server state | [Fetched data] | [Cache library / custom hook] | [Polling / WebSocket / manual refresh] | [Cleared on clear-all / preserved] |
+| Local UI state | [Modal open, tab selection] | [useState / useReducer] | - | [Reset to default / preserved] |
+| Temporary state | [Form input, draft] | [useState / form library] | [Auto-save / manual save] | [Cleared on reset / persisted] |
+
+Fill the Reset/Clear Behavior column when the feature has a reset or clear-all operation. A state that must return to its unused/default value on reset is a state-lifecycle negative contract (the state stays unused/default after reset; Contract Type `state-lifecycle-negative`) — record it so it is verified rather than assumed.
 
 ### UI Action - API Contract Mapping (when feature includes frontend)
 

package/.claude/skills-en/documentation-criteria/references/plan-template.md

@@ -26,8 +26,8 @@ Review Scope: [planned-files scope derived from Design Doc and task targets; for
 - **Failure response**: [extracted from Design Doc]
 
 ### Proof Strategy
-- **Proof obligation source**: [test skeleton annotations (primary failure mode, proof obligation) when skeletons exist; otherwise each AC's primary failure mode]
-- **Per-task propagation**: every task that implements a claim records Proof Obligations (see task template) so downstream review can judge whether the tests prove the claim, not merely run
+- **Proof obligation source**: [test skeleton annotations (primary failure mode, proof obligation) when skeletons exist; otherwise each AC's primary failure mode; plus any applicable Failure Mode Checklist categories mapped to tasks]
+- **Per-task propagation**: every task that implements a claim or covers an applicable Failure Mode Checklist category records Proof Obligations (see task template) so downstream review can judge whether the tests prove the claim, not merely run
 
 ## Quality Assurance Mechanisms (from Design Doc)
 
@@ -61,7 +61,7 @@ Include this section when the Design Doc specifies a **binding observable value*
 
 ## Failure Mode Checklist
 
-Domain-independent failure categories this implementation must guard against. Enumerate all eight categories, mark each in the Applies? column as yes/no, and list a covering task for each that applies; keep entries free of project-specific names.
+Domain-independent failure categories this implementation must guard against. Enumerate all nine categories, mark each in the Applies? column as yes/no, and list a covering task for each that applies; keep entries free of project-specific names.
 
 | Category | Applies? | Covered By Task(s) |
 |---|---|---|
@@ -73,6 +73,7 @@ Domain-independent failure categories this implementation must guard against. En
 | unavailable boundary | yes/no | |
 | shared-state dependency | yes/no | |
 | rollback-only visibility | yes/no | |
+| missing-sort-key ordering | yes/no | |
 
 ## UI Spec Component → Task Mapping
 

package/.claude/skills-en/documentation-criteria/references/task-template.md

@@ -74,10 +74,10 @@ Each row is a DD-derived observable contract the implementation in this task mus
 - **Verification level**: [L1: Functional operation as end-user feature / L2: New tests added and passing / L3: Code builds without errors]
 
 ## Proof Obligations
-(One entry per AC or claim this task implements. Derived from test skeleton annotations when present, otherwise from the AC's primary failure mode. Each test must prove its claim. Repeat the block below once per claim; the heading carries the AC ID or claim ID so downstream review can resolve coverage per claim.)
+(One entry per AC, claim, or applicable Failure Mode Checklist category this task covers. Derived from test skeleton annotations when present, otherwise from the AC's primary failure mode or the mapped Failure Mode category. Each test must prove its claim. Repeat the block below once per claim; the heading carries the AC ID, claim ID, or `Failure Mode: <category>` so downstream review can resolve coverage per claim.)
 
-### Obligation: [AC ID or claim ID]
-- **Claim**: [the behavior the AC promises]
+### Obligation: [AC ID, claim ID, or Failure Mode category — e.g., `Failure Mode: missing-sort-key ordering`]
+- **Claim**: [the AC behavior, claim, or failure-mode condition this task must prove]
 - **Primary failure mode**: [the regression the test turns red on]
 - **Boundary to exercise**: [public/integration boundary the test traverses, or "in-process unit"]
 - **State assertion**: [observable state before → action → after for state-changing claims; "N/A" otherwise]

package/.claude/skills-ja/documentation-criteria/references/design-template.md

@@ -281,11 +281,13 @@ unknowns:
 
 ### クライアント状態設計（フロントエンド機能を含む場合）
 
-| 状態カテゴリ | 状態 | 管理方法 | 同期戦略 |
-|------------|------|---------|---------|
-| サーバー状態 | [取得データ] | [キャッシュライブラリ/カスタムフック] | [ポーリング/WebSocket/手動更新] |
-| UIローカル状態 | [モーダル開閉、タブ選択] | [useState/useReducer] | - |
-| 一時状態 | [フォーム入力、下書き] | [useState/フォームライブラリ] | [自動保存/手動保存] |
+| 状態カテゴリ | 状態 | 管理方法 | 同期戦略 | リセット/クリア時の振る舞い |
+|------------|------|---------|---------|--------------------------|
+| サーバー状態 | [取得データ] | [キャッシュライブラリ/カスタムフック] | [ポーリング/WebSocket/手動更新] | [全クリアで消去/保持] |
+| UIローカル状態 | [モーダル開閉、タブ選択] | [useState/useReducer] | - | [デフォルトにリセット/保持] |
+| 一時状態 | [フォーム入力、下書き] | [useState/フォームライブラリ] | [自動保存/手動保存] | [リセットで消去/永続化] |
+
+機能にリセットまたは全クリア操作がある場合、リセット/クリア時の振る舞い列を埋める。リセット時に未使用/デフォルト値へ戻らなければならない状態は state-lifecycle negative 契約（観測可能な契約: リセット後も状態は未使用のまま。Contract Type `state-lifecycle-negative`）であり、想定で済ませず検証されるよう記録する。
 
 ### UIアクション - APIコントラクトマッピング（フロントエンド機能を含む場合）
 

package/.claude/skills-ja/documentation-criteria/references/plan-template.md

@@ -26,8 +26,8 @@
 - **失敗時の対応**: [Design Docから抽出]
 
 ### 証明戦略
-- **証明義務の出所**: [スケルトンが存在する場合はテストスケルトンの注釈（主要な故障モード、証明義務）。存在しない場合は各ACの主要な故障モード]
-- **タスクごとの伝播**: 主張を実装する各タスクは Proof Obligations（task template参照）を記録し、下流のレビューがテストが主張を証明しているか（単に実行されるだけでないか）を判定できるようにする
+- **証明義務の出所**: [スケルトンが存在する場合はテストスケルトンの注釈（主要な故障モード、証明義務）。存在しない場合は各ACの主要な故障モード。加えてタスクにマッピングされた該当する故障モードチェックリストのカテゴリ]
+- **タスクごとの伝播**: 主張を実装する、または該当する故障モードチェックリストのカテゴリをカバーする各タスクは Proof Obligations（task template参照）を記録し、下流のレビューがテストが主張を証明しているか（単に実行されるだけでないか）を判定できるようにする
 
 ## 品質保証メカニズム（Design Docより）
 
@@ -61,7 +61,7 @@ Design Docが、実装が正確に再現すべき**拘束的観測値**を指定
 
 ## 故障モードチェックリスト
 
-この実装が防ぐべきドメイン非依存の故障カテゴリ。8カテゴリすべてを列挙し、各カテゴリの該当列に yes/no を記入し、該当する各カテゴリにカバーするタスクを挙げる。エントリにはプロジェクト固有の名称を含めない。
+この実装が防ぐべきドメイン非依存の故障カテゴリ。9カテゴリすべてを列挙し、各カテゴリの該当列に yes/no を記入し、該当する各カテゴリにカバーするタスクを挙げる。エントリにはプロジェクト固有の名称を含めない。
 
 | カテゴリ | 該当? | カバーするタスク |
 |---|---|---|
@@ -73,6 +73,7 @@ Design Docが、実装が正確に再現すべき**拘束的観測値**を指定
 | unavailable boundary | yes/no | |
 | shared-state dependency | yes/no | |
 | rollback-only visibility | yes/no | |
+| missing-sort-key ordering | yes/no | |
 
 ## UI Specコンポーネント → タスクマッピング
 

package/.claude/skills-ja/documentation-criteria/references/task-template.md

@@ -74,10 +74,10 @@ Metadata:
 - **検証レベル**: [L1: エンドユーザー機能としての動作確認 / L2: 新規テスト追加・パス / L3: ビルドエラーなし]
 
 ## Proof Obligations
-（このタスクが実装するACまたは主張ごとに1エントリ。スケルトンの注釈がある場合はそこから、なければACの主要な故障モードから導出する。各テストは主張を証明すること。下記ブロックを主張ごとに繰り返し、見出しにAC IDまたは主張IDを記載して下流のレビューが主張ごとにカバレッジを解決できるようにする。）
+（このタスクがカバーするAC・主張・該当する故障モードチェックリストのカテゴリごとに1エントリ。スケルトンの注釈がある場合はそこから、なければACの主要な故障モードまたはマッピングされた故障モードカテゴリから導出する。各テストは主張を証明すること。下記ブロックを主張ごとに繰り返し、見出しにAC ID・主張ID・`Failure Mode: <category>` のいずれかを記載して下流のレビューが主張ごとにカバレッジを解決できるようにする。）
 
-### Obligation: [AC IDまたは主張ID]
-- **主張**: [ACが約束する振る舞い]
+### Obligation: [AC ID・主張ID・故障モードカテゴリのいずれか — 例: `Failure Mode: missing-sort-key ordering`]
+- **主張**: [このタスクが証明すべき、ACの振る舞い・主張・故障モード条件]
 - **主要な故障モード**: [テストがレッドになるリグレッション]
 - **検証する境界**: [テストが通過する公開/統合境界、または "in-process unit"]
 - **状態アサーション**: [状態変更を伴う主張では 操作前 → 操作 → 操作後 の観察可能な状態。それ以外は "N/A"]

package/CHANGELOG.md

@@ -5,6 +5,12 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.24.2] - 2026-06-23
+
+### Added
+
+- **Failure-mode and spec-completeness coverage** (agents, skills) — added a ninth domain-independent failure category (`missing-sort-key ordering`), a mode × branch AC-expansion step in technical design, and reset/clear state captured as a `state-lifecycle-negative` contract. Failure Mode Checklist categories now propagate from the work plan to task Proof Obligations and are verified in review (`code-reviewer`, `integration-test-reviewer`), with a deterministic fallback when task files are absent so AC-less obligations are not silently treated as verified. Applied across en/ja.
+
 ## [1.24.1] - 2026-06-21
 
 ### Changed

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-ai-project",
-  "version": "1.24.1",
+  "version": "1.24.2",
   "packageManager": "npm@10.8.2",
   "description": "TypeScript boilerplate with skills and sub-agents for Claude Code. Prevents context exhaustion through role-based task splitting.",
   "keywords": [