claude-spotter 0.13.0 → 0.13.2

package/CHANGELOG.md

@@ -1,5 +1,48 @@
 # Changelog
 
+## 0.13.2
+
+**Daemon の死因を必ずログに残す診断インフラ + Haiku 子プロセス stdio の防御的 error listener**。v0.13.1 までは daemon が `uncaughtException` / `unhandledRejection` で死ぬと痕跡ゼロで消えていた ([daemon-80b5c0af.log](../../.spotter/logs/daemon-80b5c0af-700f-47af-a3ac-796144823a7d.log) line 15 → line 16 で shutdown ログなしに再起動)。次に同じことが起きた時に真因を必ず捕まえられるよう、診断 handler を導入。
+
+### 監査の経過と結論
+
+[haiku-caller.mjs](src/daemon/haiku-caller.mjs) の `child.stdin.end(prompt)` → timeout で `child.kill()` という流れで、未 flush の stdin が EPIPE を emit → unhandled stream error → daemon 即死、という仮説を立てた。Windows + Node v24.14.0 で repro script を書いて検証したところ、**`child.stdin/stdout/stderr` の error listener 不在でも uncaughtException は発火せず process は生存** (stdin 8KB end → 500ms 後に kill → 4 秒生存して clean exit、EXIT=0)。
+
+つまり 80b5c0af の死因は stdin EPIPE ではなく、別経路。ログには `handler error on turn_end: E_HAIKU_TIMEOUT` (transport の catch + onError まで完了) が残っているので、その後の何かで死んでいる。**真因を確定できる証拠がログにないことが本質的な問題**と判断、診断 handler を先に入れる方針に切替えた。
+
+### 変更点
+
+- **編集 [src/cli/daemon-cmd.mjs](src/cli/daemon-cmd.mjs)**: daemon 起動冒頭で `process.on('uncaughtException')` / `process.on('unhandledRejection')` を登録。**同期 `writeFileSync` で log file に append** してから `process.exit(1)`。async write はバッファ flush 前に exit して line を失うが、sync write なら必ず残る。次回死亡時に stack trace + 種別 (`uncaughtException` か `unhandledRejection` か) が確実に記録される
+- **編集 [src/daemon/haiku-caller.mjs](src/daemon/haiku-caller.mjs)**: `child.stdin/stdout/stderr` に no-op error listener を追加。今の Node v24 では落ちないと実証済みだが、Node 公式 docs はこの edge case を明示保証していない (将来の Node 変更や別 OS で挙動が変わる可能性) ため、defensive coding として投入
+
+### 残課題
+
+- daemon 突然死の真因特定: **次回再現を待つ**。診断 handler が入ったので、次に死亡した時はログに必ず痕跡が残る。それを見て対処する
+- v0.13.1 で 30s → 45s 緩和した Haiku timeout の効果観測は継続: 現セッション [daemon-69bd2b93.log](../../.spotter/logs/daemon-69bd2b93-ffbe-43bc-94e7-1d0ba2bd9e74.log) line 5 で `mode=first, duration_ms=32703` を観測 (30s 設定なら timeout していた値が 45s で生存)。サンプル 1 件で結論はまだ早い
+
+## 0.13.1
+
+**Haiku timeout 30s → 45s 緩和 + hook 側 IPC timeout を整合**。v0.13.0 以前の実セッション ([daemon-80b5c0af.log](../../.spotter/logs/daemon-80b5c0af-700f-47af-a3ac-796144823a7d.log) line 15) で `E_HAIKU_TIMEOUT: haiku did not respond within 30000ms` を観測。同ログ line 20 でも `mode=first, duration_ms=20948` と 30s の 70% 域まで達しており、timeout が実測レイテンシに対して狭すぎた。合わせて [src/hooks/stop.mjs](src/hooks/stop.mjs) の IPC timeout が元々 15s で Haiku 側 30s と整合していなかった既存バグ (turn_end で Haiku が 16s 超かかると hook 側が先に諦めていた) も同時解消。
+
+### 調査で判明した Haiku 4.5 の高速化ダイヤル不在
+
+公式 docs 確認 (2026-04-20):
+
+- `--effort` フラグは Opus 4.7 / Opus 4.6 / Sonnet 4.6 のみ対応、**Haiku 4.5 は effort 非対応** ([model-config docs](https://code.claude.com/docs/en/model-config#adjust-effort-level))
+- Haiku 4.5 は **extended thinking 対応だが adaptive thinking 非対応** ([models/overview](https://platform.claude.com/docs/en/docs/about-claude/models/overview) 比較表)
+- `claude -p` CLI に thinking 直接フラグ無し、API デフォルトで thinking は OFF
+- つまり Haiku 側で「速くする手段」は存在せず、timeout 緩和しか打ち手が無い (Sonnet 4.6 切替は遅くなる + 3 倍コストで逆効果)
+
+### 変更点
+
+- **編集 [src/daemon/daemon.mjs](src/daemon/daemon.mjs)**: `DEFAULT_HAIKU_TIMEOUT_MS` を 30_000 → 45_000。first-call cold-start + 観測されたレイテンシスパイク (20.9s) + margin を包含
+- **編集 [src/hooks/user-prompt.mjs](src/hooks/user-prompt.mjs)**: `TIMEOUT_MS` を 30_000 → 50_000 (Haiku 45s + IPC margin 5s)
+- **編集 [src/hooks/stop.mjs](src/hooks/stop.mjs)**: `TIMEOUT_MS` を 15_000 → 50_000 (既存の整合性バグも解消)
+
+### 残課題
+
+Haiku 突然死 (shutdown ログなしで daemon 再起動する事象、v0.12.0 auto-resurrect で救われているが見えない欠落ターンが発生する) は未対処。[docs/open-issues.md](docs/open-issues.md) P0 に残置。
+
 ## 0.13.0
 
 **Stop 判定軸を「要請充足チェック」から「ツール適用機会の監査」に転換**。v0.12.x 以前の `stage=turn_end` は `<user_input>` + `<used_tools>` + `<final_response>` を Haiku に渡し、「ユーザー要請されたツールが使われたか」を判定していた。この軸では Bell が Stop 到達後にすべき動作 — 事実断定の裏付け / 新知見の記録 / 既知情報の照会 — を拾えない。実セッションで Haiku が応答「判明: A モジュールは B に依存」に対し `caveat_record` を推奨する、といった本来期待される指摘が構造的に出ない状態だった (ユーザーが [この議論](https://github.com/kitepon-rgb/Spotter) で指摘)。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-spotter",
-  "version": "0.13.0",
+  "version": "0.13.2",
   "description": "Audit agent running alongside Claude Code that catches missed tool calls — 気づく役と実行する役の分離",
   "type": "module",
   "bin": {

package/src/cli/daemon-cmd.mjs

@@ -4,6 +4,7 @@ import { startDaemon, DaemonAlreadyRunningError } from '../daemon/daemon.mjs';
 import { homedir } from 'node:os';
 import { join } from 'node:path';
 import { open } from 'node:fs/promises';
+import { writeFileSync } from 'node:fs';
 
 function parseArgs(argv) {
   const out = { sessionId: null, projectRoot: null };
@@ -30,10 +31,32 @@ export async function runDaemonStart({ argv }) {
     process.exit(2);
   }
 
-  const logFile = await open(
-    join(homedir(), '.spotter', 'logs', `daemon-${sessionId}.log`),
-    'a'
-  );
+  const logFilePath = join(homedir(), '.spotter', 'logs', `daemon-${sessionId}.log`);
+
+  // v0.13.2: last-resort fatal handlers. Without these, an uncaughtException or
+  // unhandledRejection silently kills the daemon and the regular logFile.write()
+  // (async) loses the trailing line on sudden death — leaving zero forensic
+  // trace. We do a sync append so the cause is always captured before exit.
+  // See open-issues.md "daemon プロセスが shutdown ログなしに死ぬ".
+  const fatalLog = (kind, err) => {
+    const detail = err && err.stack ? err.stack : String(err);
+    const line = `[${new Date().toISOString()}] FATAL ${kind}: ${detail}\n`;
+    try {
+      writeFileSync(logFilePath, line, { flag: 'a' });
+    } catch {
+      process.stderr.write(line);
+    }
+  };
+  process.on('uncaughtException', (err) => {
+    fatalLog('uncaughtException', err);
+    process.exit(1);
+  });
+  process.on('unhandledRejection', (reason) => {
+    fatalLog('unhandledRejection', reason);
+    process.exit(1);
+  });
+
+  const logFile = await open(logFilePath, 'a');
   const log = (msg) => {
     const line = `[${new Date().toISOString()}] ${msg}\n`;
     logFile.write(line).catch(() => {});

package/src/daemon/daemon.mjs

@@ -47,10 +47,11 @@ import { join } from 'node:path';
 import { writeFile, unlink } from 'node:fs/promises';
 const DEFAULT_HAIKU_CALL_WINDOW_MS = 10_000;
 // v0.5.0: lowered 60s → 30s. Session-scoped (--resume) means the first call still pays
-// cold-start but subsequent calls skip it. 30s covers the first-call cold path without
-// being excessive, and a role-collapse recovery cycle (reset → next call is effectively
-// a cold start again) stays within budget.
-const DEFAULT_HAIKU_TIMEOUT_MS = 30_000;
+// cold-start but subsequent calls skip it. 45s covers first-call cold path plus the
+// observed Haiku CLI latency spikes (2026-04-20 log shows 20.9s resumed calls and 30s
+// timeouts in the wild). Role-collapse recovery (reset → next call is effectively a
+// cold start again) stays within budget.
+const DEFAULT_HAIKU_TIMEOUT_MS = 45_000;
 // v0.12.0: heartbeat-based orphan cleanup. Every envelope resets a setTimeout; if no
 // hook event arrives within this window, the daemon self-shuts. 30 min is the longest
 // silence we expect from a live Claude Code session. UserPromptSubmit auto-resurrects

package/src/daemon/haiku-caller.mjs

@@ -242,6 +242,16 @@ export function createHaikuCaller({ preamble, timeoutMs, claudeBin = 'claude', m
       let stderr = '';
       let settled = false;
 
+      // v0.13.2: absorb EPIPE/ECONNRESET on stdio streams. We end(prompt) and
+      // then kill() on timeout — if the write hadn't drained yet, the unflushed
+      // stream can emit 'error' after kill. Today's Node doesn't crash on
+      // unhandled stdin errors, but the docs don't guarantee that, and this
+      // listener removes a potential silent-death path.
+      const noop = () => {};
+      child.stdin.on('error', noop);
+      child.stdout.on('error', noop);
+      child.stderr.on('error', noop);
+
       const timer = setTimeout(() => {
         if (settled) return;
         settled = true;

package/src/hooks/stop.mjs

@@ -15,7 +15,7 @@ import {
 import { getLastAssistantText } from './transcript-reader.mjs';
 import { sendRequest } from '../daemon/transport.mjs';
 
-const TIMEOUT_MS = 15_000;
+const TIMEOUT_MS = 50_000;
 
 export async function runStop() {
   if (isChildCall()) return;

package/src/hooks/user-prompt.mjs

@@ -21,7 +21,7 @@ import {
 import { sendRequest, TransportError } from '../daemon/transport.mjs';
 import { spawnDaemonAndWaitReady } from './spawn-daemon.mjs';
 
-const TIMEOUT_MS = 30_000;
+const TIMEOUT_MS = 50_000;
 const SHORT_PROMPT_MAX_CHARS = 10;
 
 export async function runUserPrompt() {