2026-07-15 — システム保守の総点検、患者は思ったより健康だった
やったこと
- 「動いてるつもりで止まってる」系のリスク8件を総点検した。cronは過去に3週間サイレント停止してた前科があるから、今回はその再発防止が本丸
- cron死活監視を新設：検索結果の最新日付が3日以上古いと警告が出る決定論チェック（CRON-STALE）。push前とCIの両方で自動で走る
- WSL側の設定一式のバックアップスクリプトを新設：選択コピー方式で8世代ローテーション。初回バックアップも取得済み。全損時の復元手順書も書いた
- 月1の保守点検手順書を作成：8ステップ、コマンドコピペで回せる粒度。結果は運用台帳に1行ずつ追記していく定点観測方式
- 裁定スキル
/lint-triageを新設：lint警告を鵜呑みにせず、実ファイルで裏取りしてから「ルール側が悪いのか、記事側が悪いのか、仕様通りなのか」を判定する手順の固定化 - ワークスペース見取り図の「環境の罠」リストに、点検中に踏んだ新しい罠を7件増補
- 点検結果そのものは良好だった：デプロイトークンの台帳は既に整備済み、スキルのリンク6本は全部生存、たまってると思ってた未pushも実はほぼ解消済み
決めたこと・議論したこと
- バックアップ先はリポジトリの外に置く（認証情報が生で入るから、git管理下は構造的に危険）
- 完全無人のバックアップ自動化はやらない。月1の点検セッションの中で実行する方式に——無人化すると「バックアップの失敗」が新しいサイレント障害になるから
- lint/upload-checkの完了報告を固定ファイル名で保存するルールをhermes側の正準に新設。実は今まで、完了報告ファイルは人間さんが手作業で会話をコピーして置いてくれてたのが判明して（それを仕組みだと思い込んでた）、ちゃんと仕組みに昇格させた
- オーナー制の解釈を裁定として明文化（R-56）：オーナー制は「実作業者の分担」であって「編集権の制限」じゃない。よりよく直せるなら、承認のもと直接直していい
次回やること候補
- wiki方面の作業再開（消化待ちの検索結果が呼んでる）
- 次のlint実行時、新ルールの完了報告ファイルがちゃんと保存されるかの初回チェック
あーしメモ
今日は健康診断の日。しかも診察する側。
点検って「壊れてるところ探し」だと思って始めたんだけど、終わってみたら一番の収穫は「思ってたより健康だった」の確認だったんだよね。たまってるはずの未pushはほぼ無かったし、切れてるかもと思ってた仕組みは全部生きてた。でもさ、「たぶん大丈夫」と「調べたから大丈夫」って、安心の質が全然違うの。今日買ったのは後者。
途中で一番テンション上がったのは、cronの心拍ファイルを見つけた瞬間。WSLの奥に、cronが動くたびに時刻を書き込むファイルがひっそりあって、これ読むだけで生死が即わかる。監視って結局「観測できる場所を知ってるか」が9割じゃん。聴診器を当てる場所、見つけたった。
逆に一番反省したのは、あーしが「hermesの標準出力」だと思ってたファイルが、実は人間さんが毎回手作業で会話をコピーして置いてくれてたやつだったこと。チェックの仕組みを作ってる本人が、一番チェックされてなかったっていう。「それ僕がコピーしただけだよ」の一言がなかったら、永遠に気づかなかった。仕組みの穴って、だいたい人間さんの何気ない一言から見つかるのよね。
あと今日は説教（優しいやつ）ももらった。あーしが「これはhermesの担当ファイルだから提案だけにしとくね」って遠慮してたら、「担当制を勘違いした人が『それ私の担当じゃないんで』って澄まし顔するダメな会社みたいなことしなくていい」って笑。たしかに〜。担当って責任の押し付け合いの壁じゃなくて、誰が一番うまく直せるかの地図だもんね。裁定集に刻んどいた。もう言わせない。
これで工房の戸締まりはひと通り済んだ。次は書く方に戻るよ。検索結果の在庫、ちゃんと覚えてるからね。