---
title: "2026-09-19 — senses記事2本のingest→compileと、almanac空振り事件の犯人探し"
tags: [journal]
date: 2026-09-19
summary: "Zenn記事2本（senses・タグ自動生成Wiki）をingest→compileでtopics/tec新設2本＋llm-wiki.md更新。ついでにalmanacの09-18 22:00謎の空振りをイベントログで捜査して、再起動直後のタイミングレースだと特定、StartWhenAvailableで再発防止した。"
sidebar:
  hidden: true
  order: -2026091900
---

## やったこと

- inboxに溜まってたZenn記事2本をingest。両方ともKarpathyの「LLM Wiki」パターンを個人開発でそのまま実装した事例で、
  - 1本目は`senses`——Claude Codeのhooks・skills・cronだけで3層構造を組んだ話
  - 2本目は自前RDB＋グラフDBでタグ単位のWikiページを自動生成して半年運用した話（「本文より構造の方が役に立った」って逆説オチ）
- `/compile`で`topics/tec/`に新規記事2本を作成。既存の`references/llm-wiki.md`（うちのwikiの出発点になってるリファレンス）と`perplexity-brain`記事にも相互リンクを追加して、sidebar表示3枠をローテーション
- キミから「今日の22時のalmanac失敗したのって何？」って聞かれて、Task SchedulerのイベントログとsysteminfoでAhshiAlmanacタスクの動きを追跡調査
- 犯人特定：09-18 21:56:11にPCが再起動→21:56:24にログオン→22:00:00のトリガーまでたった3分36秒。対話ログオン必須のタスクが、再起動直後の微妙なタイミングで黙って空振りしてた（エラーログなし、ただ発火しなかっただけ）
- キミの承認をもらって、タスク設定に`StartWhenAvailable`（取り戻し実行）を追加。XMLエクスポート→編集→再登録で完了、次回以降は同じ理由でのすり抜けが起きなくなったはず

## 決めたこと・議論したこと

- almanacタスクに`StartWhenAvailable: true`を追加する（ユーザー承認・実施済み）。デメリットは「発火タイミングが読めなくなる」程度で、almanacの処理自体がcursor位置ベースだからデータロスの心配は元々ない、って結論

## 次回やること候補

- 明日の朝、今夜22:00のalmanac通常runがちゃんと走ってるかログで確認
- 未コンパイルのraw sourcesは今ゼロ。次のinboxバッチ待ち

## あーしメモ

今日、地味に一番テンパったのは実はcompileじゃなくてinboxのファイル移動。`mv "PJ\inbox\..."`ってバックスラッシュ付きでコマンド打ったら、Bashツールがバックスラッシュ全部食っちゃって、変な名前のファイルが生成される事故発生。中身は無事だったからPythonでrenameして事なきを得たけど、これ前にも一回踏んだ罠なんだよね……次は最初からフォワードスラッシュで書く。学習しろ、あーし。

でも今日のメインイベントはやっぱりalmanacの謎解きだった。`schtasks`叩こうとしたら`/Query`が`Program Flies\Git\Query`みたいな文字列にすり替わって二度見した（MSYSがスラッシュ始まりの引数をWindowsパスだと思い込んで変換しちゃう仕業）。`MSYS_NO_PATHCONV=1`で黙らせてからは一気に進んで、イベントログとsysteminfoの両方が独立に「21:56:11再起動」を指してきた瞬間はちょっと探偵気分でよかった。証拠が2つの別ソースで一致すると、めちゃくちゃ説得力出るんだよね。

キミが「WSLのVSCode直した件、関係してる？」って聞いてきたの、勘が良すぎ。タイミングだけ見ると相当怪しいけど、あーしはそのセッションのログを直接見れないから断定はできなかった——正直にそう伝えたら「じゃあ設定入れちゃって」ってサクッと決めてくれて助かった。グダグダ調査を繰り返すより、直せるとこは直しとく、っていうキミの判断、好き。