置き去り stash の構造的原因 — 仕分けカルテ

無人の定期タスクが git 追跡下のファイルを書き換える → 作業ツリーが dirty → repo_sync の pull が autostash を作る → 誰もそのファイルを書き直さないので、退避されたまま戻らない、という連鎖です。

この対処は既にこの repo にあります。2026-08-01（pricing-uploader の16行が消えた事故）で `scripts/_git_sync.py` の `commit_ledger()` が作られ、7箇所に適用済みでした。

実測すると、今 dirty を作っている書き手8本は全部これを呼んでいません。恒久対策そのものは正しく、横展開が途中で止まっていただけです。

推奨 ① この見立てでいい — 「全部 .gitignore」は、下の A3 の9件が持つ復元不能な履歴・cross-PC 共有をまとめて壊す

無回答なら この見立てで進めます

「追跡する／しない」の2択だと、どちらを選んでも壊れるファイルが出ます。この repo には既に4つ目までの前例が揃っていたので、それに合わせました。

A. 追跡継続＋即 commit … 履歴や2機共有が要る台帳（前例: morning_build の commit_ledgers）
B. .gitignore … ローカル再生成で足りる派生物（前例: portal-internal の reviews.html）
C. 作業ツリーの外へ移設 … 消えると事故る「状態」ファイル（前例: 2026-07-22 に run_status.json を `%USERPROFILE%\.claude\health\` へ移設済み）
D. CI 再生成に寄せる … deploy 元だが決定論的に作れるもの（前例: otake_docs の index.html）

推奨 ① この4分類でいい — 2択に丸めると、C に当たる3件が「共有する意味は無いが消えると事故る」の谷に落ちる

無回答なら この4分類で進めます

gitignore してはいけない側です。理由を1件ずつ確認しました。

■ 履歴が取り直せない（消えたら終わり）
・`scripts/otake_index/manifest_health_history.json` … URL ping の直近90日。過去日は二度と取れません。朝の morning_build は既に commit していますが、毎時走る `email_agent/run_cron.py` が同じファイルを書いて commit していない ← これが最大の穴
・`data/owner_pl/manifest.json` … 施設×月のPDF在庫台帳。前回分をベースにマージする設計なので、巻き戻ると過去の送付記録ごと消えます
・`data/health_check/summary.json` ＋ `owner_report_coverage.json` … 週次の健診記録

■ 2機で共有していないと本番が壊れる
・`scripts/deploy/manifests/otake-docs.json` … これが一番危険。cf_pages_guard が「前回配ったファイル一覧」として持つ台帳で、2026-07-23 に本番ページが消えた事故の対策そのものです。古い版に巻き戻ると guard が誤判定します

■ GitHub Actions が読む（CI 側では作れない）
・`output/deploy/otake_docs/search_index.json`
・`scripts/pages_index/projects_cache.json`
・`scripts/otake_index/log_state.json`

■ 追跡すると既に決めてある
・`data/line_concierge/corpus/state.json` … `corpus/README.md` に「追跡する」と明記済み。決定を尊重します

推奨 ① この9件は追跡のままでいい — ignore にすると、上3件は履歴が永久に失われ、manifest は本番削除ガードが効かなくなる

無回答なら 9件は追跡のまま commit_ledger を足します

「2機で共有する意味は無いが、branch 切替で消えると誤動作する」ファイルです。gitignore だと git の巻き戻しからは守れますが、worktree を跨いだときに実体が分裂します。移設先は前例と同じ `%USERPROFILE%\.claude\health\<subsystem>\`。

・`data/memory_headroom_state.json`（82B）… BLADE の物理メモリ実測に基づく通知抑制フラグ。機ごとに値が違うので、git で共有すると2台が上書きし合います
・`scripts/dreaming/nightly_run_state.json`（307B）… BLADE 専用の夜間実行状態。DELL では走りません
・`scripts/cleaner_calendar/kv_refresh_state.json`（974B）… KV push 済みマーカー

2026-07-22 に run_status.json 系3本を同じ理由で移設したときの記録が `sync_requests/standing_run_status_heartbeats.json` に残っています（branch 切替で状態が消え、doctor が誤判定した事故）。同型なので同じ場所に寄せます。

推奨 ① ツリー外へ移設でいい — ②は「消える」ほうの事故（branch 切替・worktree 分裂）を防げない。7/22 はまさにそれで doctor が誤判定した

無回答なら %USERPROFILE%\.claude\health\ へ移設します

・`output/deploy/otake_portal_internal/ops/schedule/index.html` … ビルド生成物。同じディレクトリの `index.html` と `ops/facility/*/reviews.html` は既に理由付きで ignore 済みなので、完全に同じ枠です（デプロイは wrangler がフォルダごと上げるため、追跡外でも本番には載ります）
・`data/yhr_gateway/session_state.json` … 今回 untracked のまま出ていた新顔。同じ枠に入れます

追記する2行には、既存の .gitignore と同じ流儀で「なぜ ignore するか」の理由コメントを添えます。

推奨 ① ignore でいい — 追跡し続けると、毎回のビルドで40commit/60日の churn を生み続ける割に、履歴を読む価値がゼロ

無回答なら 理由コメント付きで .gitignore に足します

60日で109コミット・70KB と、churn が最も大きいファイルです。同じフォルダの `index.html` は既に「追跡せず CI で再生成」に寄せてあるので、当然そこに揃えたくなります。

が、寄せられません。 `build_search_index.py` の入力に `output/deploy//index.html` が含まれており、そのほとんどは .gitignore 対象です。CI ランナーには実体が無いので、寄せると検索インデックスが痩せたまま本番に載ります**（壊れず、静かに劣化する＝一番たちが悪い形）。

よって A3 と同じ「追跡＋即 commit」に置きます。churn は残りますが、autostash は止まります。

推奨 ① 追跡＋即commit でいい — ②は検索が静かに劣化する。壊れて気づくならまだしも、気づけない形の劣化は避けたい

無回答なら 追跡のまま即commit にします

「60分以上残っていたら置き去り」「2サイクル連続で1回だけ鳴らす」の設定はそのままにします。

今回 ALERT は正しく鳴っています。溜まっていたのは事実で、警報は仕事をしました。ここでしきい値を緩めると、次に本物の取りこぼしが起きたときに鳴らなくなります。直すのは発生源であって、警報ではありません。

上の対処が入れば、鳴る回数は自然にゼロへ近づきます。

推奨 ① 触らないでいい — 警報側を緩めるのは、2026-07-31 に実データを失った事故の再発防止をわざわざ弱める行為

無回答なら しきい値はそのままにします