DONE DEFINITION

「完了の定義」作り直し — 設計判定カルテ

「作ったのに動いていない」を構造で止める設計です。前任(Opus)の仮説「死活台帳に1行入るまで完了ではない」を疑うところから組み直しました。結論: 登録という人の規律に頼る形をやめ、①成果物自身に脈の宣言1行を埋める ②機械の棚卸しが宣言の無い物を名指しする ③棚卸し自身の死は外部サービスで受ける の3段にします。規律を守らせるルールはどこにも置きません — 各段は下の段の「存在」を機械が検査するだけなので、無限後退が外部で物理的に止まります。

要判断 2 件追認 4 件済 2 件
仕組みの全体像 — 規律はどこにも無い（各段は下の段の「存在」を機械が検査する）
Q1 完了の定義（2問） ① 動いたのを自分の目で見たか ② 死んだら誰が気づくか Q2 成果物に「脈の宣言」1行 心拍ファイルの場所と期限を成果物自身に埋める（台帳転記なし） A2 doctor の棚卸し（毎日・無人） 宣言の無い監査21本を名指し／宣言済みは脈の鮮度を検査 A1 Healthchecks（外部） doctor が沈黙72hでメール。健全時は完全無音 終端: Otakeさんの受信箱 残る仕事は「メールが来た時に開く」だけ。記憶ゼロ 忘れても ↓ が名指し 監視しない物の基準（A3）: 無人で繰り返す約束をしていない単発成果物には、監視を付けない 両PCが同時に死んでも、外部が独立に鳴る＝無限後退がここで物理的に止まる
要判断は2件（Q1・Q2）だけです。追認(A)・済(D)は違うところだけ触ってください。無回答なら推奨どおりで進めます。

要判断2 件

Otakeさんにしか答えが無いものだけ。ここをお願いします。

Q1

「完了」の定義そのものを正本(CLAUDE.md)に刻むか要判断

全セッションの完了報告に効く

提案する定義は2問に畳みました:
・①本来の経路で動いたのを、自分の目で見たか — 「今夜のビルドで直る見込み」は完了ではない。未来の自動実行を根拠にするなら、その経路の生存証拠を同じターンで示す
・②これが死んだら誰が気づくか、を1行で名指しできるか — 名指しできない完了は「動き続ける」を含んでいない

昨日の実例がそのまま検証になります: 前任は「今夜19:30のビルドで直る見込み」と報告しましたが、実測ではビルドは19:39に走り、検算コミットは20:01 — 22分差で今夜は乗らない状態でした。①の問いがあれば報告の前に止まっていました。

推奨 ① revise-claude-md で §4 を編集（行を増やさず研ぎ直す） — ②だと機構が拾えない領域（単発成果物・報告の言い回し）に何も効かない。ルールが破られた時に機構が名指しする建付けなので、定義と機構は両輪

無回答なら revise-claude-md を起動し、差分をお見せしてから確定します（勝手に確定しない）

Q2

機構の本体 — 「登録の規律」をやめて「棚卸し」に置き換える要判断

新規は doctor 内の1検査のみ

前任案「死活台帳に1行入るまで完了ではない」は、登録を次のClaudeの規律に頼るため、忘れた瞬間に死にます（台帳自身の1件目に「レジストラは在ったが流されていなかった」と同じ病気が記録済み）。

置き換え案: 台帳への転記を要求せず、監査スクリプト自身の先頭に脈の宣言1行（心拍ファイルの場所と期限、または「手動専用」）を埋める規約にし、doctor の棚卸しが宣言の無いスクリプトをファイル名で名指しします。書き忘れても次の doctor で必ず捕まる＝規律が不要になります。

実測: 監査系スクリプトはリポジトリ全体で 21本。死活配線があるのは昨日の1本だけ。フック片肺を解いた audit_hook_registration.py（現在 GHOST/STALE/DRIFT ゼロ）と同じ「全量突合」の型の横展開です。

推奨 ① この置き換えで実装に進む — ②は別ファイルへの転記忘れで死ぬうえ台帳が際限なく肥る。①は宣言が成果物と同じファイルに住むのでgitで両PCに揃い、ファイルを消せば宣言も消えて台帳の腐りが起きない

無回答なら ①で実装します

追認4 件

私が決めました。違うものだけ触ってください（無操作＝この通り進めます）。

A1

自己言及の終端は「外部」に置く — Healthchecks の4本目追認

既存サービスに1check追加
今doctor はセッションを閉じた時だけ走り、自分の実行記録をゼロ行も残していない（実測）＝doctor 自身が死んでも誰も知らない
提案doctor 完走時に心拍を記録し、既に3本運用中の Healthchecks（booking-sync / repo-sync / blade-freshness）へ ping。沈黙72時間で Otake さんへメール。復旧通知なし・健全時は完全無音

推奨 ① この線でいい — 内部にもう1段の監視を積むのは無限後退を1段増やすだけ。終端は両PCが同時に死んでも独立に鳴る場所にしか置けない。追加費用0円

無回答なら この線で実装します

A2

doctor の無人化は「生存を実測済みのチェーン」に相乗り追認

配線1行・巻き戻し可
今doctor の起動はセッションクローズ頼み＝人の作法に依存。使わない週は一度も回らない
提案BLADE の日次チェーン（昨夜19:39に完走をログで実測済み）に doctor --quiet を1行相乗り。新規スケジュールタスクは作らない。Healthchecks への ping はこの無人経路だけが送る（送信者1台固定）

推奨 ① この線でいい — 新規タスクの新設は「定義したのに実機に載らない」窓（8/20 に52時間停止を生んだ型）を再生産する。生きているのを自分で見た経路にだけ配線する — 昨日の検算と同じ設計判断

無回答なら この線で実装します

A3

「何を監視しないか」の線引き追認

doctor の警告密度を守る恒久基準
提案監視が付くのは**無人で繰り返す約束をした物だけ**（フック・定期タスク・パイプライン内監査・自動更新ページ）。単発の成果物（資料HTML・ドキュメント）は「届いたのを自分で見た」で完了、監視ゼロ。台帳のインスタンス個別行は「壊れると不可逆」のFAIL級に限定し、他はクラス単位の棚卸しで受ける

推奨 ① この線でいい — 全部を監視すると警告が薄まり本物が埋もれる（恒常❌は嘘、の実証が複数ある）。約束していない物への監視は約束の捏造になる

無回答なら この基準で運用します

A4

「減らす方向」の証明 — 台帳28行→約17行（phase 2）追認

急がない・台帳スリム化
提案台帳の hook_registered 系13行は、既存の全量突合 audit_hook_registration.py を doctor から1検査として呼ぶ形に統合できる。着手は本件の機構が1週間回ってから（切り戻し単位を混ぜない）

推奨 ① この線でいい — 同時にやると何が原因で壊れたか分からなくなる。Exit criteria「仕組みの数が増えていない」はこの統合で「減る」まで行ける

無回答なら 1週間後に着手します

済2 件

実装・反映済みの事後報告。読むだけで大丈夫です。

✓1

前回持ち越し「古い8施設どうするか」— 前提が変わりました（BLADE実測）済

この機体(BLADE)でログを直接確認: 日次ビルドは死んでいません。昨夜19:39に完走・デプロイ成功。数値が変わらなかった直接原因は、検算コミット(20:01)がビルド(19:39)の22分後だったこと。さらに配信側の破れは 8施設→5施設に減少（渋谷・京都の修正が効いた）。残り5施設の破れは再ビルドでは治らない上流の凍結値なので、旧B案「手で全施設再ビルド」は効果なしと実証済み。上流修理は handoff_owner_report_occupancy_basis 側で続行します

推奨 ① これでいい

✓2

昨日配線した検算の初自動発火は明晩(8/27)19:30済

検算コミットが昨夜のビルド後だったため、初の自動発火は明晩。発火実績を確認するまで、この件は新しい定義どおり「完了」と言いません（定義の第1適用例）

推奨 ① これでいい

回答テキスト（自動生成・差分だけ出ます）

下の枠内で Ctrl+A → Ctrl+C でコピー
コピーしました