create-ai-project 1.23.2 → 1.23.4

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)
@@ -190,7 +191,7 @@ describe('[Feature Name] Integration Test', () => {
 
 **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. Phrase it as design intent describing what to assert; the implementer writes the executable assertions and mock setup
+- `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
 
@@ -331,7 +332,8 @@ Upon completion, report in the following JSON format. Detailed meta information
 
 **Required Compliance**:
 - 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.
+  Import only the test-framework symbols the `it.todo` needs (e.g. `describe`/`it`); the implementing task adds application-module imports, assertions (`expect`), and mock setup alongside the implementation (Red→Green within one task/commit). Keep the module under test out of the skeleton's imports because it may not exist yet — a committed skeleton that references not-yet-implemented code can fail gates that type-check, compile, or load test files before implementation begins (e.g. TypeScript projects may report TS2307).
+  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)
 - Stay within budget; report to user if budget insufficient for critical tests

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
 

package/.claude/agents-en/quality-fixer-frontend.md

@@ -241,10 +241,10 @@ Minimal example (`blocked` — Variant B, missing prerequisites):
 During execution, report progress between tool calls using this format:
 
 ```markdown
-📋 Phase [Number]: [Phase Name]
+Phase [Number]: [Phase Name]
 
 Executed Command: [Command]
-Result: ❌ Errors [Count] / ⚠️ Warnings [Count] / ✅ Pass
+Result: Errors [Count] / Warnings [Count] / Pass
 
 Issues requiring fixes:
 1. [Issue Summary]
@@ -253,7 +253,7 @@ Issues requiring fixes:
    - Fix Method: [Specific Fix Approach]
 
 [After Fix Implementation]
-✅ Phase [Number] Complete! Proceeding to next phase.
+Phase [Number] Complete! Proceeding to next phase.
 ```
 
 This is intermediate output only. The final response must be the JSON result (Step 6).

package/.claude/agents-en/quality-fixer.md

@@ -205,10 +205,10 @@ Minimal example (`blocked` — Variant B, missing prerequisites):
 During execution, report progress between tool calls using this format:
 
 ```markdown
-📋 Phase [Number]: [Phase Name]
+Phase [Number]: [Phase Name]
 
 Executed Command: [Command]
-Result: ❌ Errors [Count] / ⚠️ Warnings [Count] / ✅ Pass
+Result: Errors [Count] / Warnings [Count] / Pass
 
 Issues requiring fixes:
 1. [Issue Summary]
@@ -217,7 +217,7 @@ Issues requiring fixes:
    - Fix Method: [Specific Fix Approach]
 
 [After Fix Implementation]
-✅ Phase [Number] Complete! Proceeding to next phase.
+Phase [Number] Complete! Proceeding to next phase.
 ```
 
 This is intermediate output only. The final response must be the JSON result (Step 6).

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

@@ -65,6 +65,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
 2. **Plan Analysis and Overall Design**
    - Confirm phase structure
    - Extract task list
+     - Skip any task already checked off (`[x]`) and annotated as committed (e.g. a Phase 0 resolved by the prepare-implementation recipe) — its work is already in the codebase. Generate task files only for outstanding (`[ ]`) tasks so completed work is not regenerated or re-executed
    - Identify dependencies
    - **Overall Optimization Considerations**
      - Identify common processing (prevent redundant implementation)
@@ -287,7 +288,7 @@ Task 3: [Content]
 ### Decomposition Completion Report
 
 ```markdown
-📋 Task Decomposition Complete
+Task Decomposition Complete
 
 Plan Document: [Filename]
 Overall Design Document: _overview-[plan-name].md

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,12 +111,12 @@ 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
 
-**In scope**: Read task files from `docs/plans/tasks/`, review dependency deliverables listed in task "Metadata", create React function components and React Testing Library tests, co-locate tests with components, apply Red→Green→Refactor TDD, update progress checkboxes (task file always; work plan and overall design only when those files exist — at small scale only the task file exists), produce research deliverables specified in `Provides`. State transitions: `[ ]` → `[🔄]` → `[x]`.
+**In scope**: Read task files from `docs/plans/tasks/`, review dependency deliverables listed in task "Metadata", create React function components and React Testing Library tests, co-locate tests with components, apply Red→Green→Refactor TDD, update progress checkboxes (task file always; work plan and overall design only when those files exist — at small scale only the task file exists), produce research deliverables specified in `Provides`. State transitions: `[ ]` → `[x]`.
 
 **Out of scope (always)**: Overall quality checks (delegated to quality assurance), commit creation (after quality checks), forcing implementation when Design Doc cannot be satisfied (always escalate), class components (deprecated in modern React).
 

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,12 +111,12 @@ 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
 
-**In scope**: Read task files from `docs/plans/tasks/`, review dependency deliverables listed in task "Metadata", create implementation and tests, apply Red→Green→Refactor TDD, update progress checkboxes (task file always; work plan and overall design only when those files exist — at small scale only the task file exists), produce research deliverables specified in `Provides`. State transitions: `[ ]` → `[🔄]` → `[x]`.
+**In scope**: Read task files from `docs/plans/tasks/`, review dependency deliverables listed in task "Metadata", create implementation and tests, apply Red→Green→Refactor TDD, update progress checkboxes (task file always; work plan and overall design only when those files exist — at small scale only the task file exists), produce research deliverables specified in `Provides`. State transitions: `[ ]` → `[x]`.
 
 **Out of scope (always)**: Overall quality checks (delegated to quality assurance), commit creation (after quality checks), forcing implementation when Design Doc cannot be satisfied (always escalate).
 

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

@@ -55,7 +55,7 @@ fixture-e2e gap:
     AND e2eAbsenceReason.fixtureE2e was not communicated
     AND Design Doc or UI Spec contains user-facing multi-step user journey
   THEN add to work plan header:
-    ⚠ fixture-e2e Gap: This feature contains user-facing multi-step journey(s)
+    fixture-e2e Gap: This feature contains user-facing multi-step journey(s)
     but no fixture-e2e skeleton was provided. Route this feature back through
     acceptance-test generation to evaluate fixture-e2e candidates before the
     UI implementation phase.
@@ -68,7 +68,7 @@ service-integration-e2e gap:
         verification (data persistence across services, transactional
         consistency, external service contract)
   THEN add to work plan header:
-    ⚠ service-integration-e2e Gap: This feature crosses service boundaries
+    service-integration-e2e Gap: This feature crosses service boundaries
     where correctness depends on real cross-service behavior, but no
     service-integration-e2e skeleton was provided.
     Detected boundaries: [list crossings and AC references]
@@ -159,8 +159,6 @@ For each task, derive completion criteria from Design Doc acceptance criteria. A
 - **`scale: medium` / `scale: large`**: Write a work plan following the **plan-template** from documentation-criteria skill. Include Phase Structure Diagram and Task Dependency Diagram (mermaid).
 - **`scale: small`**: Write a single task file following the **task-template** from documentation-criteria skill (see "Output Mode by Scale" below). Skip Phase Structure / Task Dependency diagrams; the task file's `## Implementation Steps` section drives execution.
 
-For `scale: medium` / `scale: large`, the plan header MUST include the line `Implementation Readiness: pending`. The marker contract: it takes one of three values — `pending` (initial, set here by work-planner), `ready` (verification completed with no remaining gaps), or `escalated` (verification completed with remaining gaps). The producer that promotes the marker beyond `pending` and the consumer that reads it before execution are external orchestration concerns owned outside this agent.
-
 ## Input Parameters
 
 - **mode**: `create` (default) | `update`
@@ -365,7 +363,6 @@ When creating work plans, **Phase Structure Diagrams** and **Task Dependency Dia
   - [ ] Each row's `Axis` value is exactly one of `placement` | `dependency_direction` | `contract_schema` | `data_flow` | `persistence`
   - [ ] Each row's `Source Section` is set to `Decision` or `Implementation Guidance` matching the actual location of the decision in the ADR
   - [ ] 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)

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

@@ -68,6 +68,7 @@ Phase 1から有効な各ACについて:
    - ハッピーパス（1テスト必須）
    - エラーハンドリング（ユーザーから見えるエラーのみ）
    - エッジケース（ビジネス影響が高い場合のみ）
+   - 境界パス（振る舞いを変えるACのみ）: ACがメインパスでは成立しつつ、別個の分岐・状態・入力クラス・ライフサイクルステップ・フォールバックで退行しうる場合、その境界を証明義務として捉え、テストがそこを通過するようにする
 
 2. **テストレベルを分類**:
    - 統合テスト候補（機能レベルの相互作用）
@@ -192,7 +193,7 @@ describe('[機能名] Integration Test', () => {
 
 **証明注釈**（すべてのスケルトンに、上記メタ情報とともに付与）: 各 `it.todo` は証明コントラクトをテスト実装者と integration-test-reviewer に渡す2行のコメントを持つ（これらは task template の Proof Obligations フィールドに対応する）:
 - `主要な故障モード`: このテストをレッドにする具体的なリグレッション — ACが約束し、壊れると失われる振る舞い
-- `証明義務`: 実装されたテストが主張を証明するためにアサートすべき内容 — 通過する境界、状態変更を伴うACでは操作前後の観測可能な状態、どの境界をなぜモックしてよいか。アサート対象を記述する設計意図として書き、実行可能なアサーションとモック設定は実装者が書く
+- `証明義務`: 実装されたテストが主張を証明するためにアサートすべき内容 — 通過する境界、状態変更を伴うACでは操作前後の観測可能な状態、どの境界をなぜモックしてよいか。振る舞いを変えるACでは、メインパスだけでは、そのリグレッションがあってもグリーンのままになる場合に、テストが通過すべき境界パス（分岐・状態・入力クラス・ライフサイクルステップ・フォールバック）を明示する。アサート対象を記述する設計意図として書き、実行可能なアサーションとモック設定は実装者が書く
 
 ### E2Eテストファイル群
 
@@ -333,7 +334,8 @@ it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 
 **必須準拠事項**:
 - `it.todo`スケルトンのみ出力: 各スケルトン内にコメントとして検証観点、期待結果、合格基準、主要な故障モード、証明義務を記述。
-  実装コード、アサーション(`expect`)、モックセットアップは含めない — 下流の処理で`it.todo`の有無によりフェーズ配置やレビュー判定が行われる。
+  `it.todo` が必要とするテストフレームワークのシンボル（`describe`/`it` など）のみを import する。アプリケーション側モジュールの import、アサーション(`expect`)、モックセットアップは、実装と同じタスク/コミットで実装時に追加する（Red→Green を1コミット内に収める）。テスト対象モジュールはまだ存在しない可能性があるため、スケルトンの import には含めない — 未実装コードを参照するスケルトンをコミットすると、テストファイルを型チェック・コンパイル・ロードするゲートが実装着手前に失敗し得る（例: TypeScript では TS2307 が報告され得る）。
+  下流の処理では`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. 識別子の検証
 

package/.claude/agents-ja/quality-fixer-frontend.md

@@ -241,10 +241,10 @@ package.json からフロントエンドビルドコマンドを自動検出し
 実行中、ツール呼び出しの間に以下のフォーマットで進捗を報告する:
 
 ```markdown
-📋 Phase [番号]: [フェーズ名]
+Phase [番号]: [フェーズ名]
 
 実行コマンド: [コマンド]
-結果: ❌ エラー [件数] / ⚠️ 警告 [件数] / ✅ パス
+結果: エラー [件数] / 警告 [件数] / パス
 
 修正が必要な問題:
 1. [問題概要]
@@ -253,7 +253,7 @@ package.json からフロントエンドビルドコマンドを自動検出し
    - 修正方法: [具体的な修正アプローチ]
 
 [修正実施後]
-✅ Phase [番号] 完了！次のフェーズへ進みます。
+Phase [番号] 完了！次のフェーズへ進みます。
 ```
 
 これは中間出力であり、最終レスポンスはJSON結果（ステップ6）で出力する。

package/.claude/agents-ja/quality-fixer.md

@@ -205,10 +205,10 @@ coding-standardsおよびtypescript-testingスキルに従って修正を適用
 実行中、ツール呼び出しの間に以下のフォーマットで進捗を報告する:
 
 ```markdown
-📋 Phase [番号]: [フェーズ名]
+Phase [番号]: [フェーズ名]
 
 実行コマンド: [コマンド]
-結果: ❌ エラー [件数] / ⚠️ 警告 [件数] / ✅ パス
+結果: エラー [件数] / 警告 [件数] / パス
 
 修正が必要な問題:
 1. [問題概要]
@@ -217,7 +217,7 @@ coding-standardsおよびtypescript-testingスキルに従って修正を適用
    - 修正方法: [具体的な修正アプローチ]
 
 [修正実施後]
-✅ Phase [番号] 完了！次のフェーズへ進みます。
+Phase [番号] 完了！次のフェーズへ進みます。
 ```
 
 これは中間出力であり、最終レスポンスはJSON結果（ステップ6）で出力する。

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

@@ -65,6 +65,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 2. **計画書の分析と全体設計**
    - フェーズ構成の確認
    - タスクリストの抽出
+     - `[x]` で完了マーク済みかつコミット済みと注記されたタスク（例: prepare-implementation レシピが解消した Phase 0）はスキップする — その作業は既にコードベースに存在する。未消化（`[ ]`）のタスクのみタスクファイルを生成し、完了済みの作業を再生成・再実行しない
    - 依存関係の特定
    - **全体最適化の検討**
      - 共通処理の識別（冗長実装の防止）
@@ -287,7 +288,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 ### 分解完了レポート
 
 ```markdown
-📋 タスク分解完了
+タスク分解完了
 
 計画書: [ファイル名]
 全体設計書: _overview-[plan-name].md

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

@@ -94,6 +94,12 @@ package.json の `packageManager` フィールドに従って実行コマンド
 - 一致したのが (a+c) または (b+c) の組み合わせのみ → エスカレーション。その他の2項目組み合わせ → 継続実装
 - 1項目以下一致 → 継続実装
 
+### Step4: 中核メカニズム保全チェック（以下1つでもYES → 即エスカレーション）
+タスク・AC・Design Doc・UI Spec が要求する中核メカニズムを保全する。実装詳細（変数名、内部のロジック順序、ローカルな構造）は自由に変更してよいが、要求された中核メカニズムそのものは保つ。
+□ 要求された中核メカニズムを、より単純または弱い代替で置き換えようとしている？（テストが通ることは代替を正当化しない）
+□ 要求された中核メカニズムが仕様どおりには実現不可能？
+1つでもYES → 実装を中止し、`escalation_type: "design_compliance_violation"` でエスカレーション（エスカレーションレスポンス表に従い、ケースを契約フィールドに対応づける）: `design_doc_expectation` = 要求された中核メカニズムと、その出所となる文言（task/AC/Design Doc/UI Spec）; `actual_situation` = 提案された代替と、結果として生じる振る舞いの差分; `why_cannot_implement` = 中核メカニズムを置き換えた、または仕様どおりに実現できない理由; `attempted_approaches[]` = 中核メカニズムを保全するために試みた方法。実装前に実現不可能と判明している場合は `[]`; `claude_recommendation` = ブロックを解除する条件。
+
 ### 境界ケースと鉄則
 
 | ケース | 継続 | エスカレーション |
@@ -105,12 +111,12 @@ package.json の `packageManager` フィールドに従って実行コマンド
 
 **鉄則 — 客観的に判定不可のときはエスカレーション**: 判定項目について2通り以上の解釈が成り立つ; 過去の実装経験で遭遇していないパターン; 判定に必要な情報がDesign Docにない; 同等の技術者でも判断が分かれる。
 
-### 継続実装可（Step1-3 の全チェックが NO かつ明確に該当）
+### 継続実装可（Step1-4 の全チェックが NO かつ明確に該当）
 内部詳細の最適化（変数名、ロジック順序）; Design Doc 未記載の詳細仕様; 外部 API レスポンス用の `unknown` → 具体型への安全な型ガード; 軽微なUI・メッセージ文言調整。
 
 ## 責務・権限・境界
 
-**範囲内**: `docs/plans/tasks/` からタスクファイルを読み込み、タスクの「Metadata」に記載された依存成果物を確認、React 関数コンポーネントと React Testing Library テストを作成、テストはコンポーネントと共に配置（co-locate）、Red→Green→Refactor のTDDを適用、進捗チェックボックスを更新（タスクファイルは常時更新。作業計画書と全体設計書は存在する場合のみ更新 — 小規模単一タスクではタスクファイルのみ存在）、`Provides` に指定された調査成果物を作成。状態遷移: `[ ]` → `[🔄]` → `[x]`。
+**範囲内**: `docs/plans/tasks/` からタスクファイルを読み込み、タスクの「Metadata」に記載された依存成果物を確認、React 関数コンポーネントと React Testing Library テストを作成、テストはコンポーネントと共に配置（co-locate）、Red→Green→Refactor のTDDを適用、進捗チェックボックスを更新（タスクファイルは常時更新。作業計画書と全体設計書は存在する場合のみ更新 — 小規模単一タスクではタスクファイルのみ存在）、`Provides` に指定された調査成果物を作成。状態遷移: `[ ]` → `[x]`。
 
 **範囲外（常に）**: 全体品質チェック（品質保証工程に委譲）、コミット作成（品質チェック後に実施）、Design Doc を満たせない場合の強行（必ずエスカレーション）、クラスコンポーネント（モダン React では非推奨）。
 

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

@@ -94,6 +94,12 @@ package.json の `packageManager` フィールドに従って実行コマンド
 - 一致したのが (a+c) または (b+c) の組み合わせのみ → エスカレーション。その他の2項目組み合わせ → 継続実装
 - 1項目以下一致 → 継続実装
 
+### Step4: 中核メカニズム保全チェック（以下1つでもYES → 即エスカレーション）
+タスク・AC・Design Doc・参照資料が要求する中核メカニズムを保全する。実装詳細（変数名、内部の処理順序、ローカルな構造）は自由に変更してよいが、要求された中核メカニズムそのものは保つ。
+□ 要求された中核メカニズムを、より単純または弱い代替で置き換えようとしている？（テストが通ることは代替を正当化しない）
+□ 要求された中核メカニズムが仕様どおりには実現不可能？
+1つでもYES → 実装を中止し、`escalation_type: "design_compliance_violation"` でエスカレーション（エスカレーションレスポンス表に従い、ケースを契約フィールドに対応づける）: `design_doc_expectation` = 要求された中核メカニズムと、その出所となる文言（task/AC/Design Doc/参照資料）; `actual_situation` = 提案された代替と、結果として生じる振る舞いの差分; `why_cannot_implement` = 中核メカニズムを置き換えた、または仕様どおりに実現できない理由; `attempted_approaches[]` = 中核メカニズムを保全するために試みた方法。実装前に実現不可能と判明している場合は `[]`; `claude_recommendation` = ブロックを解除する条件。
+
 ### 境界ケースと鉄則
 
 | ケース | 継続 | エスカレーション |
@@ -105,12 +111,12 @@ package.json の `packageManager` フィールドに従って実行コマンド
 
 **鉄則 — 客観的に判定不可のときはエスカレーション**: 判定項目について2通り以上の解釈が成り立つ; 過去の実装経験で遭遇していないパターン; 判定に必要な情報がDesign Docにない; 同等の技術者でも判断が分かれる。
 
-### 継続実装可（Step1-3 の全チェックが NO かつ明確に該当）
+### 継続実装可（Step1-4 の全チェックが NO かつ明確に該当）
 内部詳細の最適化（変数名、処理順序）; Design Doc 未記載の詳細仕様; `unknown` → 具体型への安全な型ガード; 軽微なUI・メッセージ文言調整。
 
 ## 責務・権限・境界
 
-**範囲内**: `docs/plans/tasks/` からタスクファイルを読み込み、タスクの「Metadata」に記載された依存成果物を確認、実装とテストを作成、Red→Green→Refactor のTDDを適用、進捗チェックボックスを更新（タスクファイルは常時更新。作業計画書と全体設計書は存在する場合のみ更新 — 小規模単一タスクではタスクファイルのみ存在）、`Provides` に指定された調査成果物を作成。状態遷移: `[ ]` → `[🔄]` → `[x]`。
+**範囲内**: `docs/plans/tasks/` からタスクファイルを読み込み、タスクの「Metadata」に記載された依存成果物を確認、実装とテストを作成、Red→Green→Refactor のTDDを適用、進捗チェックボックスを更新（タスクファイルは常時更新。作業計画書と全体設計書は存在する場合のみ更新 — 小規模単一タスクではタスクファイルのみ存在）、`Provides` に指定された調査成果物を作成。状態遷移: `[ ]` → `[x]`。
 
 **範囲外（常に）**: 全体品質チェック（品質保証工程に委譲）、コミット作成（品質チェック後に実施）、Design Doc を満たせない場合の強行（必ずエスカレーション）。
 

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

@@ -30,29 +30,7 @@ ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判
 
 ### ゲート順序 [BLOCKING]
 
-以下のサブセクションは並列の必須事項ではなく、4段階の直列ゲートを構成する。各ゲートを完了してから次のゲートに進むこと。各ゲート内では列挙されたサブセクションすべてが必須（各サブセクションの条件に従う）。
-
-**Gate 0 — Inputs and Standards**（上流依存なし）:
-- Agreement Checklist
-- Standards Identification
-
-**Gate 1 — Existing State Analysis**（Gate 0 に依存）:
-- Existing Code Investigation
-- Fact Disposition（Codebase Analysis 入力が提供される場合）
-- Minimal Surface Alternatives（永続化されるクライアント/サーバー状態、所有境界を越える Props またはフィールド — エクスポートされた再利用可能コンポーネントの公開 API Props、Context 値、所有境界を越えて持ち上げられた状態 — 観測可能な振る舞いを変える振る舞いモード/バリアント、または再利用可能なコンポーネント分割を導入する場合）
-
-**Gate 2 — Design Decisions**（Gate 1 に依存）:
-- Implementation Approach Decision
-- Common ADR Process
-- Data Contracts
-- State Transitions（該当する場合）
-
-**Gate 3 — Impact Documentation**（Gate 2 に依存）:
-- Integration Point Analysis
-- Change Impact Map
-- Interface Change Impact Analysis
-
-各サブセクションには見出しに `[Gate N — ...]` の注記を付す。サブセクションはゲート順（Gate 0 → 1 → 2 → 3）で記載されており、文書順に実行すること。
+以下のサブセクションは並列の必須事項ではなく、4段階の直列ゲートを構成する: **Gate 0** Inputs & Standards → **Gate 1** Existing-State Analysis → **Gate 2** Design Decisions → **Gate 3** Impact Documentation。各ゲートを完了してから次のゲートに進むこと。各サブセクションには見出しに `[Gate N — ...]` の注記（適用条件を含む）が付き、ゲート順に記載されている。文書順に実行すること。
 
 ### 合意事項チェックリスト [Gate 0 — Required]
 Design Doc作成の最初に必ず実施：
@@ -331,31 +309,7 @@ UI Specが存在する場合（`docs/ui-spec/{feature-name}-ui-spec.md`）:
 
 **必須**: ADR/Design Doc 内の実装サンプルは frontend-typescript-rules スキルに必ず準拠すること。必須項目: function components（class components は非推奨）; 全コンポーネントに Props 型定義; ロジック再利用にはカスタムフック; 厳密な型（外部APIレスポンスは `unknown` + 型ガード、`any` 禁止）; Error Boundary / エラー状態管理; 環境変数 — 秘密情報はサーバーサイドのみ。
 
-準拠サンプル（Props型付き function component、`unknown` を型ガードする 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 }
-}
-```
-
-非準拠: class components、`any`、ガードなし型なしレスポンス、クライアントサイドに埋め込まれた秘密情報。
+非準拠: class components（Error Boundary を除く）、`any`、ガードなし型なしレスポンス、クライアントサイドに埋め込まれた秘密情報。
 
 ## 図表作成（mermaid）
 
@@ -394,6 +348,14 @@ function useUserData(userId: string) {
 
 ## 受け入れ基準作成ガイドライン
 
+### 価値起点のドラフトと境界拡張
+
+各ACは価値起点でドラフトし、下記のスコーピングルールを適用する前に要件境界へ展開する:
+
+1. **価値起点**: まずユーザーにとっての価値を挙げ、次にそれを実現する観察可能なUIの振る舞い、最後にそれを支える技術的境界を特定する。
+2. **境界への展開**（候補抽出 — 採否は下記のスコーピングルールが決定）: ある振る舞いはハッピーパスでは成立しつつ、別の状態で退行しうる。振る舞いを変えるACごとに、約束した振る舞いが成立すべき箇所すべてでACを検討する — 単一/最新/全件のリスト描画、隣接する Props やフィールド、ローディング/空/エラーおよび後続のインタラクション状態、stale または欠損データ、フェッチ失敗やフォールバックUI、権限/バリデーションのゲーティング、入力スコープと順序/選択、副作用、可視性やルートの境界（状態が別画面・別コンポーネント・ナビゲーション後に観察可能になる箇所）。
+3. **同一粒度での比較**: ACが既存または参照先の振る舞いに関わる場合、参照元（source）の振る舞いと対象（target）の振る舞いを同じ詳細度で記述し、各境界が保持されているか意図的に変更されたかをレビュアーが確認できるようにする。
+
 ### 自律実装のためのACスコーピング（フロントエンド）
 
 **原則**: AC = 隔離されたCI環境でブラウザ上で検証可能なユーザー観察可能動作。ハッピーパス、アンハッピーパス（エラー）、エッジケース（空状態・ローディング状態）をカバー。重要なACを上位に配置し、非機能要件は別セクションで定義する。