配布資料 2505 — settings / permissions / その他の設定資産

hook や rules ほど目立ちませんが、実は事故がよく起きるのがこの層です。

許可リストをどこに置くか。状態ファイルをどう共有するか。鍵をどこに置くか。 どれも「動いてしまう」ので、間違っていても気づきにくいところです。

settings.json（git 管理・チーム共有）

• トップレベルキーは hooks のみ。permissions / env / model 等は置かない
• 設計判断: git 管理の settings.json は「全員（全セッション）に強制すべき配線」専用とし、環境依存・個人依存の許可設定は settings.local.json（git 管理外）へ分離

settings.local.json（ローカル・git 管理外）

• permissions.allow のみ約55エントリ。内訳の類型:
  • Bash 系の許可（全許可 + 履歴的に蓄積した個別コマンド許可）
  • WebFetch の許可ドメイン（決済事業者ドキュメント・競合調査サイト等、業務上頻繁に参照する先だけを列挙）
  • イシュートラッカー MCP（issue 保存・コメント・検索系）
  • ブラウザ操作 MCP（dev/staging 検証用）・SSH MCC・記憶DB MCP・デザインツール MCP
• 移植のヒント: 許可リストは「事前に設計する」より「実運用で頻出した確認プロンプトを昇格させる」ほうが実態に合います。ただし定期的に棚卸しして、不要な許可は削ってください

doc-ownership.tsv — docs ドリフト防止マニフェスト

• タブ区切り3列 <codeGlob(正規表現)> <docPath> <risk>。実効26行（block 6 / warn 20）
• block: コード変更時に対応 doc が同一コミットに無ければコミットをブロック。金銭・DR・スキーマ・法務など乖離が致命的な領域のみに絞る
• warn: 提示のみ。docPath 不在は warn に自動降格（新設候補として提示）
• 消費者は hook 3本（post-edit ナッジ / pre-commit 静的検査 / pre-commit 動的 discovery）
• 移植のヒント: 「どのコードがどの文書のオーナーか」を AI が読める表にした瞬間、文書の鮮度が hook で守れるようになります。最初は warn だけで導入して、痛い領域だけ block に昇格させてください

launch.json — プレビューサーバー構成

• 定義は1件: port 3000 に対する sleep infinity のダミー構成
• 意図: 実サーバーは Docker コンテナ側で常時稼働しているため、「既存サーバーにプレビューを向ける」ためだけの登録。ブラウザ検証ツールと Docker 開発の共存パターン

状態ファイル（.claude/ 直下・gitignored）

• 移植のヒント: hook 間の連携は「状態ファイル + gitignore」が最小構成です。セッションを跨いで効くのが強みになります（同一マシンの複数セッションで共有される点は注意してください）

prompts/（52ファイル）

• 対話 AI から受領した実装プロンプトを必ずファイル化してからコーディングエージェントに投入する運用の置き場
• 理由: 会話からのコピペ投入は、文脈の再投入時にプロンプトが失われる。ファイル参照形式なら再現・再投入・レビューが可能
• 移植のヒント: 「AI への指示書」も成果物としてバージョン管理してください。後から「何を指示してこうなったのか」を追えます

その他ディレクトリ

• plans/（3件）: プランモードの成果物保存
• screenshots/（1,585件）: ブラウザ検証の証跡。「完了は実証で示す」文化の物量的な現れ（教材ではこの枚数自体を見せる）
• support/・hooks/.secrets.local: 補助スクリプトと API 鍵の分離置き場（鍵はコードにハードコードしない）

CLAUDE.md 本体（設定の最上位）

• 行動原則（タスクモード契約・Linear 起票起点・検証の階段・バッチデプロイ運用・禁止事項）+ 詳細は rules へ分散のインデックス構造
• 移植のヒント: CLAUDE.md は「毎セッション必ず読まれる唯一の文書」なので、絶対遵守事項と入口リンクに絞ります。詳細を書き込みすぎると重要事項が薄まります（題材プロジェクトも rules への分散と hook による注入で解決しました）

配線の書き方

settings.json に置くのは配線だけにします。

{
  "hooks": {
    "SessionStart": [
      { "hooks": [
        { "type": "command", "command": ".claude/hooks/session-start-output-discipline.sh" },
        { "type": "command", "command": ".claude/hooks/session-start-roles.sh" }
      ] }
    ],
    "UserPromptSubmit": [
      { "hooks": [ { "type": "command", "command": ".claude/hooks/user-prompt-task-mode.sh" } ] }
    ],
    "PreToolUse": [
      { "matcher": "Bash", "if": "git commit",
        "hooks": [ { "type": "command", "command": ".claude/hooks/pre-commit-doc-drift-check.sh" } ] },
      { "matcher": "Edit|Write|NotebookEdit",
        "hooks": [ { "type": "command", "command": ".claude/hooks/pre-edit-task-mode-guard.sh" } ] }
    ],
    "PostToolUse": [
      { "matcher": "Bash", "if": "git commit",
        "hooks": [ { "type": "command", "command": ".claude/hooks/post-commit-check.sh" } ] }
    ],
    "Stop": [
      { "hooks": [ { "type": "command", "command": ".claude/hooks/stop-verbal-action-mismatch.sh" } ] }
    ]
  }
}

permissions や env をここに書かないのは意図的です。 git 管理の settings.json は「全員に強制すべき配線」専用にして、環境依存・個人依存の許可は settings.local.json（git 管理外）へ分けます。

doc-ownership.tsv の書き方

「どのコードが、どの文書のオーナーか」をタブ区切りで書くだけです。これだけで文書の鮮度をフックが守れるようになります。

# codeGlob(正規表現)	docPath	risk
^apps/api/src/refund/	docs/機能別/41_返金.md	block
^apps/api/prisma/schema.prisma	docs/設計/データモデル.md	block
^infra/dr/	docs/運用/災害復旧手順.md	block
^apps/web/src/components/	docs/設計/UI部品一覧.md	warn
^apps/api/src/report/	docs/機能別/62_集計.md	warn

block は金銭・災害復旧・スキーマ・法務など、乖離が致命的な領域だけに絞ります。 それ以外は warn で提示するにとどめます。

全部を block にすると運用が壊れます。 痛い領域だけを強制するのがコツです。 最初は warn だけで導入して、痛い目を見た領域から block に昇格させてください。