Mac 用のポータブル開発環境を chezmoi で管理する personal repository。
ねらいは「どこでも同じ設定にする」ことではなく、個人 / 会社 / クライアント / sandbox / AI agent の環境が、Git identity・secret・install policy・AI agent 権限の面で混ざらないことを最優先にすること。便利さよりも、境界を壊さないことを優先する。
personal project だが repository は public。会社名・クライアント名・内部 URL・secret は core に一切含めない方針で運用している(後述の「安全モデル」)。
複数の環境(個人 Mac・会社 Mac・クライアント案件・実験用・AI agent 用)を扱うと、こういう事故が起きやすい。
- 会社の commit に個人のメールアドレスが乗る(またはその逆)。
- 会社マシンで個人用の package を勝手に入れる、secret に触れる。
- credential 入りの remote URL を push してしまう。
- AI agent が触ってよい範囲が曖昧なまま広がる。
この repository は、これらを設定の作りからして起きにくくする。判定の基準は「project をどの directory に置いたか」(~/src/<context>/)。
personal project として段階的に作っている。現時点の実装状況は次のとおり。
| 領域 | 状態 |
|---|---|
| Git identity 分離(context 別、fail-closed) | 実装済み・実機適用済み |
| policy / capabilities / profile 検証(fail-closed) | 実装済み |
| environmentKind による capability 制約の強制 | 実装済み |
| supply-chain(git credential scan / npm hardening / Corepack policy) | 実装済み・実機適用済み(#91) |
| mise runtime | 実装済み・実機適用済み |
| doctor / preflight(report-only の健康診断) | 実装済み |
| software catalog + install action(dry-run 既定) | 実装済み・運用中(#53) |
| private backup(age 暗号化・verify/restore) | 実装済み・運用中(#60) |
| agent-tools との report-only 連携 | 実装済み(personal で opt-in 済み、#73) |
| zsh(shell-extra)+ starship の管理 | 実装済み・実機適用済み(#96) |
| Claude Code settings(personal の public-safe な settings.json) | 実装済み・実機適用済み(personal のみ) |
| Git signing(SSH 署名 + 1Password、opt-in) | 実装済み・実機適用済み(#85/#97) |
| VS Code settings の管理 | 管理しない(未使用のため見送り #16、dormant 配線も削除済み #145) |
| SSH(ssh-1password)の管理 | 実装済み・実機適用済み(personal のみ、#17/#121) |
| GitHub injection 防御(secret floor / MCP deny、steering) | Phase 2 まで実機適用済み(hard 層は #131) |
| Git hook gates 配線(commit 境界の public-safety / AI trailer gate、実体は agent-tools) | 実装済み(personal のみ、#196) |
「実機適用済み」は、現時点でこの author の Mac 上で managed file が実際に稼働しているという意味(実機の状態は repo からは検証できないので、この列は運用記録。repo 側で機械検証されるのは managed template と render / test の整合まで)。VS Code は未使用のため管理しない(#16。dormant 配線も #145 で削除)。SSH の移行手順は docs/ssh.md。
profile + environmentKind + modules + capabilities + policy
- profile: 用途別プリセット(
personal/work)。選びやすさのための入口で、権限そのものではない。 - environmentKind:
personal/work/client/sandbox/agentの環境種別。許可される capability に制約をかける(下記)。 - modules: 機能単位。
paths:で管理対象 file を宣言し、.chezmoiignoreの生成を駆動する。 - capabilities: 実際に許可する操作・副作用(install、secret access、npm hardening mode など)。何が起きるかは最終的に capabilities が決める。
- policy: 何を許可・禁止するかの判断基準(docs/policy-model.md)。
environmentKind は飾りラベルではない。validate-policy.sh が、環境種別が禁止する capability を hard fail で検査する(違反した PR は CI で止まる)。
| environmentKind | false 必須の capability |
|---|---|
| work / client / agent | installPackages, installGuiApps, allowSecretsAccess, allowNetworkTunnels, enableAiTools |
| sandbox | allowSecretsAccess |
| personal | (制約なし) |
つまり「会社 profile なのに package を自動 install する」ような設定は、構造的に作れない。
開発 project はここに置く。この階層が Git identity・secret access・install policy・AI agent policy の判定基準になる。
~/src/personal/<repo>
~/src/work/<org>/<repo>
~/src/client/<client>/<repo>
~/src/sandbox/<repo>
~/src/agent/<repo>
例えば ~/src/work/... 配下では work の Git identity が自動で選ばれ、~/src/ の外では identity が解決されず commit が(意図的に)失敗する。
- chezmoi(home file の apply)
- mikefarah/yq v4(policy script が使用)
- macOS
この repository は ~/dotfiles に置く前提で運用している(下の手順の --source ~/dotfiles もこれに合わせている)。dotfiles 本体は「ディレクトリ規約」が判定対象にする開発 project ではなく home を管理する道具なので、置き場所は ~/dotfiles を正本とする。
~/src/<context>/ 規約に実体も揃えたい場合は、実体を ~/src/ 配下(例: ~/src/personal/dotfiles)に置いて ~/dotfiles から symlink を張る(下の手順をそのまま使える)か、chezmoi --source <実パス> で実体のパスを直接指定する。
# 1. profile を選んで init(default は無いので明示する)
chezmoi init --source ~/dotfiles --promptString profile=personal
# 2. 何が適用されるかを全て確認する
chezmoi diff --source ~/dotfiles
# 3. 初回は target を絞って適用する(例: gitconfig だけ)
chezmoi apply --source ~/dotfiles ~/.gitconfigGit identity の実値は repository に入れない。使う context の identity file を手で置く。
mkdir -p ~/.config/git
cat > ~/.config/git/personal.gitconfig <<'EOF'
[user]
name = Your Name
email = you@example.com
EOF普段はほとんど意識しない。~/src/<context>/ 配下に project を置いて commit すれば、その context の identity が自動で使われる。状態を確認したいときは次を実行する(どちらも何も変更しない)。
./scripts/doctor.sh personal # 導入後の健康診断
./scripts/preflight.sh personal # 新マシン適用前の危険検知dotfiles を更新したら、pull してから diff を確認して apply する。apply の前に必ず diff を読む(何が変わるかを見てから反映する)。
git -C ~/dotfiles pull # dotfiles を最新化
chezmoi diff --source ~/dotfiles # 何が変わるか確認(必ず読む)
chezmoi apply --source ~/dotfiles # 反映(target を絞るなら末尾に path)
./scripts/doctor.sh personal # 反映後の健康診断profile を切り替える別マシン(例: 会社 Mac)では、先に git -C ~/dotfiles pull してから profile を更新する(古い profile 値のまま apply すると require-profile が fail-closed で止まる=設計どおり)。
git -C ~/dotfiles pull
chezmoi init --source ~/dotfiles --promptString profile=<kind>- Git identity が context を跨いで漏れない。
user.useConfigOnly=trueとincludeIfにより、context 外では identity が解決されず commit が止まる(間違った identity で commit するより安全側に倒れる)。 - credential 入りの remote URL を Git が拒否する(
transfer.credentialsInUrl=die)。加えて既存 remote の credential を doctor が scan する(URL の値は表示しない)。 - work / client 環境が構造的に lockdown される(environmentKind の制約強制)。
- supply-chain hardening。 npm の
ignore-scriptsなどの強制、Corepack の暗黙有効化なし、runtime の自動 install なし(docs/supply-chain-npm.md ほか)。 - fail-closed かつ report-only。 unknown profile・不正データ・依存欠如は黙って進まず止まる。
doctor/preflightは状態を報告するだけで何も変更しない。
- secret・SSH 秘密鍵・実 credential は repository に含めない。正しい供給方式(op + direnv の実行時注入、平文を置かない)は規約として定義し、dotfiles 自体は fetch しない(docs/secrets.md)。
- 会社名・クライアント名・社内 URL・private registry URL は core に入れない(public repository 前提)。
- unknown profile / module / capability は fail closed にする。
doctorは副作用を持たない。preflightは導入前の危険検知に限定する。- package install / GUI app install / macOS defaults / secret fetch / network tunnel / Git remote mutation / 既存 home 設定の上書きは、暗黙には実行しない。
- 別 repository(agent-tools)の status 取得は、別 repo のコード実行になるため
enableAgentToolsStatusでの明示 opt-in 時のみ行う(docs/ai-environment-boundary.md)。
scripts/— policy 検証 / doctor / preflight / テスト(scripts/README.md)。.chezmoidata/— profiles / modules / capabilities schema。docs/— policy model、Git identity、supply-chain、runtime、AI 境界などの方針。dot_*/private_dot_*— chezmoi が管理する home file の source。
変更は Issue → branch → Pull Request → CI → merge で進める(docs/github-workflow.md)。CI(.github/workflows/validate.yml)が policy 検証・各種テスト・shellcheck・chezmoi render を PR ごとに実行する。roadmap や作業ログは repository の外(Notion)で管理する。
MIT