Wave 5 → Wave 10 — カテゴリ別 Before/After 完全解説

📚 用語解説 — Optional Skin: Platform 5 入口の 外側に重ねる補助レイヤー。99_Proposals が main knowledge graph の外側 Support Layer であるのと同じ哲学。NOT 6th Platform entry と明記する (置き換えない、補強する)。

🛠️ 運用方法: 朝 1 番に 00_PLATFORM.md を開く → 目的に応じて 5 spoke のいずれかに移動。体調不良/やる気が出ない時は 🪫 Engagement Layer (Bastion Gate) → 知識作業は 🧬 Knowledge Ops の 5 zk-verbs → 施設案件は 🌉 Project Bridge の Dossier 経由。

📚 用語解説 — Support Layer: Vault 内に物理配置されているが意味的には main knowledge graph の 外側に位置する staging 領域。curated metric から除外、Obsidian Graph で visually 区別、main vault へは review 後にのみ merge。
📚 用語解説 — curated metric: PDF extracts / templates / Archive / Personal / 99_Proposals / 80_Rendered など「測定対象から除外すべき」folder を除いた集計値。Platform 表示用の正確な指標。

🛠️ 運用方法: (1) ノート編集時は 1 file = 1 役割を守る。混ざったら別 file へ split。(2) AI 提案 (PR/Edit) は 必ず 99_Proposals/ に staging → human review → main へ merge。(3) Wiki link 健全性は python validate_wikilinks.py --curated --compare で月次測定。(4) Bases は管理 UI、読みたい時は HTML reader、編集は Obsidian という役割分担を守る。

📚 用語解説 — Bastion Gate (城門): 朝 1 番に開くページ。今日の自分の状態 (4 段階) を選ぶだけで、その日の Quest 数と種類が自動決定される。状態は localStorage に当日 key で保存、リロードしても保持。
📚 用語解説 — Quest (4 種): 🔥 MAIN (今日絶対 1 件) / 🗡️ SIDE (できれば 1 件) / 📋 DAILY (定型確認) / 🌙 RECOVERY (休養・整理)。各 Quest に XP (10/5/3/3) が振られる。
📚 用語解説 — Recovery XP: 「回復」にも XP が付く設計。頑張れた日も休めた日も両方価値がある、というメッセージを数字で表現。

🛠️ 運用方法: (1) 朝起きたら Bastion Gate を開く → 4 状態から 1 つクリック。(2) 通常日は Daily Quest Board で当日 4 Quest を編集。(3) 寝不足/疲労日は Low Energy Mode へ → 5 つの「最低限」だけチェック。(4) 週末に Weekly XP Report で振り返り。

📚 用語解説 — Karpathy LLM Wiki: OpenAI 共同創業者 Andrej Karpathy が提唱した「AI が wiki ページを育て続ける」設計パターン。RAG (Retrieval-Augmented Generation) の発展形で、AI が 新規 source を読む → 既存ノートを更新する → 関連リンクを増やすを反復。
📚 用語解説 — Reflect 動詞 (Manabe 拡張): AI が育てた Wiki を Manabe 自身の Zettelkasten 思考連鎖へ戻す。AI が考える代わりに、Manabe の思考を trigger する役割。AI が代行できない、人間中心。
📚 用語解説 — append-only ログ: wiki_activity_log.md は 過去 entry の編集禁止。grep "^## \[" で時系列スキャンしやすい形式。Git log と相補。

🛠️ 運用方法: (1) 新規 PDF/論文を取り込む → /zk-ingest で 99_Proposals に staging → human review → merge。(2) 「BOOST と DE-MRI を比較して」→ /zk-query で knowledge_index を読んでから関連 5-10 notes 引用付き回答。(3) 月次健康診断 → /zk-lint で broken link/orphan/stale HTML を report 化。(4) HTML reader 再生成 → /zk-render (source = md を変更してから run)。(5) AI 提案を見て自分の思考を作る → /zk-reflect で 1 つだけ Zettel 化。

📚 用語解説 — Project Bridge: _Platform/Project_Bridge/ 配下に project_registry.json (31 projects、path triplet schema = relative + rc_root_relative + absolute) + facility_registry.json (7 facilities) を配置。AI Agent はこれを読んでから Dossier → Reference の順で深く入る。
📚 用語解説 — Facility Visit Report Layer ≠ Project Deliverable Layer: 1 回の訪問は通常 複数 Project を同時に扱うため、訪問報告書は施設レイヤー (0000_報告書/) に置くのが自然。Project の半年・1 年成果物は当該 Project 配下 (5_Deliverable/) に置く。混同すると整理が崩れる。
📚 用語解説 — Project Dossier: 各 Project folder の入口 1 枚 md。AI Agent はこれを最初に読む (深い folder 直接探索しない)。frontmatter に facility / project_code / canonical_folder / status / report_layer / ai_policy 等。

🛠️ 運用方法: (1) 新規 Project を扱う前に project_registry.json を読む → 該当 project の absolute_dossier パスから Dossier を Read。(2) 訪問前に Visit Battlecard 作成 → 当日 ReportForge で起案 → review → 0000_報告書/ に最終配置。(3) 半年/1 年成果物 → DeliverableForge で起案 → 5_Deliverable/。(4) Cross-Drive Guard: OneDrive (work) ⇔ GoogleDrive (private) は 自動 cross-copy しない、Context Pack に source_domain 必須。

📚 用語解説 — Critic Agent: oh-my-claudecode の critic サブエージェント。read-only mode で成果物を多角的に評価し、CRITICAL/HIGH/MINOR 分類で出力。verdict は ACCEPT / ACCEPT_WITH_RESERVATIONS / NEEDS_REWORK / REJECT。
📚 用語解説 — second opinion (独立レビュー): 同じ成果物を 異なる model (Claude vs Codex GPT-5) でレビューさせ、両者が指摘した点だけを「強い指摘」として採用する。互いに依存していないため、systematic bias 検出に強い。
📚 用語解説 — Potemkin village: 「scaffolding without content」 — 構造はあるが中身が空っぽの状態。Wave 9 で 31 空 Dossier がこれに該当、Codex Worker が top 5 を enrich して解消。

🛠️ 運用方法: (1) 大規模変更 (Wave 完了等) のたびに二重レビューを発動: Claude side で oh-my-claudecode:critic agent + Codex side で codex exec + 「review this directory honestly」。(2) 両者の出力を読み、CRITICAL のみ即修正、HIGH は次セッション、MINOR は defer。(3) 修正後 Playwright で screenshot 取得 (16 PNG) → Cloudflare Pages deploy → Discord 通知。(4) Memory に「verifier can be wrong」を保ちつつ、検出力は信頼。

📚 用語解説 — argv truncation: コマンドライン引数 (argv) としてプロセスに渡される文字列が、長すぎる/特殊文字を含む等の理由で完全に伝わらず途中で切れる現象。Windows の cmd.exe batch 実行系は改行 を行終端と解釈し、引用符 escape rules も独特なため、長い日本語プロンプトで頻発する。
📚 用語解説 — stdin pipe: 標準入力 (stdin) 経由でデータを渡す方法。CLI ツールの多くは - を「stdin から読む」signal として認識する (codex も同様)。プロセス起動コマンドの長さ制限・cmd.exe escape の影響を受けない。
📚 用語解説 — CODEX_HOME 隔離: 環境変数 CODEX_HOME で codex の作業 dir を切替えられる。並列実行時に各 worker が mktemp -d で専用 dir を作り、~/.codex 内容を symlink (auth.json は共有、generated_images/ だけ独立) すれば、画像保存先 race を完全回避。

🛠️ 運用方法: (1) Python/Bash から codex を呼ぶ時は 必ず stdin pipe (上記コード参照)。(2) 並列実行 (>1 worker) する場合は 必ず CODEX_HOME を per-worker 隔離。(3) Bash の場合は printf '%s' "$prompt" | CODEX_HOME="$tmp" codex exec --full-auto - パターン。(4) 失敗診断は session JSONL を読む: ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl の line 5 user message に渡したプロンプトが完全に入っているか確認。intro 1 行のみなら argv truncation 確定。

📚 用語解説 — disjoint path enforcement: 並列実行する各 worker の write 先 path を完全分離するルール。OneDrive 配下で並列書き込みすると conflict copy が大量発生するため、各 worker は専用 path のみ書く。Wave 8 で 4 codex worker を分離 path で動かし 0 conflict 達成。
📚 用語解説 — smoke test first: 外部 CLI / 新 skill を本番投入する前に最小プロンプトで動作確認する規律。Wave 10 で「codex image_gen が file 保存するか」を smoke test → 「inline image しか返らない」事実発見 → session JSONL から自動保存先 path 発見 → 完全動作確認。
📚 用語解説 — Codex bypass フラグ (Windows 必須): --skip-git-repo-check --dangerously-bypass-approvals-and-sandbox。Windows codex sandbox の "spawn setup refresh" 失敗を回避し、shell access を有効化する。stdin close (</dev/null in Bash, input="" in Python) で hang 回避も併用。

🛠️ 運用方法: (1) 大量・反復タスク (10+ files の bulk 生成、template instantiation) → Codex worker を 3-4 並列で dispatch、Manager は調整に専念。(2) 各 worker の write path を事前に図示し、完全 disjoint を確認してから dispatch。(3) Worker の出力は 未信頼: Glob/Read で実ファイル存在を verify (memory: feedback_codex_quality)。(4) 1 worker ~30-100k tokens 消費なので、想定 tokens を見積もって ChatGPT Plus subscription 範囲内か確認。(5) 失敗時 (Wave 10 のような) は session JSONL 解析で root cause 特定 → 修正パターンを auto-memory 化。