常駐ジョブを「作業ツリーの HEAD」に依存させない設計

毎日決まった時刻に走るジョブ（Windows タスクスケジューラ / cron / launchd）が、人間や別の AI セッションが 使っているリポジトリの作業ツリーをそのまま実行場所にしていると、いつか必ず静かに壊れる。 原因はコードの不具合ではなく「実行場所の HEAD が他人の都合で動く」こと。この文書はその潰し方を書く。

症状

• ジョブが Cannot find module ... や No such file で落ちる。スクリプトは確かにリポジトリにあるのに無い。
• 特定の朝だけ成果物（レポート・ログ）が欠ける。前後の日は正常。
• 誰も何も壊していない。ブランチを切り替えただけ。

原因

ジョブの実行場所を WorkingDirectory=<リポジトリ> にして node tools/<ジョブ>.mjs を叩いていると、 実行されるのは「その瞬間その作業ツリーがチェックアウトしているブランチの中身」になる。 ツールが特定のブランチにしか無い状態で、別のブランチへ checkout が起きるとファイルは消える。 自動化された夜間セッションがブランチを切って作業する運用だと、これは事故ではなく時間の問題。

「main にマージした」は「常駐ジョブが読める」ではない。 マージ後に作られたブランチには入るが、 マージ前に切られたブランチに居る作業ツリーには現れない。

直し方: コードの置き場と成果物の置き場を分ける

1. ジョブ専用の worktree を作る（コードの置き場）

git -C <リポジトリ> worktree add --detach <ジョブ用worktree> origin/<既定ブランチ>

detached にするのが要点。ブランチをチェックアウトすると「同じブランチは1つの worktree にしか置けない」 制約で、人間側が同じブランチを触れなくなる。

2. ジョブは worktree の中のスクリプトを叩く（ラッパーを噛ませない）

タスクのアクションを複数並べる。シェルスクリプトのラッパーを1枚挟むと、そのラッパーが 文字コード・行継続・終了コードの握り潰しで**「成功に見える失敗」**を作る。実行ファイルを直に指定する。

アクション1: git  -C "<ジョブ用worktree>" fetch --quiet origin
アクション2: git  -C "<ジョブ用worktree>" checkout --detach --quiet origin/<既定ブランチ>
アクション3: <node等> "<ジョブ用worktree>/tools/<ジョブ>" --out-root "<リポジトリ>"

1・2 で毎回最新へ追従するので、worktree が塩漬けになって改善が反映されない問題も同時に消える。 タスクの終了コードは最後のアクションのものになるので、1・2 が失敗しても本体の生死は拾える。

3. 成果物だけは共有リポジトリへ返す（--out-root）

これを忘れると、レポートやログが誰も見ない worktree に溜まる。 「まず直近のレポートを読む」という運用の導線が切れて、次に触る人（や AI）が同じ調査をやり直す。

スクリプト側は出力の基準ディレクトリだけを差し替えられるようにする。実装の勘所:

const HERE = path.dirname(fileURLToPath(import.meta.url));
const ROOT = path.resolve(HERE, '..');
const argv = process.argv.slice(2);

const OUT_ROOT = (() => {
  const i = argv.indexOf('--out-root');
  if (i >= 0) {
    const v = argv[i + 1];
    if (!v || v.startsWith('--')) { console.error('--out-root にパスが指定されていません'); process.exit(2); }
    return path.resolve(v);
  }
  return process.env.<接頭辞>_OUT_ROOT ? path.resolve(process.env.<接頭辞>_OUT_ROOT) : ROOT;
})();
const OUT_DIR  = path.join(OUT_ROOT, '<出力先ディレクトリ>');
const LOG_PATH = path.join(OUT_ROOT, '<履歴ファイル>');
fs.mkdirSync(OUT_DIR, { recursive: true });

変えてよいのは出力先だけ。 同じスクリプトが呼ぶ兄弟ツール（path.join(HERE, 'other-tool')）は HERE 基準のままにする。ここまで OUT_ROOT にすると、固定した worktree で走らせている意味が消える。

値が欠けたら exit 2 で止める。 黙って既定へ落とすと、出力先を間違えたまま何ヶ月も走り続ける。

検証（ここを省くと直った気になるだけ）

順番に、すべて終了コードで判定する。

1. 構文: node --check <スクリプト> → 0
2. ガード: <ジョブ> --out-root（値なし）→ 2。--out-root --other-flag も 2
3. 出力先: 空の一時ディレクトリを --out-root に渡して実走 → 0 かつそのディレクトリに成果物が出る。 同時にworktree 側に出ていないことをファイルの更新時刻で確認する（「出た」だけ見ると二重出力に気付けない）
4. スケジューラ経由で起動する（手でコマンドを打つのではなく）。終了コードをスケジューラ側の記録で読む。 コマンドラインが手打ちでは通るのにタスクからは落ちる、は日常的に起きる（引用符・作業ディレクトリ・権限）
5. 外部通知を伴うジョブは、テスト実行の時だけ --dry 相当を足して送信を止める。 終わったら外したことを定義の読み戻しで確認する（付けっぱなしで通知が止まる事故が本命）

よくある取りこぼし

• 終了コードが 0 でも成果物が無いことがある。生死は「成果物の更新時刻」で見る。
• 複数の常駐ジョブがあるなら worktree は共用してよい。ただし片方が checkout で HEAD を動かすので、 もう片方も同じ既定ブランチで動く前提であることを確認する。
• worktree は登録情報がリポジトリ側に残る。使い終わった一時 worktree は git worktree remove --force で消す。
• git worktree list に一時ディレクトリが並び続けるのは、掃除し忘れの合図。