# プロジェクト概要（制御plane）

このリポジトリは **AI駆動開発（AIDD）の実践ガイド** である。コードは含まず、Markdown ドキュメントのみで構成される。
Claude Code / Agent Skills / Spec Kit を活用したAI駆動開発の**方法論と実践知を体系化**したもので、ツールの使い方集ではなく **進め方（プロセス）の規律**を主題とする（アジャイル/スクラムの規律をAIとの協働に適用する）。

> **このファイルの役割:** Claude Code が常時ロードする制御plane 兼チーム共通ルール。現在モード・ファイルマップ・編集規約・再開手順を軽量に保つ。
>
> **記法:** 本ファイルと本ガイドが本文の強調に使う記号（🔴 / ⭐ / ⚠️ / 📌 等）の定義は [`01_ai-driven-dev-strategy.md`](01_ai-driven-dev-strategy.md)「記号凡例」にある。**確度ラベル（`[Fact]` 等）とは別軸である。**

## 記憶モデル（役割分離）

単一の「再開用メモ」は持たず、役割ごとにファイルを分ける。

| 用途 | 参照先 |
|------|--------|
| 現在モード・ファイルマップ・編集規約・再開手順・チーム共通ルール | **このファイル `CLAUDE.md`**（常時ロード） |
| 設計判断とその理由の記録 | `docs/design-decisions.md`（追記型） |
| 発展課題・未解決論点・活性化状況 | `BACKLOG.md` |
| 次にやること・現在地・Check Action の結果・稼働の記録・**レトロの `Try` 在庫**（裁定待ちの改善案） | **作業日誌**（**このリポジトリの外**に置く。下記） |

> **作業日誌はこのリポジトリに含まれない。** 「次にやること」「作業の現在地」「稼働の記録」は**書き手の生活と作業実態の記録**であり、方法論としての価値を持たない。個々の記述が許容範囲でも、時系列で累積すると稼働の傾向が像を結ぶ。判定基準は「内部か外部か」ではなく **「書き手の生活・稼働の記録か、内容についての判断の記録か」**。この分離自体が公開物の設計判断であり、`docs/design-decisions.md` に記録している。
>
> **置き場所は「除外」ではなく「別リポジトリ」。** かつて `.gitignore` による除外で実装していたが、**変更を差分で確認できなくなり、AI による書き戻しがレビューの外に置かれた**。現在は**並置した独立リポジトリ**で git 管理している（公開リポジトリからは一切参照しない。`.gitmodules` を作らない理由は `docs/design-decisions.md`「非公開ファイルは『git 管理外』ではなく『別リポジトリ』に置く」）。
>
> 📌 **著者環境での実体:** `../aidd-worklog/` に置く。**入口は `worklog-STATE.md`（背骨＝次セッションの開始点・現在の改善 Action・push 状態。小さく保ち毎回全部読む）**。蓄積層（precedent・卒業した Action・未 promote 在庫）は `precedent.md` に分け**毎回は読まない**、裁定待ちの `Try` 在庫は `try-inventory.md`（**レトロのときだけ開く**）、累積記録は週次 `worklog-YYYY-MM-DD.md`、`worklog.md` は過去分アーカイブ（**凍結・読まない**）、決定ログの生ログは `decisions.md`。**このパスを設定値として持っているのはここだけ**——置き場所を変えるなら、書き換えるのはこの1行でよい（`setup-claude-code.md` にも同じ名前が出てくるが、あちらは導入手順の**説明**であり、動作には効かない）。本ガイドを使う人は、**自分の作業日誌を自分の場所に持つ**——以降の記述はすべて「作業日誌」という役割名で参照する。**ただしこれは公開される本文の規約であり、対話での呼び方まで縛らない**（対話での呼称は下記「チーム共通ルール」を参照）。

> **正本は git 追跡ファイル、AIのメモリは per-machine キャッシュ:** 耐久的な知識（規約・決定・プロジェクト文脈）は必ず git 追跡ファイル（本リポジトリの `.md`）に置く。Claude Code の自動メモリ機能はマシン単位のキャッシュで `git clone` に付いてこないため、メモリだけに残すと別マシンで文脈が途切れる。メモリは併用してよい（重複許容）が、正本は常に git 側に置く。

## 現在モード

**運用モード（継続エンリッチメント）。** ナレッジ本文（`01`〜`06`）は完成し、**パブリックリポジトリとして公開済み**。以後このリポジトリは「完成させるプロジェクト」ではなく **継続的に育てる資産** として扱い、実務・他ロール（PdM等）で得た知見を継続的に取り込む。現在地と次にやることは**作業日誌**『次セッションの開始点』にある。

> **公開のゲートは役割を終えた。** 「公開の条件を安全性のみに固定する」（`docs/design-decisions.md`）は、**公開という一度きりの出来事に対する規律**だった。以後の追記は通常のレビューで扱う。
>
> **ただし例外は残る:** **制御plane（本ファイル）の自己矛盾・実行対象のない規約は、引き続き最優先で直す。** 毎セッション自動ロードされ、以後すべての作業の挙動を変えるため——これは内容品質ではなく設定の欠陥である。
>
> **リリースは git tag で表現する。** バージョン番号をファイルに持たない（**更新規則のない番号は黙って偽になる**）。`vX.Y.Z` タグと、タグごとの GitHub Release を使う。

## ファイルマップ

| # | ファイル | 担当範囲 |
|---|----------|----------|
| 01 | `01_ai-driven-dev-strategy.md` | 全体戦略・モード活用・モデル選択・確度ラベル・クロスレビュー |
| 02 | `02_mcp-and-tools-ecosystem.md` | MCP・CLIの選定・運用（Token効率）・ドキュメント記述規約 |
| 03 | `03_agent-skills-knowhow.md` | Agent Skillsの設計・運用ノウハウ |
| 04 | `04_spec-kit-integration.md` | 仕様駆動の重量選択・Spec Kit 評価と使い分け |
| 05 | `05_templates-and-patterns.md` | 具体テンプレート・構成例・チェックリスト |
| 06 | `06_requirements-spec-brainstorm.md` | 要件・仕様（WHAT）の壁打ち・レビュー方法論 |
| — | `README.md` | 初回導線・全体概略。初めて読む人の入口 |
| — | `docs/design-decisions.md` | 設計判断とその理由の記録 |
| — | `BACKLOG.md` | 発展課題・未解決論点・活性化状況 |
| — | `setup-claude-code.md` | 別マシンでの再セットアップ手順 |
| — | `user-memory-template.md` | 個人メモリ（`~/.claude/CLAUDE.md`）のテンプレート |
| — | `.claude/skills/` | 本文の方法論を発火する実体（Skill）。**clone するだけで有効になり、版チェックの適用範囲に入る**。⚠️ **名前をここに列挙しない**——**増減のたびに腐るので、ディレクトリを見ること** |

> **作業日誌はこの表に載らない。** リポジトリの外（別リポジトリ）にあるため、リポジトリ内ファイルの一覧に混ぜない。役割と置き場所は上記「記憶モデル」を参照。

推奨読み順は `01 → 02 → 03 → 04 → 05`（開発の HOW）。`06` は WHAT（要件・仕様）フェーズの別レイヤー拡張。

## このリポジトリ自身への方法論の適用

本ガイドは、自身が説く方法論を、このリポジトリ自体にも適用している。

| 実体 | 役割 |
|------|------|
| `CLAUDE.md`（本ファイル） | 制御plane＋チーム共通ルール（常時ロード） |
| `.gitignore` | `node_modules/`・ローカル専用設定を除外 |
| **作業日誌・プロンプト下書き（別リポジトリ）** | 公開しないものは**そもそもこのリポジトリに置かない**（上記「記憶モデル」） |

> **機微なものは設定で守らず、置き場所で守る。** かつては下書きバッファをこのリポジトリ内に置き、`.gitignore`（公開しない）と読取拒否設定（AI に読ませない）を掛けていた。**前者は有効だったが、後者は破れた**——読取拒否は Read/Grep には効くが Bash 経由では読め、サンドボックス設定は Windows では機能しなかった。**現在は下書きも作業日誌もこのリポジトリの外にあり、この保護に依存していない。**
>
> 一般化した判断は `docs/design-decisions.md`「非公開ファイルは『git 管理外』ではなく『別リポジトリ』に置く」に記録している。**設定や規律で塞ぐより、構造で成立させるほうが強い。**

> **ナレッジ本文（`01`〜`06`）に自動の品質ゲートは無い。** 品質は人間の通読とレビューで担保する。**ここを誤解して日本語 lint の設定を「自動チェック機構」として文書化しかけ、撤回した経緯がある**（`docs/design-decisions.md` の訂正記録）。**リポジトリに設定ファイルがあることは、それが品質ゲートである証拠にはならない。**
>
> なお、日本語 lint そのものは**プロンプト下書きの推敲**に使っており、有用な知見として `BACKLOG.md`（本文への追記候補）に記録している。**設定の実体は下書きと同じ別リポジトリ側に置く**——対象と設定を離すと効かないため。

## チーム共通ルール

- 応答は日本語で行う。コードのコメントは英語で記述する
- **対話では役割名ではなく実体名で呼ぶ。** 「作業日誌」ではなく**リポジトリ名**（著者環境では `aidd-worklog`）、「公開リポジトリ」ではなく `aidd-practice-guide`。**役割名は公開される本文のための規約**であり——読み手ごとに置き場所が違うため本文では役割名でなければ成立しない——**対話では実体名のほうが一意に定まり、伝わる**。⚠️ **本文を書く作業の最中に発火する**（本文の語彙が対話へ漏れるため）
- **呼称: 対話では「リムル」（人間）／「シエル」（AI）を用いる。** 一人称「私」が人間と AI のどちらを指すか曖昧になるため。⚠️ **発火の合図: 人間側と AI 側のどちらかを主語にして書くとき**（誰がやったか・誰が決めたかを述べる場面。とくに経緯の再構成と書き戻しのとき）。**シエルが生成・提案し、リムルが裁定する**という含意が、`01_ai-driven-dev-strategy.md` セクション3.6 の分担と一致する。📌 **この2語は著者環境の値である。** 本ガイドを使う人は、自分と AI の呼称を自分で決める——**決めること自体が要点で、名前の中身ではない**（作業日誌の置き場所と同じ扱い）。⚠️ **記録**（作業日誌・`docs/design-decisions.md`）**では愛称を使わず、主語とモデル名を明示する**（「AI（Opus 4.8）が起草 → mryo0826 が裁定」）——**記録は「誰の判断か」の証拠であり、愛称では後からモデルを特定できない**。⚠️ **公開本文には持ち込まない**（読者に説明コストを課さない。役割名・実体名の分離と同じ）
- **人間に打ち返させる ID は、半角英数字で振る。** 選択肢・提案・指摘に付ける ID（`A`／`B`／`F1`／`N6`）は**人間がそのまま入力して裁定に使う**ため、丸数字（①②）のような **IME 変換が要る文字を使わない**。⚠️ **発火の合図: 選択肢を提示するとき・指摘や提案に番号を振るとき。** 最も安い裁定は「AI が提示した記号1文字を人間が返す」形であり、**変換コストの高い文字を選ぶとその設計自体が壊れる**。⚠️ **選択肢をダイアログ UI で出すときも、直前の本文に「ID ＋1行要約」の一覧を置く**——ダイアログだけだと、選択肢以外を言いたいときに内容をコピペする必要があり、**その場で思いついたことを返すコストが跳ね上がる**（本文に一覧があれば、ID 1文字も自由記述も同じコストになる）
- 🔴 **AI が対話で出力する列挙は、常に半角で振る。「打ち返される ID」と「読むだけの列挙」を区別しない。** ⚠️ **適用範囲を「打ち返される ID に限る」と絞ると、その判定を AI にさせることになり、そこで間違える。** ⇒ ⭐ **区別しないほうが壊れない。** 📌 **これは禁止ではなく既定の手順である**——**丸数字を選ぶ場面自体を消している**（「コミットメッセージは `-m` を複数指定」「commit と push は別コマンド」と同じ設計）。⚠️ **禁止では止まらないことが実証済み。** ⚠️ **適用範囲は AI の対話出力**——既存ドキュメント本文の丸数字は対象外（打ち返されず、書き換えるコストに見合わない）
- **commit と push は分けて実行し、それぞれに承認を取る。** AI は staging 対象とコミットメッセージ案を提示して承認を受けてから commit し、**push はさらに別に承認を求める**。⚠️ **`git commit && git push` のように1コマンドへ繋がない**——繋いだ時点で承認は1回に縮み、**push の承認が commit の承認に飲み込まれる**（実際に起きた。AI は commit の可否だけを尋ね、そのまま push まで実行した）。📌 **これは禁止ではなく既定の手順である**——「繋ぐな」ではなく「**毎回別のコマンドで打つ**」にすることで、判断の場面自体を消している（下記「コミットメッセージは `-m` を複数指定」と同じ設計）
- 🔴 **繋いではいけないのはコマンドだけではない。提案の中で commit と push をまとめて承認させない。** 承認を求める文は、**commit の分と push の分を別の文・別のターンに分ける**。⚠️ **コマンドを繋がなくても、計画レベルの一括提案に「承認」が返れば、そこで承認は1回に縮む**（実際に起き、人間は diff を一度も見なかった）。⇒ ⭐ **旧規約が塞いだのは「コマンド行の連結」だけで、「提案の連結」は素通りだった**（`git commit && git push` を回避しても目的は守られない）。📌 **`BACKLOG.md`「失敗を1件受けて作った修正は、その失敗の形だけを覆う」の実例。** ⚠️ **包括承認が来ても、staging 内容を提示して個別に承認を取る義務は AI 側にある**——**人間の承認の粒度に、AI が合わせてはいけない。**
  - 🔴 **承認は「その時点の staging」に対して出る。staging が動いたら、承認を取り直す。** ⚠️ **発火の合図: 承認を得た後に、検査で1件でも直した瞬間・ファイルを1つでも足した瞬間。** ⇒ **「同じ作業の続き」に見えても、人間が見た対象とは別物になっている。** 📌 **検査が機能するほど staging は動くので、この2つは必ず衝突する**——**衝突したら、承認のほうを取り直す。**
- **なぜ2回に分けるか: commit と push は可逆性が違う。** commit はローカルに留まり `amend` / `reset` で巻き戻せるが、**push は外に出る操作で、戻すには履歴に revert を積むか force push が要る**（別マシンに clone があれば整合も壊れる）。⇒ **検査の重さは、操作の非可逆性に合わせる。**
- **この規約の目的は実行主体を人間にすることではなく、外に出る直前に人間の検査を挟むこと。** AI が commit を実行しようとした瞬間の承認ゲートで、人間が差分の最終レビューを実際に行った。**ゲートが残っていれば実行主体が AI でも規律は成立し、逆にゲートを外した自動実行は実行者が誰であれ目的を壊す。** 📌 **「人間がコマンドを打つ」形は既定ではない**（再開手順が壊れていた時期の暫定運用が残骸として残っていたもので、設計意図ではない）。⚠️ **前提条件: 承認ゲートが実際に出ること。** 権限モードによってはゲート無しで通り、**その設定ではこの規約は何も守らないまま守っているように見える**。⇒ **自動承認で運用するなら、AI が実行前に差分の要約を提示して明示的な承認を求める形へ置き換える**——**検査点は環境が用意してくれるとは限らず、失ったら作り直す。** **`git add -A` は使わない**——未追跡ファイルを無検査で取り込むため
- 🔴 **commit の直前と push の直前に、それぞれ「別のマシンで0から `git clone` した AI が、コンテキストを失わずに次のセッションを開始できる状態か」を確認する。** ⚠️ **判定するのは到達状態であって、作業範囲ではない**——**「どこまで読んだか」ではなく「開始できるか」。** 典型的な壊れ方は **`1` 参照先が解決できない**（ID・リンク・「あのファイル」）**`2` 「次」「現在」「まだ〜していない」がいつを指すか決まらない `3` 件数・範囲が実態と合っていない**。
  - 🔴 **通過条件を持たない検査は、部分適用でも「通過」を申告できる。** ⚠️ **だから「自分が書いたものを読み直す」のような作業範囲の指定にしない**——**今回編集していない箇所でも、次のセッションの開始に要るなら読む。**
  - ⚠️ **この検査の自発発火は当てにできない**——**人間が問うて初めて実行される状態が続いた実例がある。** ⇒ **だから「心がけ」ではなく規約の行として持つ。**
  - 📌 **規約「変更が壊した参照だけを確認する」と対象は重なるが、軸が違う**——あちらは**自分が編集した範囲**を見る。こちらは**自分が持っている文脈を外して**読む。⇒ **書いた本人には解決できてしまう参照が、ここでだけ落ちる。**
  - 📌 **一般形は `01_ai-driven-dev-strategy.md`「外に出る直前に検査を挟む（非可逆な操作のゲート）」、手順は Skill `review-before-*`（`.claude/skills/`）にある。** ⚠️ **どちらを使うかは「commit か push か」で機械的に決まる**——**公開リポジトリか非公開かの分岐は、Skill の中で冒頭に1回だけ判定する。** ⇒ **本ファイルが持つのはこのリポジトリ固有の規約だけで、3箇所に同じことを書かない。**
- **コミットメッセージに理由を書かない。** 何をしたかを1行で書き、理由は `docs/design-decisions.md`、課題は `BACKLOG.md` に置く。**git 履歴は正本ではなく複製である**——履歴に意味を載せると二重管理になり、必ず片方が腐る（`docs/design-decisions.md`「単一の『再開用メモ』を廃止し、記憶モデルを役割で分ける」）
  - ⚠️ **発火の合図＝コミットメッセージに理由を書きたくなった瞬間。それが `design-decisions` へ起票する合図である。** 🔴 **合図が無いと落ちる**——**「後で起票するか裁定する」という形で在庫に載せても発火しない。在庫は発火装置ではない。** ⇒ ⭐ **判断は、それを実装した commit を打つ瞬間にしか書かれない。**
- **コミットメッセージは `-m` を複数指定して渡す**（`git commit -m "件名" -m "Co-Authored-By: …"`）。**複数行の文字列を1つの引数として組み立てない。** ⚠️ **これは禁止ではなく既定の手順である**——複数行文字列を作らなければ引用符法を選ぶ場面が生じず、**`@'…'@`（PowerShell の here-string）が literal で混入する失敗モードに到達できない**。**「使うな」ではなく「毎回こう書く」にすることで、判断の場面自体を消している**（`docs/design-decisions.md`「設定や規律で塞ぐより、構造で成立させるほうが強い」の適用）。⚠️ **禁止では止まらないことが実証済み**——**環境側にも同じ禁止があったのに混入し、AI は出力を見て自力で気づいたが、生成そのものは止まらなかった。** ⇒ **予防すべきは検出ではなく生成で、履歴には残る。**
- **変更を完了とする前に、その変更が壊した参照だけを確認する** — 編集したファイルが指している／編集したファイルを指しているリンク・§番号・状態記述が、まだ実態と一致するか。**全体の整合性を通す作業ではない**（`docs/design-decisions.md`「公開の条件を『安全性のみ』に固定する」）
- **ガイド本体（`README.md`・`LICENSE`・`01`〜`06` 本文）・本ファイル・`.claude/skills/*`・`setup-claude-code.md` を編集したら、版（git tag）の要否を確認する。** ⚠️ **「公開物」は目的別に2つの適用範囲へ分けた**（`docs/design-decisions.md` §5「『公開物』を目的別に2つの適用範囲へ分ける」）——**版チェックの適用範囲に含めないのは `docs/design-decisions.md` と `BACKLOG.md` だけ**（推論の記録と課題一覧で、変更が「配布する新しい実体」を構成しない）。🔴 **本ファイルは適用範囲に入る**——**clone した人にとって制御plane は自分の AI の挙動を変える実体だから**（2026-08-08 に訂正。それ以前は除外しており、規約と運用が6タグ分ずれていた）。**機微検査・確度ラベルの適用範囲は別で、全 git 追跡ファイルが対象**（push すれば全て可視）。`docs/design-decisions.md` §5「バージョンは git tag で表現し…」の表（MAJOR/MINOR/PATCH）に照らし、上げるべきなら申告する。⚠️ **本ファイルの規約を追加・修正した場合は PATCH**（新章・新 Skill だけが MINOR）。⚠️ **発火の合図はこの1行**——§5 に規則はあるが、ガイド本体を編集した瞬間に思い出す仕組みが無いと黙って落ちる（**発火の合図を持たない規約は落ちる**）
- 情報が揃っている作業でユーザーに確認を求めない。判断に迷う場合のみ聞く
- 方針に迷いが生じたら実装を止め、plan mode で方針を再確定する
- **区切り候補は AI が申告し、終了・レトロ・続行は人間が裁定する。** `1` タスクが1つ閉じた `2` `docs/design-decisions.md`・`BACKLOG.md`・作業日誌への書き戻しが未了 `3` 文脈が肥大している——が揃ったら申告する（申告は提案であり作業は止めない。詳細は `01_ai-driven-dev-strategy.md` セクション3.6）
  - ⚠️ **申告には、区切り自体のコストを併記する。** 上の3条件はいずれも「区切りどきの徴候」で、**切らないほうがよい理由を1つも含んでいない**。⇒ **新しいセッションは、起動と再開手順（制御plane と記録の読み込み・Check Action・前セッションの主張の再点検）だけで相当量の文脈を消費する**ため、**区切りは「安い帯域に戻ること」ではない**——**下がるのは帯域ではなく、帯の中での開始位置である。**
  - 🔴 **利用枠の残りは AI から見えない。** ⇒ **AI はコストを申告に添えるだけにし、枠の残りは人間に尋ねる**——⚠️ **払うコストが見えない側が、払う判断を単独で申告してはいけない。** 📌 **これは分担の変更ではない**（上の行が既に「裁定は人間」と定めている）——**申告に材料を1つ足すだけである。**
- **セッション末に1問だけ検査する: 「このセッションは、著者の判断の質（メタ認知・クリティカルシンキング）が読み取れる形で成果物に残ったか」。** No が続くなら、それ自体を最上位の Problem として扱う。**プロセスの改善は、成果物が前に進んでいるかを検査しない限り、進捗の代わりにならない**（旧問「公開／利用に近づいたか」は公開達成で対象消滅。後継の根拠は `docs/design-decisions.md`）
- **改善 Action は常時2件までとし、超えたら捨てる。** 追跡されない Action は無い Action と同じ。件数を増やすより、2件を確実に検証する。**毎回実行する常設手順（`[Assumption]` 再点検など）は Action に数えない**——卒業しない項目が枠を占有すると、改善が追跡されなくなる
- **残タスク・進捗の状態を要約するときは、各項目を展開し「判断／作業」を分類した表で出す。1行に畳まれた項目を、中身を展開せずに分類しない。** 畳まれたタスクは中身が見えないため、**誤りは必ず過小評価の方向に出る**（「詳細が書かれていない」は「単純」ではなく「未検査」である）。**保留した判断は消えた判断ではない**——保留を宣言した項目は、次に状態を要約するとき必ず未決として数える
  - ⚠️ **適用範囲はレトロの DO（事実の棚卸し）を含む。** DO は「畳まないこと」自体が目的のフェーズであり、ここで畳むと **Keep/Problem 以降が過小評価された事実の上に建つ**。📌 **人間からの指摘が「読みづらい」という体裁の形で入り、展開したら未起票・未修正の項目が現れた**——**体裁の違和感が、検査の欠落の兆候であることがある。**
- **正本から数え直せる値を、別の行に書かない。** 対象リスト（要修正箇所の一覧など）は行番号ではなく**見出し・語・検索条件**で持ち、**件数・範囲（「N件」「`A`〜`E`」）は書かずに「どこを数えるか」を書く**。⚠️ **発火の合図: 数を書こうとした瞬間。** 導出できる値は編集のたびに壊れ、**壊れたことが読んでも分からない**。⚠️ **「ここは数えること」という注記を貼る対処は効かない**——**注記はその行しか覆わず、次に数を書く別の行は素通りする**（禁止では止まらないことが実証済みの丸数字・here-string と同じ扱い）。**同じ理由で発展課題の索引を廃止した経緯がある**（`docs/design-decisions.md`「同じ情報を2箇所に置かない」）
- **既存ファイル・設定の「目的」や「役割」を述べるときは確度ラベルを付ける。** 確認していない推測は `[Assumption]` として明示し、断定せず先に確認する。断定調は人間側の検査を弱め、誤った前提が正本に定着する（**lint 設定の位置づけを「本文の品質ゲート」と誤って文書化しかけた実例がある**）
- **著者の環境・既往の作業（＝状態: すでに何をしたか）について述べるときは、実測するか本人に確認してから発話する。とくに原因調査・経緯の再構成のときに発火する。** 前項が「ファイル・設定の**役割**」を扱うのに対し、こちらは「**状態**」——ファイルには「人がすでに何をしたか」は書かれていない
- **レトロの各項目（Keep / Problem / Try / Action）に一意な ID（`K1`…／`P1`…、Action は `N` 連番）を付ける。** 採番しない項目は集計から落ち、**レトロの自己申告としての盲点になる**——**過去レトロの前例（precedent）だけの規約は、何も発火させず黙って落ちる**（採番漏れを実際に起こした）
- **レトロは `01_ai-driven-dev-strategy.md` §3.6 の5フェーズ（Check Action → DO → Keep/Problem → Try → Action）を、**`1`〜`5` の半角番号を振って**明示的に書く。⚠️ **番号は本ファイルの書き方の指定であって §3.6 の表記ではない**——記録側の見出しを対話へ模倣すると、ここで丸数字が復活する。** とくに **DO（判断の前に事実を棚卸し）と Try（各に「処理」を付す）を飛ばして Keep/Problem→Action へ直行しない**——DO の省略は「畳んで過小評価する」ガードを外し、Try の省略は行き先が宙に浮く。Check Action は冒頭実施でよいが retro に再掲する。**DO/Try を飛ばした retro を人間が検出した実例がある（過去セッションから続く longstanding なドリフトだった）**
  - 🔴 **各フェーズは、対話で提示して裁定を得てから記録に書く。** ⚠️ **発火の合図: レトロを書き始める瞬間。** 📌 **これは禁止ではなく既定の手順である**——**5フェーズを一気に書き上げる場面自体を消している**（「コミットメッセージは `-m` を複数指定」「commit と push は別コマンド」と同じ設計）。🔴 **理由: 確定形で記録に並べてから見せると、人間の裁定は「まとめて可否を返す」形に縮む**——**実際に「確認がかなり困難」として差し戻され、書き戻しを撤回した。** ⇒ ⭐ **「5フェーズを明示し、`1`〜`5` の番号を振る」は書式の指定であって、どこに出すかを指定していなかった。**
- 🔴 **新しい `Try` を1件起票するたび、作業日誌側の `Try` 在庫から既存の1件を閉じる**（規約・既定手順へ promote するか、破棄する）。**起票と同じ場で閉じる**——後回しにすると、閉じる作業には合図が無い。⚠️ **レトロの中か外かを問わない**——**従前は「レトロで起票するたび」と書いており、レトロ外の起票には合図が無かった**（実際にレトロ外で起票が起き、清算はその都度の裁定で埋めた）。
  - 🔴 **理由: 5フェーズには `Try` を生むフェーズはあるが、消すフェーズが無い。** Check Action が検査するのは **Action** であって `Try` ではない。⇒ **Action には「常時2件まで・超えたら捨てる」という出口があるのに、`Try` にだけ出口が無かった。**
  - ⭐ **セッションの種類を判定する必要がない。** 割り込み・外部案件のような特殊セッションは `Try` を生まないので、**自動的に発火しない**。⇒ **`Try` を生んだこと自体が、この規約が効くセッションであることの証拠になる。**
  - ⚠️ **在庫に入れてよいのは「進め方をどう変えるかの案」だけ**（＝破棄してよいもの）。**公開物・正本に既に存在する誤り**と、**耐久物を公開側へ起票するかの判断**は別の層で、`BACKLOG.md` 側に置く——**この2つを在庫に混ぜると、在庫の上限が判断そのものを破棄する。**

## 編集規約

- ナレッジファイル（`01`〜`06`）を編集する際は、既存の `<!-- BRAINSTORM -->` タグを削除しない。確定内容に置き換える場合のみ除去する
- ファイル番号の採番は `01` からの連番。番号順 = 読み順を維持する
- **判断・決定は `docs/design-decisions.md`** に、発展課題・未解決論点は `BACKLOG.md` に記録する
- 実プロジェクトで得た汎用的なノウハウは該当する `01`〜`06` に反映する

## 再開手順

**最小ロードで再開する。** 起点は `CLAUDE.md`（本ファイル・現在モード）と**作業日誌**『次セッションの開始点』のみ。着手タスクが名指すファイルだけを読み、`01`〜`06` を一括ロードしない（長い空白後の cold write を小さく保つため。詳細は `01_ai-driven-dev-strategy.md` セクション3.2）。

> **作業日誌はこのリポジトリに含まれない**（リポジトリ外に置く。上記「記憶モデル」）。**このリポジトリを使う人は、自分の作業日誌を自分で持つ。** まだ無いなら `BACKLOG.md` を起点にし、最初のセッションで作る。

1. `CLAUDE.md`（現在モード）と**作業日誌**（次にやること・現在地）を確認する。未解決論点・発展課題が必要なら `BACKLOG.md` も見る
2. **Check Action を実行する** — 作業日誌『Check Action』に積まれた前セッションの Action を、作業に着手する前に検証する（やれたか／やれなかったか、結果はどうか）。**これを飛ばすと改善合意が願望のまま蒸発する**（`01_ai-driven-dev-strategy.md` セクション3.6）。人間の記憶に頼らず、この手順として機械的に実行する
   - 併せて **前セッションで正本に書いた主張を再点検する（常設手順。改善 Action には数えない）** — 対象は `01`〜`06` / `CLAUDE.md` / `docs/design-decisions.md` / `BACKLOG.md` に書き込んだ内容のうち、**`1` 確認前の推測に基づくもの `2` 裏取り済みだが読み違えの可能性があるもの `3` 対象リスト・状態要約**（前セッション以降の編集で陳腐化しやすい）。**その場のレビューを通過した誤りは、時間を置くと露見する**（実例: lint 設定の位置づけ）。注意力に頼らず、時間差で拾う仕組みとして実行する
3. 着手タスクが名指すファイルだけを `@` 参照する。必要が出た時だけ追加で読む
4. 壁打ち結果は内容に応じて章へ反映し、判断は `docs/design-decisions.md`、残課題は `BACKLOG.md`、作業の現在地は**作業日誌**に記録する