takt 0.32.1 → 0.32.2

package/builtins/en/facets/instructions/plan.md

@@ -19,7 +19,9 @@ For small tasks, skip the design sections in the report.
 4. Determine file structure and design patterns (if needed)
 5. Decide on the implementation approach
    - Verify the implementation approach does not violate knowledge/policy constraints
+   - When adding or changing a user-facing feature, fix the conditions, entry points, and reachability by which users arrive at it
 6. Include the following in coder implementation guidelines:
    - Existing implementation patterns to reference (file:line). Always cite when similar processing already exists
    - Impact area of changes. Especially when adding new parameters, enumerate all call sites that need wiring
    - Anti-patterns to watch for in this specific task (if applicable)
+   - When adding or changing a user-facing feature, all affected reachability, callers, and launch conditions

package/builtins/en/facets/instructions/review-frontend.md

@@ -7,6 +7,7 @@ Review the changes from a frontend development perspective.
 - Performance (re-renders, memoization)
 - Accessibility (keyboard navigation, ARIA)
 - Data fetching patterns
+- Reachability wiring for user-facing features (routes, entry paths, launch conditions)
 - TypeScript type safety
 
 **Design fidelity check (when a design reference exists):**
@@ -28,5 +29,6 @@ Review {report:coder-decisions.md} to understand the recorded design decisions.
 
 1. Review the change diff and detect issues based on the frontend development criteria above
    - Cross-check changes against REJECT criteria tables defined in knowledge
+   - When new screens or user-facing features are added, verify that entry points and caller wiring were updated as well
 2. For each detected issue, classify as blocking/non-blocking based on Policy's scope determination table and judgment rules
 3. If there is even one blocking issue, judge as REJECT

package/builtins/en/facets/knowledge/frontend.md

@@ -45,6 +45,40 @@ features/{feature-name}/
 └── index.ts
 ```
 
+## Routing Wiring When Adding a Page
+
+Do not stop at creating the page component. A new page must also be wired into an actual entry path. Decide together with the implementation how the page is reached: router, menu, temporary route, or another explicit entry point.
+
+| Criteria | Judgment |
+|----------|----------|
+| A new page exists but no route is registered for it | REJECT |
+| Basename-based URL and route path mapping is not verified | REJECT |
+| Router wiring and page entry are decided together with the page implementation | OK |
+| A temporary development route is used and its purpose/removal plan is recorded | OK |
+| Routes are updated but actual entry points such as menus, buttons, links, or external callers are not checked | Warning |
+
+```tsx
+// OK - page and route are added together
+<Route path="/contreg" element={<ContainerRegisterPage />} />
+
+// REJECT - page exists but has no reachable route
+// src/pages/ContainerRegisterPage.tsx exists
+// Router has no matching route
+```
+
+Reachability is broader than router configuration. Confirm the real entry path users will follow, such as menus, transition buttons, dialog actions, links from other screens, or external callers.
+
+### Integrating third-party UI libraries
+
+Third-party UI libraries such as data grids, date pickers, charts, and virtualized lists can fail at runtime even when types pass. This is especially common across major-version changes where prop names or state model shapes are no longer compatible, and shallow mocks do not expose the problem.
+
+| Criteria | Judgment |
+|----------|----------|
+| Major UI library props are guessed without checking the version used by the project | REJECT |
+| Tests fully mock the library and miss real mount failures | Warning |
+| The real component is rendered with representative props and verified not to crash at screen level | OK |
+| Prop shapes are chosen by referencing existing in-project usage patterns and the installed version | OK |
+
 ## State Management
 
 Child components do not modify their own state. They bubble events to parent, and parent manipulates state.
@@ -78,6 +112,7 @@ Exception (OK for child to have local state):
 | State changes from child to parent (reverse data flow) | REJECT |
 | API response stored as-is in state | Consider normalization |
 | Inappropriate useEffect dependencies | REJECT |
+| Initial load tied to unstable Context/Provider function references | REJECT |
 
 State Placement Guidelines:
 
@@ -88,6 +123,17 @@ State Placement Guidelines:
 | Shared across multiple components | Context or state management library |
 | Server data cache | Data fetching library (TanStack Query, etc.) |
 
+## Initial load and refetch boundaries
+
+Initial loading should be separated from reactive refetching. If refetching is not driven by URL, filter, paging, or explicit user action, keep it mount-only and do not tie it to unstable callback references.
+
+| Criteria | Judgment |
+|----------|----------|
+| Initial load reruns because a Provider/Context callback changed identity | REJECT |
+| Refetch conditions are explicit (URL, filter, paging, refresh action) | OK |
+| Message display, loading toggles, or modal state cause refetching | REJECT |
+| Initial load is mount-only and later refetches are triggered explicitly | OK |
+
 ## Data Fetching
 
 API calls are made in root (View) components and passed to children via props.

package/builtins/en/facets/knowledge/react.md

@@ -0,0 +1,90 @@
+# React Knowledge
+
+## Effects and Re-execution
+
+`useEffect` is a mechanism for declaring when re-execution is allowed, not a generic place to put initialization. Decide first whether a load is mount-only or should rerun on dependency changes.
+
+| Criteria | Judgment |
+|----------|----------|
+| A mount-only initial load depends on recreated function references | REJECT |
+| Context/Provider functions are used as effect dependencies without a clear refetch requirement | REJECT |
+| Mount-only initialization is expressed with `useEffect(..., [])` and its intent is documented | OK |
+| Refetching on dependency change is required by the feature and those dependencies are explicit | OK |
+
+```tsx
+// REJECT - initial load can rerun because unstable function deps leak into the effect
+const fetchList = useCallback(async () => {
+  await loadItems()
+}, [setIsLoading, errorPage])
+
+useEffect(() => {
+  fetchList()
+}, [fetchList])
+
+// OK - explicitly mount-only initial load
+useEffect(() => {
+  void loadItemsOnMount()
+  // mount-only initial load
+  // eslint-disable-next-line react-hooks/exhaustive-deps
+}, [])
+```
+
+## Context and Provider Values
+
+`value={{ ... }}` in a Provider creates a new reference on each Provider render. When functions obtained from Context are placed in effect dependencies, consumers can enter unintended refetch loops.
+
+| Criteria | Judgment |
+|----------|----------|
+| Context-derived functions are placed in effect dependencies without checking reference stability | REJECT |
+| Mount effects rely on Provider functions whose stability is not guaranteed | REJECT |
+| Context functions are used from event handlers while initial load stays mount-only | OK |
+| Provider values are stabilized and refetch conditions are defined explicitly | OK |
+
+```tsx
+// REJECT - Context functions are used directly as initial-load effect deps
+const { setIsLoading, errorPage } = useAppContext()
+useEffect(() => {
+  void loadInitialData(setIsLoading, errorPage)
+}, [setIsLoading, errorPage])
+
+// OK - initial load is mount-only, Context functions are consumed inside it
+const { setIsLoading, errorPage } = useAppContext()
+useEffect(() => {
+  void loadInitialData({ setIsLoading, errorPage })
+  // mount-only initial load
+  // eslint-disable-next-line react-hooks/exhaustive-deps
+}, [])
+```
+
+## Initial Page Load
+
+Treat initial page load separately from reactive refetching. Unless refetching is required by filter, URL, pagination, or explicit user action, keep the initial fetch mount-only.
+
+| Condition | Recommendation |
+|-----------|----------------|
+| List is loaded once on page entry | mount-only effect |
+| Refetching follows filter, pagination, or URL changes | make those states explicit dependencies |
+| Loading state updates trigger refetching | REJECT |
+| Message display or dialog state triggers refetching | REJECT |
+
+## Custom Hook Responsibility
+
+A React custom hook should encapsulate state, effects, refs, or event translation. Pure calculations belong in function modules, not in a `use*` hook.
+
+| Criteria | Judgment |
+|----------|----------|
+| A module is named `use*` but does not use React state/effect/ref | Warning |
+| Pure functions are modeled as a custom hook | Warning |
+| Stateful UI control lives in a custom hook and pure calculations live in functions | OK |
+| A hook returns JSX | REJECT |
+
+## Handling exhaustive-deps
+
+`react-hooks/exhaustive-deps` is not a rule to satisfy mechanically. If adding dependencies changes a mount-only effect into a loop, keep the effect mount-only and document why the suppression exists.
+
+| Criteria | Judgment |
+|----------|----------|
+| Dependencies are added only to satisfy lint and they change runtime behavior | REJECT |
+| Lint suppression is added without explanation | Warning |
+| Mount-only suppression is documented with intent | OK |
+| A reactive effect that should rerun is incorrectly frozen with `[]` | REJECT |

package/builtins/en/facets/output-contracts/plan-frontend.md

@@ -0,0 +1,41 @@
+```markdown
+# Task Plan
+
+## Original Request
+{User's request as-is}
+
+## Analysis
+
+### Objective
+{What needs to be achieved}
+
+### Reference Material Findings (when reference material exists)
+{Overview of reference implementation's approach and key differences from current implementation}
+
+### Design Element Decisions (when design references exist)
+| Element | Keep/Change | Rationale |
+|------|-------------|-----------|
+
+### Scope
+{Impact area}
+
+### Approaches Considered (when design decisions exist)
+| Approach | Adopted? | Rationale |
+|----------|----------|-----------|
+
+### Implementation Approach
+{How to proceed}
+
+## Implementation Guidelines (only when design is needed)
+- {Guidelines the Coder should follow during implementation}
+
+## Out of Scope (only when items exist)
+| Item | Reason for exclusion |
+|------|---------------------|
+
+When design references exist:
+- {Excluded element name, why it is excluded, and why no substitute is taken now}
+
+## Open Questions (if any)
+- {Unclear points or items that need confirmation}
+```

package/builtins/en/facets/output-contracts/plan.md

@@ -22,6 +22,14 @@
 ### Implementation Approach
 {How to proceed}
 
+### Reachability and Launch Conditions (when adding/changing user-facing features)
+| Item | Content |
+|------|---------|
+| User entry point | {Menu/route/button/link/external caller, or explicitly say "none"} |
+| Callers/wiring to update | {Files or layers that must be updated} |
+| Launch conditions | {Auth, permission, URL condition, flags, etc.} |
+| Remaining gaps | {Any unresolved wiring, or "none"} |
+
 ## Implementation Guidelines (only when design is needed)
 - {Guidelines the Coder should follow during implementation}
 

package/builtins/en/facets/policies/coding.md

@@ -204,13 +204,35 @@ return storage.upload(file, options)
 - UI/logic exceeding 50 lines → Separate
 - Has multiple responsibilities → Separate
 
+### Reachability When Adding Features
+
+When adding a new feature or screen, update the paths by which users reach it in the same change set. Framework-specific wiring belongs in domain knowledge.
+
+| Criteria | Judgment |
+|----------|----------|
+| A new feature is implemented but callers, entry points, or navigation are not updated | REJECT |
+| A user-facing feature is added without defining how users reach it | REJECT |
+| Implementation and reachability updates are made in the same change set | OK |
+| A temporary entry path is added and its purpose/removal condition is documented | OK |
+
 ### Dependency Direction
 
 - Upper layers → Lower layers (reverse direction prohibited)
 - Fetch data at the root (View/Controller) and pass it down
 - Children do not know about their parents
 
-### State Management
+### Align execution triggers with actual intent
+
+Dependencies and triggers must match the conditions under which the behavior should actually run again. Do not add triggers only to satisfy linting or implementation convenience if that changes runtime behavior.
+
+| Criteria | Judgment |
+|----------|----------|
+| Dependencies or triggers are expanded only for linting/convenience and create rerun loops | REJECT |
+| Initial processing reruns because of unrelated state changes or recreated callbacks | REJECT |
+| Rerun conditions correspond to URL, filters, explicit refresh actions, or other intended behavior | OK |
+| Initialization and later refetch triggers are designed separately | OK |
+
+## State Management
 
 - Confine state to where it is used
 - Children do not modify state directly (notify parents via events)

package/builtins/en/facets/policies/design-planning.md

@@ -0,0 +1,52 @@
+# Design Planning Policy
+
+When a task includes design references, planning must make element inventory and scope decisions explicit.
+
+## Principles
+
+| Principle | Standard |
+|------|------|
+| Reference-first planning | When design references exist, planning treats them as primary input |
+| Element-level inventory | Differences are checked at the element level, not only at the screen level |
+| Explicit change decision | Each element includes a keep/change decision with rationale |
+| Scope exclusion accountability | If a design element is excluded, the reason must be stated |
+| Clear implementation boundary | The boundary between in-scope and out-of-scope elements is fixed during planning |
+
+## Applicability
+
+This policy applies to planning tasks whose task instructions or reference materials include design references. It does not apply when no design reference exists.
+
+## Decision Criteria
+
+| Criteria | Decision |
+|------|------|
+| Planning proceeds without listing the main design elements | REJECT |
+| There is no keep/change decision for each element | REJECT |
+| Scope is narrowed with vague statements such as "list only this time" without naming elements | REJECT |
+| Out-of-scope elements do not include an exclusion rationale | REJECT |
+| Design interpretation is ambiguous but the rationale is recorded | OK |
+
+## Planning Judgment
+
+Planning inventories the design reference without dropping elements that materially affect the UI or flow.
+
+Inventory viewpoints:
+- Check not only major sections, but also detailed flows, modals, action controls, and state displays
+- Record the current implementation difference and keep/change decision for each element
+- When keeping the existing implementation, cite the target file and rationale
+
+## Scope Decisions
+
+If a design-referenced element is placed out of scope, planning records at least:
+
+- the excluded element name
+- the reason for exclusion
+- the reason no substitute implementation is taken now
+
+Do not split out design-referenced elements as "another task" without explicit rationale.
+
+## Prohibited
+
+- **Planning with only coarse screen-level summaries** - causes missing element coverage
+- **Narrowing the intent of the reference without rationale** - misaligns implementation and review
+- **Omitting the explanation for out-of-scope elements** - makes later movements ambiguous

package/builtins/en/facets/policies/testing.md

@@ -66,6 +66,37 @@ Test names describe expected behavior. Use the `should {expected behavior} when
 - Arrange-Act-Assert pattern (equivalent to Given-When-Then)
 - Avoid magic numbers and magic strings
 
+## Refetch loop regressions
+
+When a page performs initial loading, tests must prove that the load does not rerun because of unrelated re-renders, loading toggles, or Context callback identity changes.
+
+| Criteria | Verdict |
+|----------|---------|
+| Initial load bug fix has no regression test for duplicate API calls | REJECT |
+| Tests only verify that loading happened once, not that it stayed stable after rerender | Warning |
+| Page tests assert call count stability across rerender or state updates | OK |
+
+## Reachability regressions
+
+When adding or changing user-facing features or screens, tests or equivalent verification must prove that users can still reach the feature.
+
+| Criteria | Verdict |
+|----------|---------|
+| A new screen or feature is added with no verification of entry path or launch conditions | REJECT |
+| Only isolated component rendering is tested, without verifying reachability from an entry point | Warning |
+| The feature is verified reachable from an actual entry point such as a route, menu, button, link, or external caller | OK |
+
+## UI library integration regressions
+
+When introducing or changing major third-party UI components such as data grids, date pickers, virtualized lists, or charts, tests must prove that the real component mounts without crashing.
+
+| Criteria | Verdict |
+|----------|---------|
+| A major third-party UI component is added or changed without a regression test that mounts the real component | REJECT |
+| Prop compatibility is checked only through shallow mocks or existence checks | Warning |
+| The screen is rendered from its real entry path and the primary UI mounts without exceptions | OK |
+| The primary UI component is also rendered directly with representative props | OK |
+
 ## Test Strategy
 
 - Prefer unit tests for logic, integration tests for boundaries

package/builtins/en/pieces/dual-cqrs-mini.yaml

@@ -25,6 +25,8 @@ movements:
   - name: plan
     edit: false
     persona: planner
+    policy:
+      - design-planning
     knowledge:
       - frontend
       - backend
@@ -51,7 +53,7 @@ movements:
     output_contracts:
       report:
         - name: plan.md
-          format: plan
+          format: plan-frontend
   - name: implement
     edit: true
     persona: coder

package/builtins/en/pieces/dual-cqrs.yaml

@@ -37,6 +37,8 @@ movements:
   - name: plan
     edit: false
     persona: planner
+    policy:
+      - design-planning
     knowledge:
       - frontend
       - backend
@@ -60,7 +62,7 @@ movements:
     output_contracts:
       report:
         - name: plan.md
-          format: plan
+          format: plan-frontend
   - name: implement
     edit: true
     persona: coder

package/builtins/en/pieces/dual-mini.yaml

@@ -25,6 +25,8 @@ movements:
   - name: plan
     edit: false
     persona: planner
+    policy:
+      - design-planning
     knowledge:
       - frontend
       - backend
@@ -50,7 +52,7 @@ movements:
     output_contracts:
       report:
         - name: plan.md
-          format: plan
+          format: plan-frontend
   - name: implement
     edit: true
     persona: coder

package/builtins/en/pieces/dual.yaml

@@ -37,6 +37,8 @@ movements:
   - name: plan
     edit: false
     persona: planner
+    policy:
+      - design-planning
     knowledge:
       - frontend
       - backend
@@ -63,7 +65,7 @@ movements:
     output_contracts:
       report:
         - name: plan.md
-          format: plan
+          format: plan-frontend
   - name: write_tests
     edit: true
     persona: coder

package/builtins/en/pieces/frontend-mini.yaml

@@ -25,6 +25,8 @@ movements:
   - name: plan
     edit: false
     persona: planner
+    policy:
+      - design-planning
     knowledge:
       - frontend
       - security
@@ -49,7 +51,7 @@ movements:
     output_contracts:
       report:
         - name: plan.md
-          format: plan
+          format: plan-frontend
   - name: implement
     edit: true
     persona: coder

package/builtins/en/pieces/frontend.yaml

@@ -37,8 +37,11 @@ movements:
   - name: plan
     edit: false
     persona: planner
+    policy:
+      - design-planning
     knowledge:
       - frontend
+      - react
       - architecture
     provider_options:
       claude:
@@ -58,7 +61,7 @@ movements:
     output_contracts:
       report:
         - name: plan.md
-          format: plan
+          format: plan-frontend
   - name: write_tests
     edit: true
     persona: coder
@@ -67,6 +70,7 @@ movements:
       - testing
     knowledge:
       - frontend
+      - react
       - architecture
       - unit-testing
       - e2e-testing
@@ -110,6 +114,7 @@ movements:
     session: refresh
     knowledge:
       - frontend
+      - react
       - security
       - architecture
     provider_options:
@@ -175,6 +180,7 @@ movements:
     session: refresh
     knowledge:
       - frontend
+      - react
       - security
       - architecture
     provider_options:
@@ -222,6 +228,7 @@ movements:
         knowledge:
           - architecture
           - frontend
+          - react
         provider_options:
           claude:
             allowed_tools:
@@ -244,7 +251,9 @@ movements:
         policy:
           - review
           - design-fidelity
-        knowledge: frontend
+        knowledge:
+          - frontend
+          - react
         provider_options:
           claude:
             allowed_tools:
@@ -350,6 +359,7 @@ movements:
       - design-fidelity
     knowledge:
       - frontend
+      - react
       - security
       - architecture
     provider_options:
@@ -406,6 +416,7 @@ movements:
       - design-fidelity
     knowledge:
       - frontend
+      - react
       - security
       - architecture
     provider_options:

package/builtins/ja/facets/instructions/plan.md

@@ -25,7 +25,9 @@
 5. ファイル構成・設計パターンを決定する（必要な場合）
 6. 実装アプローチを決める
    - 実装アプローチがナレッジ・ポリシーの制約に違反しないか照合する
+   - 利用者向け機能の追加や変更がある場合、利用者がその機能へ到達する条件・入口・起動経路を固定する
 7. Coder向けの実装ガイドラインに以下を含めること:
    - 参照すべき既存実装パターン（ファイル:行）。同種の処理が既にある場合は必ず示す
    - 変更の影響範囲。特に新しいパラメータを追加する場合、配線が必要な全箇所を列挙する
    - このタスクで特に注意すべきアンチパターン（該当するものがあれば）
+   - 利用者向け機能の追加や変更がある場合、到達経路・呼び出し元・起動条件に関する変更箇所

package/builtins/ja/facets/instructions/review-frontend.md

@@ -7,6 +7,7 @@
 - パフォーマンス（再レンダリング、メモ化）
 - アクセシビリティ（キーボード操作、ARIA）
 - データフェッチパターン
+- 利用者が機能へ到達できる配線（route、導線、起動条件）
 - TypeScript型安全性
 
 **デザイン忠実度チェック（デザイン参照がある場合）:**
@@ -28,5 +29,6 @@
 
 1. 変更差分を確認し、フロントエンド開発の観点に基づいて問題を検出する
    - ナレッジの判定基準テーブル（REJECT条件）と変更内容を照合する
+   - 新規の画面・機能ファイルが追加されている場合、利用者が到達する入口や呼び出し元の更新有無を確認する
 2. 検出した問題ごとに、Policyのスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
 3. ブロッキング問題が1件でもあればREJECTと判定する

package/builtins/ja/facets/knowledge/frontend.md

@@ -37,6 +37,40 @@ View コンポーネント（`features/*/components/*-view.tsx`）がデータ
 ルート（route） → View（データ取得・状態管理） → 子コンポーネント（表示）
 ```
 
+### 画面追加時のルーティング配線
+
+新しい画面を追加したら、画面コンポーネントを作るだけで終わらせず、到達経路まで配線する。Router、メニュー、導線のどこから到達するかを計画時点で固定する。
+
+| 基準 | 判定 |
+|------|------|
+| 新規ページを作成したのに Router に route がない | REJECT |
+| basename 配下の URL と route path の対応を確認していない | REJECT |
+| 画面実装と同時に Router / 導線 / 一時導線の要否を判断している | OK |
+| 開発用の一時導線を使う場合、その理由と後で除去する前提を記録している | OK |
+| route を更新したが、メニュー・ボタン・リンク・外部呼び出しなど実際の入口を未確認 | 警告 |
+
+```tsx
+// OK - 画面実装と route 配線を同時に追加
+<Route path="/contreg" element={<ContainerRegisterPage />} />
+
+// REJECT - 画面実装はあるが到達経路がない
+// src/pages/ContainerRegisterPage.tsx は存在する
+// Router には route がない
+```
+
+到達経路は Router だけではない。メニュー、一覧からの遷移ボタン、ダイアログ内の確定導線、外部画面からのリンクなど、利用者が実際にたどる入口を基準に確認する。
+
+### 外部UIライブラリとの統合
+
+DataGrid、日付ピッカー、チャート、仮想リストのような外部 UI ライブラリは、型が通っても実行時に落ちることがある。特にメジャーバージョン差分では、props 名や state model の互換性を shallow なモックだけでは検出できない。
+
+| 基準 | 判定 |
+|------|------|
+| 主要 UI ライブラリの props を、既存プロジェクトのバージョン確認なしに推測で渡す | REJECT |
+| テストでライブラリ本体を完全にモックし、実マウント時の破綻を見逃す | 警告 |
+| 代表的な props で実コンポーネントを描画し、画面レベルでクラッシュしないことを確認する | OK |
+| 既存画面の利用パターンやプロジェクト依存バージョンを参照して props 形を決める | OK |
+
 ## コンポーネント設計
 
 1ファイルにベタ書きしない。必ずコンポーネント分割する。
@@ -146,6 +180,7 @@ const Parent = () => {
 | 子から親への状態変更（逆方向データフロー） | REJECT |
 | APIレスポンスをそのまま状態に | 正規化を検討 |
 | useEffectの依存配列が不適切 | REJECT |
+| 初期取得が不安定な Context/Provider 関数参照に結び付いている | REJECT |
 
 状態配置の判断基準:
 
@@ -171,6 +206,17 @@ const Parent = () => {
 2. 既存の生成済みクライアントの使用パターンを確認
 3. 新規エンドポイントは生成パイプラインに追加し、生成されたフックを使う
 
+## 初期表示ロードと再取得境界
+
+初期表示ロードはリアクティブな再取得と分けて扱う。URL、フィルタ、ページング、明示的な更新操作がない限り、初回ロードは mount-only に保ち、不安定なコールバック参照に結び付けない。
+
+| 基準 | 判定 |
+|------|------|
+| Provider/Context の関数参照変化で初期取得が再実行される | REJECT |
+| 再取得条件が URL・フィルタ・ページング・更新操作として明示されている | OK |
+| メッセージ表示、loading 切替、dialog 開閉で再取得される | REJECT |
+| 初期取得は mount-only、以後の再取得は明示トリガーで行う | OK |
+
 ## データ取得
 
 API呼び出しはルート（View）コンポーネントで行い、子コンポーネントにはpropsで渡す。

package/builtins/ja/facets/knowledge/react.md

@@ -0,0 +1,90 @@
+# React知識
+
+## effect と再実行
+
+`useEffect` は「いつ再実行してよいか」を明示する仕組みであり、初期化処理の置き場ではない。初期表示で1回だけ行う処理か、依存変化で再実行すべき処理かを先に決める。
+
+| 基準 | 判定 |
+|------|------|
+| 初期表示の一度きりのロードなのに、再生成される関数参照を依存に置く | REJECT |
+| 再取得条件が明確でないのに、Context/Provider 由来関数を依存に置く | REJECT |
+| mount-only 初期化を `useEffect(..., [])` で表現し、意図をコメントで残す | OK |
+| 依存変化時の再取得が仕様として必要で、その依存を明示している | OK |
+
+```tsx
+// REJECT - 初期取得なのに不安定な関数依存を経由して再実行されうる
+const fetchList = useCallback(async () => {
+  await loadItems()
+}, [setIsLoading, errorPage])
+
+useEffect(() => {
+  fetchList()
+}, [fetchList])
+
+// OK - 初期表示の一度きりロードとして固定
+useEffect(() => {
+  void loadItemsOnMount()
+  // mount-only initial load
+  // eslint-disable-next-line react-hooks/exhaustive-deps
+}, [])
+```
+
+## Context と Provider value
+
+Context の `value={{ ... }}` は Provider の再描画ごとに新しい参照になる。Context から受け取った関数を `useEffect` の依存に置くと、利用側が意図せず再実行ループに入ることがある。
+
+| 基準 | 判定 |
+|------|------|
+| Context 由来関数の参照安定性を確認せず、effect 依存に入れる | REJECT |
+| Provider 側で value の安定性が保証されていないのに mount effect の依存に使う | REJECT |
+| Context 関数はイベントハンドラから使い、初期取得は mount-only に閉じる | OK |
+| Provider 側で value 安定化を行い、再取得条件も仕様で定義する | OK |
+
+```tsx
+// REJECT - Context 関数をそのまま初期取得 effect の依存に使う
+const { setIsLoading, errorPage } = useAppContext()
+useEffect(() => {
+  void loadInitialData(setIsLoading, errorPage)
+}, [setIsLoading, errorPage])
+
+// OK - 初期取得は mount-only、Context 関数は内部で使う
+const { setIsLoading, errorPage } = useAppContext()
+useEffect(() => {
+  void loadInitialData({ setIsLoading, errorPage })
+  // mount-only initial load
+  // eslint-disable-next-line react-hooks/exhaustive-deps
+}, [])
+```
+
+## 初期表示ロード
+
+初期表示ロードは「画面を開いたときに1回だけ必要な処理」か、「状態変化に応じて再実行する処理」かを区別する。後者でない限り、再取得のトリガーは明示的なユーザー操作や URL/検索条件の変化に限定する。
+
+| 条件 | 推奨 |
+|------|------|
+| 初期表示で一覧を1回読むだけ | mount-only effect |
+| フィルタ、ページング、URL パラメータ変更で再取得 | その状態を依存に明示 |
+| loading state 更新で再取得が走る | REJECT |
+| message 表示や dialog 開閉で再取得が走る | REJECT |
+
+## custom hook の責務
+
+React custom hook は「React の state/effect/ref を使う状態遷移」に限定する。純粋計算だけなら custom hook ではなく関数モジュールでよい。
+
+| 基準 | 判定 |
+|------|------|
+| React の state/effect を使わないのに `use*` と命名する | 警告 |
+| 純関数群を custom hook として扱う | 警告 |
+| stateful な UI 制御は custom hook に、純粋計算は function module に分ける | OK |
+| hook が JSX を返す | REJECT |
+
+## exhaustive-deps の扱い
+
+`react-hooks/exhaustive-deps` は無条件で従うものではなく、effect の意味を壊さない範囲で従う。mount-only 初期化で依存を増やすと挙動が壊れる場合は、理由を残して抑制する。
+
+| 基準 | 判定 |
+|------|------|
+| ルールに従うためだけに不要な再実行依存を追加する | REJECT |
+| lint 抑制を無言で入れる | 警告 |
+| mount-only の理由をコメントで説明して抑制する | OK |
+| 再実行が必要な effect なのに `[]` にする | REJECT |

package/builtins/ja/facets/output-contracts/plan-frontend.md

@@ -0,0 +1,41 @@
+```markdown
+# タスク計画
+
+## 元の要求
+{ユーザーの要求をそのまま記載}
+
+## 分析結果
+
+### 目的
+{達成すべきこと}
+
+### 参照資料の調査結果（参照資料がある場合）
+{参照資料の実装アプローチの概要と、現在の実装との主要な差異}
+
+### デザイン要素の判定（デザイン参照がある場合）
+| 要素 | 変更要/不要 | 根拠 |
+|------|-------------|------|
+
+### スコープ
+{影響範囲}
+
+### 検討したアプローチ（設計判断がある場合）
+| アプローチ | 採否 | 理由 |
+|-----------|------|------|
+
+### 実装アプローチ
+{どう進めるか}
+
+## 実装ガイドライン（設計が必要な場合のみ）
+- {Coderが実装時に従うべき指針}
+
+## スコープ外（項目がある場合のみ）
+| 項目 | 除外理由 |
+|------|---------|
+
+デザイン参照がある場合:
+- {除外した要素名と、除外理由・代替しない理由}
+
+## 確認事項（あれば）
+- {不明点や確認が必要な点}
+```

package/builtins/ja/facets/output-contracts/plan.md

@@ -22,6 +22,14 @@
 ### 実装アプローチ
 {どう進めるか}
 
+### 到達経路・起動条件（利用者向け機能の追加/変更がある場合）
+| 項目 | 内容 |
+|------|------|
+| 利用者が到達する入口 | {メニュー/route/ボタン/リンク/外部呼び出し など。なければ「入口なし」と明記} |
+| 更新が必要な呼び出し元・配線 | {更新対象のファイルや層} |
+| 起動条件 | {認証、権限、URL条件、フラグなど} |
+| 未対応項目 | {残っている配線があれば明記。なければ「なし」} |
+
 ## 実装ガイドライン（設計が必要な場合のみ）
 - {Coderが実装時に従うべき指針}
 

package/builtins/ja/facets/policies/coding.md

@@ -204,13 +204,35 @@ return storage.upload(file, options)
 - 50行超のUI/ロジック → 分離
 - 複数の責務がある → 分離
 
+### 機能追加時の到達経路
+
+新しい機能や画面を追加したら、実装と同じ変更セットで利用者が到達する経路も更新する。フレームワーク固有の配線方法は各ドメイン知識に従う。
+
+| 基準 | 判定 |
+|------|------|
+| 新機能の実装だけ追加し、呼び出し側・導線・到達経路の更新を忘れる | REJECT |
+| 利用者がどこから到達するか未定義のまま公開機能を追加する | REJECT |
+| 実装追加と同じ変更セットで導線と到達経路を更新する | OK |
+| 一時導線を追加した場合、その用途と除去条件を記録する | OK |
+
 ### 依存の方向
 
 - 上位層 → 下位層（逆方向禁止）
 - データ取得はルート（View/Controller）で行い、子に渡す
 - 子は親のことを知らない
 
-### 状態管理
+### 実行条件と依存条件の一致
+
+依存やトリガーは、実際にその処理を再実行したい条件と一致させる。静的ルールや実装都合のためだけに依存を増やし、意図しない再実行を起こさない。
+
+| 基準 | 判定 |
+|------|------|
+| lint や実装都合だけで依存やトリガーを増やし、再実行ループを生む | REJECT |
+| 無関係な state 変化や callback 再生成で初期処理が再実行される | REJECT |
+| 再実行条件が URL・フィルタ・明示的更新操作などの仕様に対応している | OK |
+| 初期化と再取得のトリガーを分けて設計している | OK |
+
+## 状態管理
 
 - 状態は使う場所に閉じ込める
 - 子は状態を直接変更しない（イベントを親に通知）

package/builtins/ja/facets/policies/design-planning.md

@@ -0,0 +1,52 @@
+# デザイン計画ポリシー
+
+デザイン参照が指定されている計画では、要素の棚卸しとスコープ判断を曖昧にしない。
+
+## 原則
+
+| 原則 | 基準 |
+|------|------|
+| 参照優先 | デザイン参照がある場合、計画は参照資料を一次情報として扱う |
+| 要素単位の棚卸し | 画面単位ではなく要素単位で差分を確認する |
+| 変更要否の明示 | 各要素について変更要/不要を根拠付きで示す |
+| スコープ外の説明責任 | デザインにある要素を外す場合は除外理由を明示する |
+| 実装境界の明確化 | 実装対象と非対象の境界を計画段階で固定する |
+
+## 適用条件
+
+このポリシーはタスク指示書または参照資料にデザイン参照が含まれている計画に適用する。デザイン参照がない計画には適用しない。
+
+## 判定基準
+
+| 基準 | 判定 |
+|------|------|
+| デザイン参照の主要要素を列挙せず計画している | REJECT |
+| 要素ごとの変更要/不要がない | REJECT |
+| 「今回は一覧のみ」など、要素名なしにスコープを狭めている | REJECT |
+| スコープ外要素の除外理由がない | REJECT |
+| デザイン参照の解釈が曖昧だが、判断根拠を残している | OK |
+
+## 計画時の判断
+
+計画では、デザイン参照に含まれる要素を落とさず棚卸しする。
+
+棚卸し時の観点:
+- 主要セクションだけでなく、詳細導線、モーダル、操作要素、状態表示まで確認する
+- 各要素ごとに、現行実装との差分と変更要否を記録する
+- 既存実装を維持する場合も、対象ファイルと根拠を示す
+
+## スコープ判断
+
+デザイン参照の要素をスコープ外にする場合は、少なくとも以下を計画に残す。
+
+- 除外する要素名
+- 除外理由
+- 今回代替実装を採らない理由
+
+デザイン参照に含まれる要素を、根拠なく「別タスク」とみなして切り離さない。
+
+## 禁止事項
+
+- **画面単位の雑な要約だけで計画すること** - 要素の抜け漏れが発生する
+- **根拠なしに参照資料の意図を狭めること** - 実装とレビューの前提がずれる
+- **スコープ外の説明を省略すること** - 後続ムーブメントで判断不能になる

package/builtins/ja/facets/policies/testing.md

@@ -66,6 +66,37 @@ test('ユーザーが存在しない場合、NotFoundエラーを返す', async
 - Arrange-Act-Assert パターン（Given-When-Then と同義）
 - マジックナンバー・マジックストリングを避ける
 
+## 再取得ループのリグレッション
+
+画面の初期取得がある場合、無関係な再レンダ、loading 切替、Context callback の参照変化で API が再実行されないことをテストで担保する。
+
+| 基準 | 判定 |
+|------|------|
+| 初期取得バグ修正に対し、重複 API 呼び出しの回帰テストがない | REJECT |
+| 1回呼ばれたことだけを確認し、再レンダ後の安定性を見ていない | 警告 |
+| rerender や state 更新後も呼び出し回数が増えないことを検証している | OK |
+
+## 到達経路のリグレッション
+
+利用者向け機能や画面を追加・変更した場合、利用者がその機能へ到達できることをテストまたは同等の検証で担保する。
+
+| 基準 | 判定 |
+|------|------|
+| 新規の画面・機能を追加したのに、到達経路や起動条件の検証がない | REJECT |
+| 画面ファイル単体の描画だけを見て、入口からの到達確認をしていない | 警告 |
+| route、メニュー、ボタン、リンク、外部呼び出しなど実際の入口から対象機能へ到達できることを確認している | OK |
+
+## UIライブラリ統合のリグレッション
+
+DataGrid、日付ピッカー、仮想リスト、チャートなど、外部 UI ライブラリの主要コンポーネントを導入・変更した場合は、実コンポーネントをマウントするテストでクラッシュしないことを担保する。
+
+| 基準 | 判定 |
+|------|------|
+| 外部 UI ライブラリの主要コンポーネントを追加・変更したのに、実マウントの回帰テストがない | REJECT |
+| ライブラリの props 整合性を、浅いモックや存在確認だけで済ませている | 警告 |
+| route から対象画面を描画し、主要 UI が例外なくマウントされることを確認している | OK |
+| 主要 UI コンポーネント単体でも、代表的な props で実 render している | OK |
+
 ## テスト戦略
 
 - ロジックにはユニットテスト、境界にはインテグレーションテストを優先

package/builtins/ja/pieces/dual-cqrs-mini.yaml

@@ -25,6 +25,8 @@ movements:
   - name: plan
     edit: false
     persona: planner
+    policy:
+      - design-planning
     knowledge:
       - frontend
       - backend
@@ -51,7 +53,7 @@ movements:
     output_contracts:
       report:
         - name: plan.md
-          format: plan
+          format: plan-frontend
   - name: implement
     edit: true
     persona: coder

package/builtins/ja/pieces/dual-cqrs.yaml

@@ -37,6 +37,8 @@ movements:
   - name: plan
     edit: false
     persona: planner
+    policy:
+      - design-planning
     knowledge:
       - frontend
       - backend
@@ -60,7 +62,7 @@ movements:
     output_contracts:
       report:
         - name: plan.md
-          format: plan
+          format: plan-frontend
   - name: implement
     edit: true
     persona: coder

package/builtins/ja/pieces/dual-mini.yaml

@@ -25,6 +25,8 @@ movements:
   - name: plan
     edit: false
     persona: planner
+    policy:
+      - design-planning
     knowledge:
       - frontend
       - backend
@@ -50,7 +52,7 @@ movements:
     output_contracts:
       report:
         - name: plan.md
-          format: plan
+          format: plan-frontend
   - name: implement
     edit: true
     persona: coder

package/builtins/ja/pieces/dual.yaml

@@ -37,6 +37,8 @@ movements:
   - name: plan
     edit: false
     persona: planner
+    policy:
+      - design-planning
     knowledge:
       - frontend
       - backend
@@ -63,7 +65,7 @@ movements:
     output_contracts:
       report:
         - name: plan.md
-          format: plan
+          format: plan-frontend
   - name: write_tests
     edit: true
     persona: coder

package/builtins/ja/pieces/frontend-mini.yaml

@@ -25,6 +25,8 @@ movements:
   - name: plan
     edit: false
     persona: planner
+    policy:
+      - design-planning
     knowledge:
       - frontend
       - security
@@ -49,7 +51,7 @@ movements:
     output_contracts:
       report:
         - name: plan.md
-          format: plan
+          format: plan-frontend
   - name: implement
     edit: true
     persona: coder

package/builtins/ja/pieces/frontend.yaml

@@ -37,8 +37,11 @@ movements:
   - name: plan
     edit: false
     persona: planner
+    policy:
+      - design-planning
     knowledge:
       - frontend
+      - react
       - architecture
     provider_options:
       claude:
@@ -58,7 +61,7 @@ movements:
     output_contracts:
       report:
         - name: plan.md
-          format: plan
+          format: plan-frontend
   - name: write_tests
     edit: true
     persona: coder
@@ -67,6 +70,7 @@ movements:
       - testing
     knowledge:
       - frontend
+      - react
       - architecture
       - unit-testing
       - e2e-testing
@@ -110,6 +114,7 @@ movements:
     session: refresh
     knowledge:
       - frontend
+      - react
       - security
       - architecture
     provider_options:
@@ -175,6 +180,7 @@ movements:
     session: refresh
     knowledge:
       - frontend
+      - react
       - security
       - architecture
     provider_options:
@@ -222,6 +228,7 @@ movements:
         knowledge:
           - architecture
           - frontend
+          - react
         provider_options:
           claude:
             allowed_tools:
@@ -244,7 +251,9 @@ movements:
         policy:
           - review
           - design-fidelity
-        knowledge: frontend
+        knowledge:
+          - frontend
+          - react
         provider_options:
           claude:
             allowed_tools:
@@ -350,6 +359,7 @@ movements:
       - design-fidelity
     knowledge:
       - frontend
+      - react
       - security
       - architecture
     provider_options:
@@ -406,6 +416,7 @@ movements:
       - design-fidelity
     knowledge:
       - frontend
+      - react
       - security
       - architecture
     provider_options:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "takt",
-  "version": "0.32.1",
+  "version": "0.32.2",
   "description": "TAKT: TAKT Agent Koordination Topology - AI Agent Piece Orchestration",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
@@ -63,7 +63,7 @@
   ],
   "dependencies": {
     "@anthropic-ai/claude-agent-sdk": "^0.2.71",
-    "@openai/codex-sdk": "^0.112.0",
+    "@openai/codex-sdk": "^0.114.0",
     "@opencode-ai/sdk": ">=1.2.10 <1.3.0",
     "chalk": "^5.3.0",
     "commander": "^12.1.0",