配布資料の目次 › 再現環境 Keihi
配布資料 64Keihi 実装フェーズ計画
status: active / 事前に作ってある範囲と、読み手が実装する範囲の切り分け。全5部へのマッピング。
実装順序の原則
データを作る機能を先に、閲覧・消費する機能を後に。
シードデータに頼らず、実際の操作でテストデータを作れるようにするためです。 題材プロジェクトからそのまま移植した原則です。
Phase 分割
| Phase | 内容 | 誰が作るか |
|---|---|---|
| 0 | 基盤: Docker 構成・Prisma スキーマ・3アクター認証・CLAUDE.md/hooks/rules 一式 | 事前構築 |
| 1 | 申請作成系: 費目マスタ・申請 CRUD・明細・上限チェック（S-02〜S-04） | 事前構築（第1部 で起動・観察する） |
| 2 | 承認フロー: 承認待ち一覧・承認・差戻し（A-02〜A-03） | 差戻し機能は未実装で残してある。 第3部で通し実装する対象 |
| 3 | 支払・集計: 支払処理・月次締め（F-02〜F-03） | 事前構築 |
| X | 大規模仕様変更: 2段階承認 + 代理申請 | 第2部で exploration 文書だけ作る（実装はしない） |
全5部へのマッピング
| 部 | Keihi の使い方（再現手順=手元で実行できる操作 / 演習=自分で判断する課題） |
|---|---|
| 1 | 再現手順: 環境起動 → 3ロールでログイン・一巡操作。演習: CLAUDE.md を読み解く |
| 2 | 再現手順: 要件のイシュー化。演習: ギャップ分析（画面一覧との突合）・Phase X の exploration 文書レビュー |
| 3 | 再現手順: 差戻し機能を検証の階段フルコースで通し実装（イシュー起票→ブランチ→実装→tsc→単体（成分別）→Docker→ブラウザ検証3点セット→PR→通常マージ）。演習: 完了判定（「これで完了と言えるか」）+ 実地検分（何を確認すれば「動いている」と言えるかを自分で決める） |
| 4 | 再現手順: フックを外した状態で事故を起こす → hook をその場で書く → 有効化して事故が止まることを確認。演習: 「hook で止められる失敗/止められない失敗」の分類 |
| 5 | 再現手順: バッチデプロイ（ローカル staging 相当への一括反映）。演習: 自PJ移植計画書の作成（ツール不要・紙とテンプレートで書ける） |
第3部の通し実装、その完了定義
検証の階段をそのまま完了定義にしてあります。全部埋まるまで「完了」と言いません。
- イシュー起票・In Progress 化
- 最新 master からブランチ作成
- 差戻し API（理由必須・状態遷移ガード・履歴記録）+ 画面（理由入力モーダル・インラインバナー表示）
- tsc エラーゼロ / 単体テスト（拒否・許可の両ケース + 理由未入力エラー）/ Docker healthy
- ブラウザ検証3点セット（目視・スクショ・DOM 引用）: 提出→差戻し→修正→再申請→承認の一巡
- PR 作成 → 通常マージ → イシューコメント → Done
どう作ったか
- 構築自体を Claude Code で行っています。「このリポジトリもこの手法で作られた」という再帰構造をそのまま見せるためです
- hooks は題材プロジェクトの24本から6本を選んで移植しました。本番ガード相当（デモ用）・マージ前チェックリスト・ブラウザテストフラグ・テーマトークン検査（簡易版）・タスクモード判定と編集ガードの対です
- 実際に動いているフックのソース全文はフックの実物にあります。読んでから自分のプロジェクト用に書き換えてください