PLAN.md

開発工場の憲章（全端末・全プロジェクト）— 聖典 v4

原則1〜10 の番号・骨子は不変（他リポ・グローバル共通憲法が番号で参照する生きた参照）。

趣旨

dotagents は開発工場そのもの。全プロジェクトに共通して効く土台（規範・同期ハブ・知識台帳）と、工場管理対象製品の統合責務を持つ。規範・配布・知識の各面の地図は docs/00_overview.md、管理対象の現行集合は工場の現行状態、製品・基盤toolchain・BugHubの統合契約は docs/factory-product-contracts.md が正。GitHub が真実の源。LatticeはCodegraphを完全吸収した正式後継で、独立Codegraphはretired／not_applicableの履歴だけを保持する。

範囲: 本旨は「開発工場（環境）の最適化」。個々のプロダクトの品質監査・法務チェック・深いバグ探しは範囲外——それは「工場で作る製品の検品」であり、オーナーが個別に依頼した時だけ行う。各プロジェクトへの介入は原則、①GitHub 同期 ②フォルダ構成の標準化 ③CLAUDE.md ブラッシュアップ ④Spotter のproject-scoped有効化に絞る。Spotterは全projectで無条件発火させず、正規CLIが作るmarkerで対象を限定する。

原則（番号は生きた参照＝変更禁止）

1. 最上位知能の使い所は3種だけ: ①判断が資産として残る作業（監査・敵対的検証・裁定） ②必要性を実証した契約の敷設（外部境界・最終確認CI・規約・テンプレ） ③翻訳（弱いモデルでも従える契約・手順への落とし込み）。仕様が固まった実装は安価モデルで足りる——物量は外部枠・安価枠へ委譲し、統括は仕様＋罠リスト＋検証コマンドの作成・裁定・diff レビュー・コミット/push に絞る（委譲契約はshared/orchestrate/delegation-contract.md、配置はdocs/02_models.mdが正）。
2. GitHub が真実の源: プロジェクトは端末を跨いで存在する。全てのプロジェクト作業は fetch→照合→整合させてから。作業後はpushで真実を返す（本原則は、dotagentsと製品契約台帳で自作コアに分類された製品の正規repoに対する恒久push裁定である。第三者製品・基盤toolchainには適用しない。認定手順は憲法git鉄則に従う）。
3. リポ内知識 ＞ 端末ローカル記憶: プロジェクトの真実（設計・手順・規約）は repo の CLAUDE.md / docs / rag に置く。端末メモリ（~/.claude/projects/*/memory）は端末固有・私的な文脈だけ。
4. 全リポを残す前提を置かない: 終わったプロジェクトはローカルから消してよい。ただし削除の決定は必ずオーナーに提案→承認（AI が勝手に消さない）。安全判定は git-hygiene runbook の終活手順に従う。
5. 各タスクにラベル: F=最上位品質が要る／A=安価モデル＋契約で可／H=人手（ログイン・削除承認等）。ラベル運用は統括レーンの4関節（writer委譲・受入裁定・Phase gate・H操作）の裁定用とする。
6. 自作資産の終活: 自作 skill / command / rule / 契約は、作成時期を問わず対象hostで使う現行モデルと実行環境のネイティブ能力と突合してから残す。突合で負ける資産は延命せず廃止を提案する（廃止承認は常に H）。見直しのトリガーはオーナー——モデル世代交代の時期はオーナーだけが観測・宣言できる。前提行の書式・定期化しない理由・世代交代時の手順は docs/02_models.md が正。
7. 依存は「窓」に限定し、「真実の保存」には置かない: 依存を置いてよいのは交換可能な「窓」（ビューア・UI・変換器）まで。知識・判断・規約の保存層は素の Markdown＋git（依存ゼロ・全モデル可読・端末横断）。根拠と適用例は rag/second-brain/ が正。
8. 重い検証構造（多視点Find→Dedup→指摘ごとの反証→Critic）は統括レーンの契約クリティカルだけ（頻度・範囲・クロスprovider検証・指摘の反証と棄却はshared/orchestrate/contract.md「監査の頻度」が正）。
9. モデルはバージョン固定禁止: latest 型で指定する。役割→現行最強の対応表 docs/02_models.md を唯一の参照点にし、各所にモデル名を書き散らさない。
10. （書込みscopeは憲法「調査と知識の置き場」冒頭に従う）知識は還流させて育てる（第二の脳）: 調査・研究を使い捨てにしない。外部仕様・文献も出力（回答・監査ダイジェスト・図解）も還流して複利で育てる。運用規約（raw/コンパイル分離・INDEX台帳・月次Lint・選球眼・人間用の窓）は knowledge-return runbook が正。

文書の作法

• 統括レーンのプランはプロジェクトの docs/ に作る。通常レーンは会話上の成功条件または内蔵planで足り、会話・端末メモリ・~/.claude/plans を工程正本にしない。
• 実行TODOの正本はLattice typed discoveryで決める: Latticeの明示適用が決まった作業、またはオーナー承認済みの既存Lattice工程を継続する時だけ、工程を読む/作る前に lattice status --json で正本を判定する（判定・cutover・fallback禁止の詳細は lattice-workflow runbook が正）。
• 文書は所有者と寿命を同時に決める: current／contract／generated／history／evidenceの分類とarchive例外はdocsの地図とdocument registryが正。完了文書はarchiveへ移し、同義currentは一つへ統合する。各製品の内部制御は各製品repoが所有し、dotagentsは横断統合だけを所有する。
• 時間見積を計画の制約・判断材料にしない（AI の作業時間見積は実際の約20倍過大）。計画は順序・依存関係・承認ゲート（H）だけで組む。
• （書込みscopeは憲法「調査と知識の置き場」冒頭に従う）方針級の発見はその場で正典へ。共通文書の書き方（端末非依存・絶対日付・方針は理由ごと本文に）と書き先の振り分けは canon-authoring runbook が正。

定常運用

• プロジェクト作業は sync-sweep green から始める。掃引の検査項目・台帳運用と、リポ終活トリアージ（三分類・安全に消せる条件・救済手順・GitHub 側は archive）は git-hygiene runbook が正。「休眠」は端末単位の状態であってプロジェクトの生死ではない——生死はオーナー宣言でのみ決まり、削除承認は常に H・端末ごと。
• 席への手作業の工場展開は、その席のdotagents作業ディレクトリで親AIを起動し、その親にその席の正規入口を実行させ、失敗はその席で直して閉じる（SSHで1箇所から他席を回す場合も同じ。理由: 2026-08-16 Wave 5。一撃展開のexit 0は親として動くことを見ない。入口スクリプトは改良が続き、スクリプト単独の無人実行では席差の壊れに気づけない）。定期更新のcron／Taskは対象外。手順はREADME「他端末セットアップ・ランブック」が正。
• 定期: agents-update の常設（全端末必須。Macは週次、main-server／rabbit native Linux／Windows nativeは日次。各hostのcron／Task Schedulerは独立jobで、相互代替・共有しない。登録と受入はREADME「他端末セットアップ」「自動アップデート」のhost別一撃展開が正）。月次: メモリ棚卸し＋ rag/ Lint（枠と手順は knowledge-return runbook が正）。世代交代時の更新手順は docs/02_models.md が正。

残件

• 現役工程はlattice todo status --jsonを正とし、本憲章へ個別TODOや完了数を重複させない。完了した統合工程は固定参照用の案内から履歴へ辿る。