create-ai-project 1.23.4 → 1.24.0

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

@@ -51,6 +51,14 @@ Maps each Design Doc technical requirement to the covering task(s). One row per
 
 **Gap Status values**: `covered` (task exists), `gap` (no task — requires justification in Notes, user confirmation required before plan approval)
 
+## Reference Contract Values
+
+Include this section when the Design Doc specifies a **binding observable value** the implementation must reproduce exactly — extract these from the Design Doc directly, not from the Traceability table's summarized DD Item: a column/label set and order, a derived-display rule (display value derived from another field), or a state-lifecycle negative (the condition under which the state must stay unused). The Traceability table records *that* a row is covered; this table carries the value *verbatim* so the covering task is checked against the exact contract rather than a re-derived summary. Serialized boundaries are owned by the Connection Map below; ADR-derived structural decisions by ADR Bindings. Omit the section when none apply.
+
+| Design Doc (§ Section) | Contract Type | Required Observable Value (verbatim) | Covered By Task(s) |
+|---|---|---|---|
+| [docs/design/XXX.md (§ Section)] | structure-order / derived-display / state-lifecycle-negative | [the exact value copied from the Design Doc — e.g., "the listed fields in the specified order"; "the label shows the looked-up name in place of the raw code"; "the persisted state is applied only when an explicit restore signal is present"] | [Phase X Task Y] |
+
 ## 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.
@@ -68,13 +76,13 @@ Domain-independent failure categories this implementation must guard against. En
 
 ## UI Spec Component → Task Mapping
 
-Include this section when a UI Spec is among the inputs. Maps each component documented in the UI Spec to the task(s) that implement it. task-decomposer reads this table to populate each task's Investigation Targets with the corresponding UI Spec section. Omit the section when no UI Spec exists.
+Include this section when a UI Spec is among the inputs. Maps each component documented in the UI Spec to the task(s) that implement it. This table is read in a downstream step to populate each task's Investigation Targets with the corresponding UI Spec section. Omit the section when no UI Spec exists.
 
 | UI Spec Component (section heading) | States to Cover | Covered By Task(s) | Gap Status | Notes |
 |---|---|---|---|---|
 | [Use the UI Spec heading exactly as written, e.g., "§ Component: AlertCard"] | [default / loading / empty / error / partial — list the states the implementation must produce] | [Phase X Task Y] | covered | |
 
-**Reference key rule**: The component identifier in column 1 is the UI Spec section heading (verbatim). ui-spec-designer enforces unique component headings so this reference resolves to exactly one section.
+**Reference key rule**: The component identifier in column 1 is the UI Spec section heading (verbatim). Component headings are unique, so this reference resolves to exactly one section.
 
 **Gap Status values**: `covered` (task exists), `gap` (no task — requires justification in Notes, user confirmation required before plan approval)
 
@@ -92,11 +100,13 @@ One row per binding decision. A single ADR can contribute multiple rows. A singl
 
 ## Connection Map
 
-Include this section when the implementation crosses more than one package, service, or process boundary. Document each boundary so task-decomposer can propagate boundary context to the implementation tasks on each side. Omit the section when the implementation stays within a single package.
+Include this section when the implementation crosses a package, service, or process boundary, **or when a value is serialized and re-parsed across a boundary even within a single runtime** — through a medium such as a query string, route/CLI argument, environment variable, config entry, message/queue payload, storage key, or file (producer and consumer must agree on the exact representation). Document each boundary so boundary context propagates to the implementation tasks on each side in a downstream step. Record each Owner as concrete file path(s), not a bare module/package/component name, so it resolves as an Investigation Target the executor can read. Omit the section when no such boundary exists.
 
-| Boundary | Owner (left side) | Owner (right side) | Expected Signal | Covered By Task(s) |
-|---|---|---|---|---|
-| [e.g., "web client → API gateway"] | [module/package on the request side] | [module/package on the response side] | [Observable evidence the boundary works — e.g., "HTTP 200 with response matching ContractA", "row inserted in tableB", "message published to topicC"] | [Phase X Task Y on each side] |
+For a serialized boundary, fill Serialized Format and Consumer Parse Rule. Set both to "—" when the contract is already captured by the Expected Signal (e.g., a cross-process call whose body matches the agreed schema); fill them when producer and consumer must agree on a specific encoding of a value (query string, storage key, CLI argument, config entry, message field).
+
+| Boundary | Owner (left side) | Owner (right side) | Serialized Format | Consumer Parse Rule | Expected Signal | Covered By Task(s) |
+|---|---|---|---|---|---|---|
+| [producing side → consuming side] | [owner on the producing side — concrete file path(s)] | [owner on the consuming side — concrete file path(s)] | [exact representation the producer emits; "—" if not serialized] | [how the consumer decodes/validates it; "—" if not serialized] | [Observable evidence the boundary works — e.g., a response matching the agreed contract, or the consumer reproducing the producer's values] | [Phase X Task Y on each side] |
 
 ## Objective
 [Why this change is necessary, what problem it solves]
@@ -212,7 +222,7 @@ This phase is required for ALL implementation approaches.
 - [ ] Security review: Verify security considerations from Design Doc are implemented
 - [ ] Quality checks (types, lint, format)
 - [ ] Execute all tests (including integration/E2E from test skeletons, when provided)
-- [ ] Coverage 70%+
+- [ ] Coverage reviewed as a gap signal on critical paths (any enforced threshold per project CI config)
 - [ ] Document updates
 
 ### Quality Assurance

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

@@ -17,6 +17,13 @@ Metadata:
 Files to read before starting implementation (file path, with optional search hint):
 - [e.g., src/orders/checkout (processOrder function) — determined during task decomposition based on task nature]
 
+## Change Category
+(Include this field only when the task is a bug fix, regression, state-change, or boundary-change — populated during task decomposition. Omit otherwise.)
+
+`Change Category: <one or more of bug-fix, regression, state-change, boundary-change — comma-separated>`
+
+When present, the implementation sweeps the cases sharing the same path, contract, persisted state, or external boundary for the same class of defect (see Implementation Steps Red Phase).
+
 ## Binding Decisions
 (Include this section when the work plan's ADR Bindings table covers this task. Omit otherwise.)
 
@@ -26,12 +33,22 @@ Each row is an ADR decision the implementation in this task must comply with.
 |---|---|---|---|
 | [docs/adr/ADR-XXXX.md (§ <Source Section>) — substitute the section name (`Decision` or `Implementation Guidance`) from the matching work plan row] | [Axis value copied verbatim from the work plan's ADR Bindings row] | [Binding decision copied from the work plan's ADR Bindings row] | [Y/N-answerable positive predicate that evaluates whether the planned/final implementation satisfies the decision] |
 
+## Reference Contracts
+(Include this section when the work plan's Reference Contract Values table covers this task. Omit otherwise.)
+
+Each row is a DD-derived observable contract the implementation in this task must reproduce exactly. Serialized boundaries are carried by the Boundary Context (from the work plan's Connection Map); ADR-derived structural decisions by Binding Decisions above.
+
+| Source | Contract Type | Required Observable Value | Compliance Check |
+|---|---|---|---|
+| [Design Doc path (§ Section) copied from the matching work plan Reference Contract Values row] | [structure-order / derived-display / state-lifecycle-negative, copied from the work plan row] | [Required Observable Value copied verbatim from the work plan row] | [Y/N-answerable positive predicate that evaluates whether the planned/final implementation reproduces the value] |
+
 ## Investigation Notes
 (Implementation observations are appended here before implementation begins. When Binding Decisions exist, record the planned implementation approach and each Compliance Check result here.)
 
 ## Implementation Steps (TDD: Red-Green-Refactor)
 ### 1. Red Phase
 - [ ] Read all Investigation Targets and record key observations
+- [ ] (When Change Category is set) Sweep the adjacent cases sharing the same path/contract/state/boundary for the same class of defect; fold any found within scope into the failing tests
 - [ ] Review dependency deliverables (if any)
 - [ ] Verify/create contract definitions
 - [ ] Write failing tests
@@ -73,6 +90,7 @@ Each row is an ADR decision the implementation in this task must comply with.
 - [ ] Each Proof Obligation is met: the test turns red under its primary failure mode and exercises the stated boundary
 - [ ] Deliverables created (for research/design tasks)
 - [ ] (When Binding Decisions exist) Every Compliance Check evaluates to `Y` against the final implementation, with evidence recorded in Investigation Notes (file:line, test result, or command output)
+- [ ] (When Reference Contracts exist) Every Reference Contract Compliance Check evaluates to `Y` against the final implementation, with evidence recorded in Investigation Notes
 
 ## Notes
 - Impact scope: [Areas where changes may propagate]

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

@@ -59,7 +59,7 @@ Map PRD acceptance criteria to prototype references. Skip this section if no pro
 
 ### Component: [ComponentName]
 
-> Component heading uniqueness: every `Component: [ComponentName]` heading must be unique within this UI Spec. work-planner and task-decomposer reference components by exact heading text — duplicate names or paraphrased headings break the propagation to implementation tasks.
+> Component heading uniqueness: every `Component: [ComponentName]` heading must be unique within this UI Spec. Downstream steps reference components by exact heading text — duplicate names or paraphrased headings break the propagation to implementation tasks.
 
 #### State x Display Matrix
 

package/.claude/skills-en/frontend-technical-spec/SKILL.md

@@ -133,14 +133,10 @@ Quality checks are mandatory upon implementation completion:
 - `test:coverage:fresh` - Coverage measurement
 - `check:all` - Overall integrated check
 
-### Coverage Requirements
-- **Mandatory**: Unit test coverage must be 60% or higher
-- **Component-specific targets**:
-  - Atoms: 70% or higher
-  - Molecules: 65% or higher
-  - Organisms: 60% or higher
-  - Custom Hooks: 65% or higher
-  - Utils: 70% or higher
+### Coverage
+- Treat coverage as a diagnostic signal for finding untested areas, not a target (a target gets gamed into trivial tests — Goodhart's Law)
+- Concentrate test rigor on foundational, high-reuse units (shared components, custom hooks, utils) whose regression has the widest blast radius; higher-composition surfaces (organisms, pages) lean on integration/E2E coverage instead
+- Any enforced numeric threshold is the project's CI/coverage config, not a goal in itself
 
 ### Non-functional Requirements
 - **Browser Compatibility**: Chrome/Firefox/Safari/Edge (latest 2 versions)

package/.claude/skills-en/frontend-typescript-rules/SKILL.md

@@ -34,6 +34,7 @@ const user = raw // narrowed to User
 - **Custom hooks** are the unit of logic reuse and dependency injection (inject collaborators through the hook for testability).
 - **Function parameters:** 0-2 positional; for 3+ take a single options object.
 - **State shape:** type state explicitly; for multi-field state with discrete transitions, use `useReducer` with a discriminated-union action type rather than many `useState` calls.
+- **Server/Client boundary** (RSC frameworks only — e.g. Next.js App Router): default to server components for data fetching/rendering and isolate interactivity behind a `"use client"` boundary at the smallest scope that needs it; keep browser-only APIs (`window`, `localStorage`, event handlers) inside client components, since calling them in a server component breaks the render. N/A for client-only SPAs (e.g. Vite) — skip when the project has no server-component runtime.
 
 ## Error Handling
 - Surface every error: log and handle, or propagate — never swallow.
@@ -41,6 +42,7 @@ const user = raw // narrowed to User
 - Represent expected failures as values with a `Result` type; reserve `throw` for unexpected/unrecoverable cases.
 - Use purpose-specific error classes extending a base `AppError` carrying a `code` (e.g. ValidationError, ApiError, NotFoundError).
 - **Layer responsibilities:** the API layer converts transport errors into domain errors; hooks propagate `AppError` upward; an Error Boundary catches render-time errors and shows fallback UI.
+- **Effect race/cleanup:** guard `useEffect` data fetches against out-of-order responses and post-unmount state updates — abort or ignore stale results (`AbortController` or a mounted flag), or use a server-state library (React Query/SWR) that cancels and dedupes. `try-catch` alone does not cover this.
 - Never log secrets (password, token, apiKey, creditCard).
 
 ```typescript
@@ -63,8 +65,8 @@ class ErrorBoundary extends React.Component<{ children: React.ReactNode; fallbac
 ```
 
 ## Project Conventions
-- **Environment variables:** read through the build tool's env system (`process.env` is absent in the browser). Keep all secrets server-side — frontend code ships to the client.
-- **Bundle & performance:** monitor with the `build` script, keep under 500KB; memoize expensive components (`React.memo`); code-split with `React.lazy` + `Suspense`; structure state to minimize re-renders.
+- **Environment variables:** read client-side env through the bundler's exposed accessor — only vars carrying its public prefix reach the browser; an unprefixed var is `undefined` there. Match the project's bundler: Vite `import.meta.env.VITE_*`, Next.js public `process.env.NEXT_PUBLIC_*`, CRA `process.env.REACT_APP_*`. Keep all secrets server-side — frontend code ships to the client.
+- **Bundle & performance:** monitor bundle size with the `build` script against the project's budget; code-split with `React.lazy` + `Suspense`; structure state to minimize re-renders. Memoization: when React Compiler is enabled, rely on it; reach for manual `React.memo`/`useMemo`/`useCallback` only as a profiler- or identity-justified escape hatch (a measured bottleneck, or stable reference identity for third-party APIs / effect dependencies).
 - **Naming:** components/types `PascalCase`; variables/functions `camelCase`; hooks `use`-prefixed; constants `SCREAMING_SNAKE_CASE`.
 - **Imports:** absolute paths from `src/`; order: React → external libs → internal (absolute) → internal (relative) → type-only → styles/assets.
 - **Formatting:** follow Biome (semicolons and style come from project config).

package/.claude/skills-en/frontend-typescript-testing/SKILL.md

@@ -24,21 +24,15 @@ description: Designs tests with React Testing Library, MSW, and Playwright E2E.
 ## Basic Testing Policy
 
 ### Quality Requirements
-- **Coverage**: Unit test coverage must be 60% or higher (Frontend standard 2025)
+- **Coverage**: prioritize meaningful assertions on critical paths and high-reuse components; treat coverage as a signal for gaps, not a target (a target gets gamed into trivial tests — Goodhart's Law). Any numeric threshold is the project's CI config
 - **Independence**: Each test can run independently without depending on other tests
 - **Reproducibility**: Tests are environment-independent and always return the same results
 - **Readability**: Test code maintains the same quality as production code
 
-### Coverage Requirements (ADR-0002 Compliant)
-**Mandatory**: Unit test coverage must be 60% or higher
-**Component-specific targets**:
-- Atoms (Button, Text, etc.): 70% or higher
-- Molecules (FormField, etc.): 65% or higher
-- Organisms (Header, Footer, etc.): 60% or higher
-- Custom Hooks: 65% or higher
-- Utils: 70% or higher
+### Where to concentrate test rigor
+Test foundational, high-reuse units the hardest — shared components, custom hooks, and utils reused across many features carry the widest blast radius. Higher-composition surfaces (organisms, pages) lean on integration/E2E coverage instead. Any numeric threshold is the project's CI config.
 
-**Metrics**: Statements, Branches, Functions, Lines
+**Metrics** (what coverage reports break down): Statements, Branches, Functions, Lines
 
 ### Test Types and Scope
 1. **Unit Tests (React Testing Library)**
@@ -74,7 +68,7 @@ src/
 
 **Rationale**:
 - React Testing Library best practice
-- ADR-0002 Co-location principle
+- Co-location principle: tests live alongside the implementation they cover
 - Easy to find and maintain tests alongside implementation
 
 ### Naming Conventions

package/.claude/skills-en/frontend-typescript-testing/references/e2e.md

@@ -2,7 +2,7 @@
 
 ## Lane Selection
 
-E2E tests in this workflow split into two lanes (defined in integration-e2e-testing skill):
+E2E tests in this workflow split into two lanes:
 
 | Lane | Backend setup | Use these patterns |
 |------|---------------|-------------------|

package/.claude/skills-en/technical-spec/SKILL.md

@@ -92,6 +92,7 @@ Quality checks are mandatory upon implementation completion:
 - **Cache issues**: Run the `test:coverage:fresh` script
 - **Dependency errors**: Clean reinstall dependencies
 
-### Coverage Requirements
-- **MANDATORY**: Unit test coverage MUST be 70% or higher
-- **Metrics**: Statements, Branches, Functions, Lines
+### Coverage
+- Treat coverage as a diagnostic signal for finding untested areas, not a target (a target gets gamed into trivial tests — Goodhart's Law). Concentrate tests on critical paths and business logic whose regression would matter
+- Any enforced numeric threshold is the project's CI/coverage config, not a goal in itself
+- **Metrics** (what coverage reports break down): Statements, Branches, Functions, Lines

package/.claude/skills-en/typescript-testing/SKILL.md

@@ -14,14 +14,14 @@ description: Applies Vitest test design and quality standards. Provides coverage
 ## Basic Testing Policy
 
 ### Quality Requirements
-- **Coverage**: Unit test coverage must be 70% or higher
+- **Coverage**: treat coverage as a diagnostic signal for finding untested areas, not a target (a target gets gamed into trivial tests — Goodhart's Law). Concentrate tests on critical paths, business logic, and behavior whose regression would matter. Any numeric threshold is the project's CI config
 - **Independence**: Each test can run independently without depending on other tests
 - **Reproducibility**: Tests are environment-independent and always return the same results
 - **Readability**: Test code maintains the same quality as production code
 
-### Coverage Requirements
-**Mandatory**: Unit test coverage must be 70% or higher
-**Metrics**: Statements, Branches, Functions, Lines
+### Coverage
+- Prioritize meaningful assertions over the coverage number; raise coverage where a gap leaves a real regression unguarded, not to hit a percentage
+- **Metrics** (what coverage reports break down): Statements, Branches, Functions, Lines
 
 ### Test Types and Scope
 1. **Unit Tests**

package/.claude/skills-ja/coding-standards/SKILL.md

@@ -29,7 +29,7 @@ description: コードの品質問題、アンチパターン、可読性を検
 
 - **積極的なリファクタリング** - 技術的負債を防ぎ、健全性を維持
 - **使われない「念のため」のコード禁止** - YAGNI原則（Kent Beck）に反する
-- **Minimum Surface for Required Coverage** - 保守対象の要素（永続状態、公開コントラクト要素または境界を越えるフィールド/Props、振る舞いモード/フラグ/バリアント、再利用可能な抽象、コンポーネント分割）を導入する場合、現在のユーザー観察可能な要件と受容済み技術制約（監査、データ整合性、互換性、セキュリティ、パフォーマンス、アクセシビリティ）をカバーする最小の設計面を選ぶ。採用の正当化は「より小さい代替案では満たせない現要件・制約を名指す」形で行い、価値ベースの議論（再利用可能、将来対応、実装が楽）はタイブレーカーのみに用いる。YAGNI との違い: YAGNI は時間軸の判断（将来のためだけの作業はしない）、本原則は固定されたカバレッジ点での設計面を制約する。
+- **Minimum Surface for Required Coverage** - 保守対象の要素（永続状態、公開コントラクト要素または境界を越えるフィールド/Props、振る舞いモード/フラグ/バリアント、再利用可能な抽象、コンポーネント分割）を導入する場合、現在のユーザー観察可能な要件と受容済み技術制約（監査、データ整合性、互換性、セキュリティ、パフォーマンス、アクセシビリティ）をカバーする最小の設計面を選ぶ。採用の正当化は「より小さい代替案では満たせない現要件・制約を明記する」形で行い、価値ベースの議論（再利用可能、将来対応、実装が楽）はタイブレーカーのみに用いる。YAGNI との違い: YAGNI は時間軸の判断（将来のためだけの作業はしない）、本原則は固定されたカバレッジ点での設計面を制約する。
 
 ## コメント記述ルール
 
@@ -283,7 +283,7 @@ Grep -n "targetData\|SetData\|UpdateData" -o content
 - 操作に必要な権限のみを付与（ファイル、データベース接続、APIスコープ）
 
 ### Knowledge Cutoff Supplement (2026-03)
-- OWASP Top 10:2025は症状から根本原因にシフトし、「Software Supply Chain Failures」(A03)と「Mishandling of Exceptional Conditions」(A10)が追加
-- 最近の研究でAI生成コードがAccess Controlの欠落を高い発生率で示す — 認証と認可を高優先度のレビュー対象として扱う
-- OpenSSFが「Security-Focused Guide for AI Code Assistant Instructions」を公開 — 汎用的なアドバイスより言語固有のアクション可能な制約を推奨
+- OWASP Top 10:2025は症状から根本原因へと視点を移し、「Software Supply Chain Failures」(A03)と「Mishandling of Exceptional Conditions」(A10)が追加された
+- 最近の研究ではAI生成コードがAccess Controlの欠落を高い発生率で示しているため、認証と認可を高優先度のレビュー対象として扱う
+- OpenSSFが「Security-Focused Guide for AI Code Assistant Instructions」を公開した。汎用的なアドバイスより、言語固有で実行可能な制約を推奨している
 - 詳細な検出パターンは`references/security-checks.md`を参照

package/.claude/skills-ja/coding-standards/references/security-checks.md

@@ -49,7 +49,7 @@ Sources: OWASP Top 10:2025, DryRun Agentic Coding Security Report (2026-03)
 - 認証ミドルウェアなしで定義されたエンドポイントやルートハンドラ
 - 認可検証なしのリソースアクセス操作（読み取り、更新、削除）
 - 昇格された権限なしでアクセス可能な管理操作や破壊的操作
-- AI生成コードでは認証ミドルウェアと認可チェックの欠落が頻発する — 全ルートハンドラとリソースアクセス操作をレビュー時に明示的に検証対象とする
+- AI生成コードでは認証ミドルウェアと認可チェックの欠落が頻発するため、全ルートハンドラとリソースアクセス操作をレビュー時に明示的に検証対象とする
 - 検出方法: 認証ミドルウェアを持たないルート/エンドポイントハンドラ定義を検索し、呼び出しチェーン内で認可チェックなしのリソース操作（読み取り、更新、削除）を検索
 
 ### 例外条件の不適切な処理（OWASP A10:2025）

package/.claude/skills-ja/documentation-criteria/SKILL.md

@@ -53,7 +53,7 @@ description: PRD、ADR、Design Doc、UI Spec、作業計画書の作成を支
 - 成功指標とKPI（各指標に数値目標、測定方法、期間を明記）
 - ユーザーストーリーとユースケース
 - MoSCoW法による優先順位（Must/Should/Could/Won't）
-- 受入基準に連番ID（AC-001, AC-002, ...）を付与し、下流でのトレーサビリティを確保
+- 受入条件（AC）に連番ID（AC-001, AC-002, ...）を付与し、下流でのトレーサビリティを確保
 - MVPとFutureフェーズの分離
 - ユーザージャーニー図（必須）
 - スコープ境界図（必須）

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

@@ -112,7 +112,7 @@ unknowns:
 
 ### Fact Disposition Table
 
-コードベース分析の`focusAreas`の各エントリに対して1行ずつ記載する。この表は**構造的な既存事実**と設計を結び付ける主たるテーブル（Verification StrategyのOutput Comparisonは**ランタイムの振る舞い**を別途拘束する）。既存の振る舞いに言及する他セクションはこの表の行を`fact_id`値で参照する。
+コードベース分析の`focusAreas`の各エントリに対して1行ずつ記載する。この表は**構造的な既存事実**と設計を結び付ける主たるテーブルである（Verification StrategyのOutput Comparisonは**ランタイムの振る舞い**を別途拘束する）。既存の振る舞いに言及する他セクションは、この表の行を`fact_id`値で参照する。
 
 | Fact ID | Focus Area | Disposition | Rationale | Evidence | Related Files |
 |---------|------------|-------------|-----------|----------|---------------|
@@ -120,7 +120,7 @@ unknowns:
 
 ### Cross-Layer Assumptions（レイヤー横断フロー時のみ）
 
-本Design Docが前レイヤーのDesign Docの未検証主張に依存する場合（Prior-Layer Verification参照）、各主張に正当化と下流検証先を記載する:
+本Design Docが前レイヤーのDesign Docの未検証主張に依存する場合（Prior-Layer Verification参照）、各主張について正当化と下流の検証先を記載する:
 
 - [主張]: [正当化]; 検証先: [ステップまたは成果物]
 
@@ -187,7 +187,7 @@ unknowns:
 
 ### Minimal Surface Alternatives（保守対象の要素を導入する場合）
 
-新規に導入する適用対象要素（永続状態 / 公開コントラクト要素または境界を越えるフィールド・Props / 振る舞いモード・フラグ・バリアント / 再利用可能な抽象またはコンポーネント分割）ごとに1エントリ。設計者エージェントが実行した5ステップの結果を記録する。参照: `coding-standards` スキル「Minimum Surface for Required Coverage」。
+新規に導入する適用対象要素（永続状態 / 公開コントラクト要素または境界を越えるフィールド・Props / 振る舞いモード・フラグ・バリアント / 再利用可能な抽象またはコンポーネント分割）ごとに1エントリ。設計者エージェントが実行した5ステップの結果を記録する。参照: 「Minimum Surface for Required Coverage」の原則。
 
 #### Element 1: [新規要素の名前]
 
@@ -220,7 +220,7 @@ unknowns:
 - **選定**: [代替案の名前]
 - **根拠**:
   - 選定が検討した中で最小の代替案である場合: 「検討した中で最小の代替案であり、これ以上の縮減余地なし」と記載
-  - 選定が最小でない場合: ステップ1から、より小さい代替案では満たせない現要件を名指す
+  - 選定が最小でない場合: ステップ1から、より小さい代替案では満たせない現要件を明記する
 
 **ステップ5 — 不採用案の記録**
 - [代替案の名前]: [何だったか・なぜ不採用かを1〜2行]
@@ -254,7 +254,11 @@ unknowns:
 ```
 
 ### フィールド伝播マップ（フィールドが境界を越える場合）
+
+ここでの境界には**シリアライズ境界** — 一方の側でエンコードされ、クエリ文字列、CLI引数、環境変数、設定エントリ、メッセージ/キューのペイロード、ストレージキー、ファイルなどの媒体を介して他方の側でパースされる値 — も含まれ、インメモリの受け渡しに限らない。シリアライズ境界の行では `Serialized: [producerが出力する正確な表現]; Parse: [consumerがどうデコード/検証するか]` — すなわち **Serialized Format** と **Consumer Parse Rule** — を付記し、producerとconsumerが合意するようにする。インメモリの受け渡しでは付記を省略する。
+
 - [フィールド名]: [コンポーネントA → B] — preserved / transformed / dropped — [理由]
+- [フィールド名]: [コンポーネントA → B] — transformed — Serialized: [正確な表現]; Parse: [デコード/検証ルール] — [理由]（シリアライズ境界）
 
 ### 状態遷移と不変条件
 
@@ -406,9 +410,9 @@ unknowns:
 
 「Minimal Surface Alternatives → ステップ5（不採用案）」との区別: ステップ5 は単一の適用対象要素内で比較・棄却した要素レベルの代替案を記録する。本セクションは個別の要素に結び付かない、より粒度の大きな能力レベルの項目（検討したが今回の設計面に含めなかった機能や能力）を記録する。
 
-- **先送りした機能・能力**: [設計時に検討したが現在の設計面から明示的に除外した機能・能力。各エントリには、これが満たしたはずの現要件を名指して記載する]
+- **先送りした機能・能力**: [設計時に検討したが現在の設計面から明示的に除外した機能・能力。各エントリには、これが満たしたはずの現要件を明記する]
 - **意図的な限定**: [意図的に小さく抑えた範囲とその理由]
-- **拡張ポイント（既存・現在のコンシューマーあり）**: [現在のコンシューマーがすでに利用している既存のインターフェースやフック。各エントリには現在のコンシューマーを名指して記載する]
+- **拡張ポイント（既存・現在のコンシューマーあり）**: [現在のコンシューマーがすでに利用している既存のインターフェースやフック。各エントリには現在のコンシューマーを明記する]
 
 ## リスクと対策
 

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

@@ -51,6 +51,14 @@ Design Docの各技術要件をカバーするタスクへのマッピング。
 
 **ギャップステータス値**: `covered`（タスクあり）、`gap`（タスクなし — 備考に理由必須、計画承認前にユーザー確認が必要）
 
+## Reference Contract Values
+
+Design Docが、実装が正確に再現すべき**拘束的観測値**を指定する場合に本セクションを記載する。これらは設計-計画トレーサビリティ表の要約されたDD項目からではなく、Design Docから直接抽出する: 列/ラベルの集合と順序、派生表示ルール（別フィールドから導出される表示値）、または状態ライフサイクルの否定条件（状態が未使用のままでなければならない条件）。設計-計画トレーサビリティ表は行がカバーされていること*を*記録するが、本表はその値を*逐語で*保持し、カバーするタスクが再導出された要約ではなく正確な契約に対して検証されるようにする。シリアライズ境界は下記のConnection Mapが、ADR由来の構造的決定はADR Bindingsが扱う。該当がない場合は本セクションを省略する。
+
+| Design Doc (§ セクション) | Contract Type | Required Observable Value（逐語） | Covered By Task(s) |
+|---|---|---|---|
+| [docs/design/XXX.md (§ セクション)] | structure-order / derived-display / state-lifecycle-negative | [Design Docからコピーした正確な値 — 例: "指定順序での列挙フィールド"; "ラベルは生コードの代わりに参照名を表示"; "永続状態は明示的な復元シグナルがある場合のみ適用"] | [Phase X タスクY] |
+
 ## 故障モードチェックリスト
 
 この実装が防ぐべきドメイン非依存の故障カテゴリ。8カテゴリすべてを列挙し、各カテゴリの該当列に yes/no を記入し、該当する各カテゴリにカバーするタスクを挙げる。エントリにはプロジェクト固有の名称を含めない。
@@ -68,13 +76,13 @@ Design Docの各技術要件をカバーするタスクへのマッピング。
 
 ## UI Specコンポーネント → タスクマッピング
 
-入力にUI Specが含まれる場合のみ本セクションを記載する。UI Specに記述された各コンポーネントを実装するタスクへのマッピング。task-decomposerはこの表を読み込み、対応するUI Specセクションを各タスクのInvestigation Targetsに伝播させる。UI Specがない場合は本セクションを省略する。
+入力にUI Specが含まれる場合のみ本セクションを記載する。UI Specに記述された各コンポーネントを実装するタスクへのマッピング。この表は下流ステップで読み込まれ、対応するUI Specセクションを各タスクのInvestigation Targetsに伝播させる。UI Specがない場合は本セクションを省略する。
 
 | UI Specコンポーネント（セクション見出し） | カバーする状態 | カバーするタスク | ギャップステータス | 備考 |
 |---|---|---|---|---|
 | [UI Specの見出しを完全一致で記載。例: "§ コンポーネント: AlertCard"] | [default / loading / empty / error / partial — 実装が満たすべき状態を列挙] | [Phase X タスクY] | covered | |
 
-**参照キーのルール**: 列1のコンポーネント識別子はUI Specのセクション見出し（完全一致）。ui-spec-designerが見出しの一意性を保証するため、この参照は1つのセクションに一意に解決する。
+**参照キーのルール**: 列1のコンポーネント識別子はUI Specのセクション見出し（完全一致）。見出しは一意であるため、この参照は1つのセクションに一意に解決する。
 
 **ギャップステータス値**: `covered`（タスクあり）、`gap`（タスクなし — 備考に理由必須、計画承認前にユーザー確認が必要）
 
@@ -82,7 +90,7 @@ Design Docの各技術要件をカバーするタスクへのマッピング。
 
 ADRが入力として与えられた場合、またはDesign Docの「Prerequisite ADRs」セクションに記載されている場合に本セクションを記載する。実装を拘束する各ADR決定を、それが制約するタスクへマッピングする。該当するADRがない場合は本セクションを省略する。
 
-決定が**実装拘束的**であるのは、コード配置、依存方向、コントラクト/スキーマ形状、データフロー、または永続化を制約する場合である。受入基準と必要な振る舞いはDesign Docに記録される。本表はADR由来の構造的制約のみを扱う。
+決定が**実装拘束的**であるのは、コード配置、依存方向、コントラクト/スキーマ形状、データフロー、または永続化を制約する場合である。ACと必要な振る舞いはDesign Docに記録される。本表はADR由来の構造的制約のみを扱う。
 
 | ADR | Source Section | Axis | Binding Decision | Covered By Task(s) |
 |---|---|---|---|---|
@@ -92,11 +100,13 @@ ADRが入力として与えられた場合、またはDesign Docの「Prerequisi
 
 ## Connection Map
 
-実装が複数のパッケージ、サービス、またはプロセス境界をまたがる場合のみ本セクションを記載する。各境界を文書化することで、task-decomposerは境界の文脈を両側の実装タスクに伝播できる。実装が単一パッケージ内に収まる場合は本セクションを省略する。
+実装がパッケージ、サービス、またはプロセス境界をまたがる場合、**または値がシリアライズされ単一ランタイム内であっても境界をまたいで再パースされる場合**（クエリ文字列、ルート/CLI引数、環境変数、設定エントリ、メッセージ/キューのペイロード、ストレージキー、ファイルなどの媒体を介する。producerとconsumerは正確な表現をあらかじめ取り決めておく必要がある）に本セクションを記載する。各境界を文書化することで、下流ステップで境界の文脈を両側の実装タスクに伝播できる。各オーナーは、後続の工程でそのままInvestigation Targetとして読み取れるよう、モジュール/パッケージ/コンポーネント名ではなく具体的なファイルパスで記録する。該当する境界がない場合は本セクションを省略する。
 
-| 境界 | オーナー（左側） | オーナー（右側） | 期待されるシグナル | カバーするタスク |
-|---|---|---|---|---|
-| [例: "web client → API gateway"] | [リクエスト側のモジュール/パッケージ] | [レスポンス側のモジュール/パッケージ] | [境界の動作を裏付ける観測可能な証拠 — 例: "ContractAに一致するスキーマでHTTP 200"、"tableBに行が挿入される"、"topicCにメッセージが発行される"] | [Phase X 各側のタスクY] |
+シリアライズ境界の場合はSerialized FormatとConsumer Parse Ruleを埋める。契約がExpected Signal（期待されるシグナル）で既に表現されている場合（例: ボディが合意スキーマに一致するクロスプロセス呼び出し）は両方を"—"にする。producerとconsumerが値の特定のエンコーディング（クエリ文字列、ストレージキー、CLI引数、設定エントリ、メッセージフィールド）を取り決める必要がある場合に埋める。
+
+| 境界 | オーナー（左側） | オーナー（右側） | Serialized Format | Consumer Parse Rule | 期待されるシグナル | カバーするタスク |
+|---|---|---|---|---|---|---|
+| [producer側 → consumer側] | [producer側のオーナー — 具体的なファイルパス] | [consumer側のオーナー — 具体的なファイルパス] | [producerが出力する正確な表現; シリアライズでなければ "—"] | [consumerがどうデコード/検証するか; シリアライズでなければ "—"] | [境界の動作を裏付ける観測可能な証拠 — 例: 合意した契約に一致するレスポンス、またはconsumerがproducerの値を再現すること] | [Phase X 各側のタスクY] |
 
 ## 目的
 [なぜこの変更が必要か、何を解決するか]
@@ -212,7 +222,7 @@ Design Docの実装アプローチに基づいてフェーズ構成をひとつ
 - [ ] セキュリティレビュー: Design Docのセキュリティ考慮事項が実装されていることを確認
 - [ ] 品質チェック（型、lint、format）
 - [ ] 全テスト実行（テストスケルトン提供時は統合/E2Eテスト含む）
-- [ ] カバレッジ70%以上
+- [ ] クリティカルパスのギャップシグナルとしてカバレッジを確認（強制しきい値はプロジェクトの CI 設定に従う）
 - [ ] ドキュメント更新
 
 ### 品質保証

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

@@ -17,6 +17,13 @@ Metadata:
 実装開始前に読むべきファイル（ファイルパス、任意でサーチヒント付き）:
 - [例: src/orders/checkout (processOrder関数) — タスクの性質に基づきタスク分解時に決定]
 
+## Change Category
+（タスクがバグ修正・リグレッション・状態変更・境界変更の場合のみ本フィールドを記載する。設定はタスク分解時に行う。それ以外は省略する。）
+
+`Change Category: <bug-fix, regression, state-change, boundary-change のうち該当するものをカンマ区切りで>`
+
+記載がある場合、実装は同一の経路・契約・永続状態・外部境界を共有するケースを、同一クラスの欠陥について走査する（Implementation Steps の Red Phase 参照）。
+
 ## Binding Decisions
 （作業計画書のADR Bindings表がこのタスクをカバーする場合に本セクションを記載する。それ以外は省略する。）
 
@@ -26,12 +33,22 @@ Metadata:
 |---|---|---|---|
 | [docs/adr/ADR-XXXX.md (§ <Source Section>) — 対応する作業計画書の行のセクション名（`Decision` または `Implementation Guidance`）に置き換える] | [作業計画書のADR Bindings行から逐語コピーしたAxis値] | [作業計画書のADR Bindings行からコピーしたバインディング決定] | [計画中/最終の実装が決定を満たすかをY/Nで判定できる肯定述語] |
 
+## Reference Contracts
+（作業計画書のReference Contract Values表がこのタスクをカバーする場合に本セクションを記載する。それ以外は省略する。）
+
+各行は、このタスクの実装が正確に再現すべきDD由来の観測可能契約である。シリアライズ境界はBoundary Context（作業計画書のConnection Mapから）が、ADR由来の構造的決定は上記のBinding Decisionsが扱う。
+
+| Source | Contract Type | Required Observable Value | Compliance Check |
+|---|---|---|---|
+| [対応する作業計画書のReference Contract Values行からコピーしたDesign Docパス (§ セクション)] | [作業計画書の行からコピーしたContract Type: structure-order / derived-display / state-lifecycle-negative] | [作業計画書の行から逐語コピーしたRequired Observable Value] | [計画中/最終の実装が値を再現するかをY/Nで判定できる肯定述語] |
+
 ## Investigation Notes
 （実装観察事項を実装開始前にここへ追記する。Binding Decisionsがある場合、計画した実装アプローチと各Compliance Check結果をここに記録する。）
 
 ## Implementation Steps (TDD: Red-Green-Refactor)
 ### 1. Red Phase
 - [ ] 全ての Investigation Targets を読み、主要な所見を記録
+- [ ] （Change Category が設定されている場合）同一の経路/契約/状態/境界を共有する隣接ケースを同一クラスの欠陥について走査し、スコープ内で見つかったものを失敗するテストに取り込む
 - [ ] Dependencies の成果物を確認（ある場合）
 - [ ] 契約定義を確認・作成
 - [ ] 失敗するテストを書く
@@ -73,6 +90,7 @@ Metadata:
 - [ ] 各 Proof Obligation が満たされている: テストが主要な故障モードでレッドになり、指定された境界を通過する
 - [ ] 成果物作成完了（調査・設計タスクの場合）
 - [ ] （Binding Decisionsがある場合）全てのCompliance Checkが最終実装に対して`Y`と評価され、根拠（file:line、テスト結果、またはコマンド出力）がInvestigation Notesに記録されている
+- [ ] （Reference Contractsがある場合）全てのReference Contract Compliance Checkが最終実装に対して`Y`と評価され、根拠がInvestigation Notesに記録されている
 
 ## Notes
 - 影響範囲: [変更が波及する可能性のある領域]

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

@@ -15,7 +15,7 @@
 
 ## プロトタイプ管理
 
-プロトタイプコードはこのUI Specの**添付資料**です。正式な仕様は常にこのドキュメント + Design Docです。
+プロトタイプコードはこのUI Specの**添付資料**である。正式な仕様は常にこのドキュメント + Design Docである。
 
 - **添付パス**: [docs/ui-spec/assets/{feature-name}/]
 - **バージョン識別**: [コミットSHA / タグ]
@@ -59,7 +59,7 @@ PRDの受入条件をプロトタイプの参照先にマッピング。プロ
 
 ### コンポーネント: [ComponentName]
 
-> コンポーネント見出しの一意性: すべての`コンポーネント: [ComponentName]`見出しはUI Spec内で一意でなければならない。work-plannerとtask-decomposerは見出しテキストの完全一致でコンポーネントを参照するため、重複した名前や言い換えがあると実装タスクへの伝播が破綻する。
+> コンポーネント見出しの一意性: すべての`コンポーネント: [ComponentName]`見出しはUI Spec内で一意でなければならない。下流の工程は見出しテキストの完全一致でコンポーネントを参照するため、重複した名前や言い換えがあると実装タスクへの伝播が破綻する。
 
 #### 状態×表示マトリクス
 
@@ -156,7 +156,7 @@ PRDの受入条件をプロトタイプの参照先にマッピング。プロ
 ## ビジュアル受入条件
 
 ### ゴールデンステート
-受入基準となる主要なビジュアル状態を定義:
+受入条件（AC）となる主要なビジュアル状態を定義:
 
 1. **[状態名]**: [視覚的に確認すべき内容の説明]
 2. **[状態名]**: [説明]

package/.claude/skills-ja/frontend-technical-spec/SKILL.md

@@ -133,14 +133,10 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 - `test:coverage:fresh` - カバレッジ測定
 - `check:all` - 全体統合チェック
 
-### カバレッジ要件
-- **必須**: 単体テストのカバレッジは60%以上
-- **コンポーネント別目標**:
-  - Atoms: 70%以上
-  - Molecules: 65%以上
-  - Organisms: 60%以上
-  - Custom Hooks: 65%以上
-  - Utils: 70%以上
+### カバレッジ
+- カバレッジは目標ではなく未テスト領域を見つける診断シグナルとして扱う（目標化すると自明なテストに歪む — グッドハートの法則）
+- 基盤的で再利用度の高いユニット（共有コンポーネント、カスタムフック、utils）にテストの重点を置く。これらはリグレッション時の影響範囲が最も広い。合成度の高い面（organisms、ページ）は統合/E2Eのカバレッジに委ねる
+- 強制する数値しきい値はプロジェクトの CI / カバレッジ設定であり、それ自体が目的ではない
 
 ### 非機能要件
 - **ブラウザ互換性**: Chrome/Firefox/Safari/Edge（最新2バージョン）

package/.claude/skills-ja/frontend-typescript-rules/SKILL.md

@@ -34,13 +34,15 @@ const user = raw // User に絞り込み済み
 - **Custom hook** をロジック再利用と依存注入の単位とする（テスト容易性のため、協調オブジェクトは hook 経由で注入する）。
 - **関数引数:** 位置引数は 0〜2 個。3 個以上は単一の options オブジェクトで受ける。
 - **状態の形:** 状態は明示的に型付けする。複数フィールドかつ離散的な遷移を持つ状態は、複数の `useState` ではなく discriminated union の action 型を用いた `useReducer` にする。
+- **Server/Client 境界**（RSC フレームワークのみ — 例: Next.js App Router）: データ取得とレンダリングは既定でサーバーコンポーネントに置き、インタラクティブ性は必要最小のスコープで `"use client"` 境界の内側に隔離する。ブラウザ専用 API（`window`、`localStorage`、イベントハンドラ）はクライアントコンポーネント内に留める。サーバーコンポーネントで呼ぶとレンダリングが壊れるためである。クライアントのみの SPA（例: Vite）では N/A であり、サーバーコンポーネントランタイムが無いプロジェクトではスキップする。
 
 ## エラーハンドリング
-- すべてのエラーを表に出す: ログして処理するか伝播する — 握り潰さない。
+- すべてのエラーを表に出す: ログして処理するか伝播し、握り潰さない。
 - **Fail fast:** 不正な状態では、無言のフォールバックを返さず throw する。
 - 想定内の失敗は `Result` 型で値として表現する。`throw` は想定外/回復不能なケースに限る。
 - 目的別のエラークラスは `code` を持つ基底 `AppError` を継承する（例: ValidationError, ApiError, NotFoundError）。
 - **層の責務:** API 層は transport エラーをドメインエラーへ変換する。hook は `AppError` を上位へ伝播する。Error Boundary はレンダリング時のエラーを捕捉しフォールバック UI を表示する。
+- **Effect の競合/クリーンアップ:** `useEffect` 内のデータ取得は、順序が入れ替わった応答とアンマウント後の状態更新に対してガードする。具体的には、`AbortController` か mounted フラグで stale な結果を中断・無視するか、キャンセルと重複排除を行うサーバー状態ライブラリ（React Query/SWR）を使う。`try-catch` だけではこれをカバーできない。
 - 機微情報（password, token, apiKey, creditCard）をログに出さない。
 
 ```typescript
@@ -63,8 +65,8 @@ class ErrorBoundary extends React.Component<{ children: React.ReactNode; fallbac
 ```
 
 ## プロジェクト規約
-- **環境変数:** ビルドツールの環境変数システム経由で読む（ブラウザに `process.env` は存在しない）。秘密情報はすべてサーバーサイドに置く — フロントエンドのコードはクライアントに配信される。
-- **バンドルとパフォーマンス:** `build` スクリプトで監視し 500KB 未満に保つ。高コストなコンポーネントは `React.memo` でメモ化する。`React.lazy` + `Suspense` でコード分割する。再レンダリングを最小化する状態構造にする。
+- **環境変数:** クライアント側の環境変数はバンドラが公開するアクセサ経由で読む。公開プレフィックスを持つ変数だけがブラウザに届き、プレフィックスの無い変数はブラウザでは `undefined` になる。プロジェクトのバンドラに合わせる: Vite は `import.meta.env.VITE_*`、Next.js の公開変数は `process.env.NEXT_PUBLIC_*`、CRA は `process.env.REACT_APP_*`。秘密情報はすべてサーバーサイドに置く。フロントエンドのコードはクライアントに配信されるためである。
+- **バンドルとパフォーマンス:** バンドルサイズは `build` スクリプトでプロジェクトの予算に対して監視する。`React.lazy` + `Suspense` でコード分割する。再レンダリングを最小化する状態構造にする。メモ化: React Compiler が有効なときはそれに任せる。手動の `React.memo`/`useMemo`/`useCallback` は、プロファイラまたは参照同一性で正当化される逃げ道としてのみ用いる（実測されたボトルネック、またはサードパーティ API や effect 依存に対する安定した参照同一性）。
 - **命名:** コンポーネント/型は `PascalCase`、変数/関数は `camelCase`、hook は `use` 接頭辞、定数は `SCREAMING_SNAKE_CASE`。
 - **インポート:** `src/` からの絶対パス。順序: React → 外部ライブラリ → 内部（絶対）→ 内部（相対）→ 型のみ → スタイル/アセット。
 - **フォーマット:** Biome に従う（セミコロンやスタイルはプロジェクト設定に従う）。

package/.claude/skills-ja/frontend-typescript-testing/SKILL.md

@@ -24,21 +24,15 @@ description: React Testing Library、MSW、Playwright E2Eでテストを設計
 ## テストの基本方針
 
 ### 品質要件
-- **カバレッジ**: 単体テストのカバレッジは60%以上を必須（フロントエンド標準 2025）
+- **カバレッジ**: クリティカルパスと高再利用コンポーネントに対する意味のあるアサーションを優先する。カバレッジは目標ではなくギャップ検出のシグナルとして扱う（目標化すると自明なテストに歪む — グッドハートの法則）。数値しきい値はプロジェクトの CI 設定に委ねる
 - **独立性**: 各テストは他のテストに依存せず実行可能
 - **再現性**: テストは環境に依存せず、常に同じ結果を返す
 - **可読性**: テストコードも製品コードと同様の品質を維持
 
-### カバレッジ要件
-**必須**: 単体テストのカバレッジは60%以上
-**コンポーネント別目標**:
-- Atoms（Button、Text等）: 70%以上
-- Molecules（FormField等）: 65%以上
-- Organisms（Header、Footer等）: 60%以上
-- Custom Hooks: 65%以上
-- Utils: 70%以上
+### テストの重点配分
+基盤的で再利用度の高いユニット（共有コンポーネント、カスタムフック、utils）を最も厚くテストする。多くの機能から再利用されるものほど、リグレッション時の影響範囲が広いためである。合成度の高い面（organisms、ページ）は統合/E2Eのカバレッジに委ねる。数値しきい値はプロジェクトの CI 設定に委ねる。
 
-**指標**: Statements（文）、Branches（分岐）、Functions（関数）、Lines（行）
+**指標**（カバレッジレポートの内訳）: Statements（文）、Branches（分岐）、Functions（関数）、Lines（行）
 
 ### テストの種類と範囲
 1. **単体テスト（React Testing Library）**
@@ -74,7 +68,7 @@ src/
 
 **理由**:
 - React Testing Libraryのベストプラクティス
-- ADR-0002 Co-location原則
+- Co-location原則: テストはそれがカバーする実装と同じ場所に置く
 - 実装と一緒にテストを見つけやすく、保守しやすい
 
 ### 命名規則