claude-spotter 1.7.2 → 1.8.0

package/CHANGELOG.md

@@ -3,6 +3,17 @@
 各節はそのversion公開時点の変更記録であり、後続versionにより置換された仕様を含む。
 現行runtime契約は[`docs/00_overview.md`](https://github.com/kitepon/Spotter/blob/main/docs/00_overview.md)から辿る。
 
+## 1.8.0 — 2026-09-27
+
+- Grok Buildのnative hookとhost専用カタログを追加。Linux、macOS、Windows nativeの実セッションで入力時・応答後の監査を確認した。Grok 1.0.41は受動hookのstdoutを会話へ渡さないため、findingは構造eventと評価DBに記録する。
+- Grokのheadless実行で最終応答つき`Stop`が欠けたturnを`SessionEnd`で補完する。Windowsでは`SessionStart`のカタログ更新完了を待ち、初回監査から有効なツールを使う。
+- Windows Cursorのhook入力に付くUTF-8 BOMを受け付け、Git管理外のprojectでもCodex CLI監査を実行できるようにする。
+- dashboardの現行構成から廃止済みFOX WSL2端末を外し、3端末を表示する。
+
+## 1.7.3 — 2026-09-24
+
+- 退役するcodex-sidecarの明示CLI、追加監査dispatch、primary auditor backend指定、診断と関連コードを削除する。Jev、Codex CLI、Haikuの主監査は維持する。
+
 ## 1.7.2 — 2026-09-21
 
 - Jevの判定を実験済みの短い質問＋Noulへ変更し、肯定確率0.5超を提案する。

package/README.ja.md

@@ -18,7 +18,7 @@
 
 ## 所有境界
 
-本repositoryはSpotter製品面の全体、すなわち監査挙動、Claude/Codex hook adapter、
+本repositoryはSpotter製品面の全体、すなわち監査挙動、Claude/Codex/Cursor/Grok hook adapter、
 project marker、catalog discoveryとhost-local tool DB、評価store、dashboard server、
 diagnostics、installer、release packagingを所有します。
 [dotagents](https://github.com/kitepon/dotagents)が所有するのは共有agent指示と、
@@ -68,16 +68,18 @@ cd your-project
 spotter install
 ```
 
-macOS の Homebrew Node 環境では、Codex hook command の Node パスに現在の実体と一致する
+macOS の Homebrew Node 環境では、CodexとGrokのhook commandのNodeパスに現在の実体と一致する
 安定 symlink (`/opt/homebrew/bin/node`) を使います。
 `/opt/homebrew/Cellar/node/<version>/...` のような version 固定パスを書かないため、
-Homebrew で Node が更新されても Codex hook が古い Node パスに取り残されません。
+Homebrew で Node が更新されてもhookが古いNodeパスに取り残されません。
 
 `v0.3.0` 以降は**プロジェクト単位の明示的 install** を採用しています (v0.2 までの `postinstall` 自動登録はデーモン増殖の主因だったため撤回)。各プロジェクトの `.claude/settings.json` に hook を登録し、そのプロジェクトでの Claude Code セッションのみで有効になります。
 Codex CLI が使える環境では、同じ `spotter install` が user-level の Codex native hooks も登録します。実際に動くプロジェクトは `spotter install` が作る `.spotter/marker.json` で制限されるため、無関係な Codex セッションでは Spotter は起動しません。
 Codex 側では現行の `[features].hooks = true` を有効化し、互換のため旧 `codex_hooks` diagnostics output も認識します。
 Spotter が所有する Codex handler は現行の同期 command schema で生成します。install / upgrade 後は `/hooks` で review して新しい Codex session を開いてください。`spotter codex-hook diagnostics` は登録と readiness を診断しますが、trust を内部状態から推測しません。
 
+Grok Buildがある環境では、`spotter install`はGrok native hookも登録し、専用の`.spotter/tool-db.grok.json`を初期化します。入力時と応答後の監査結果は`.spotter/hook-events.jsonl`と評価DBに残ります。Grok 1.0.41は受動hookのstdoutを会話へ渡さないため、findingは親会話には表示されません。登録は`spotter grok-hook diagnostics`で確認し、install後は新しいGrok sessionを開いてください。
+
 Spotter を upgrade した後、release note で hook 設定変更が案内されている場合は、各 install 済みプロジェクトで `spotter install` を再実行してください。global package update でコード経路は変わりますが、既存 `.claude/settings.json` の timeout 値は自動では書き換わりません。
 
 ```bash
@@ -88,12 +90,20 @@ spotter uninstall        # このプロジェクトの hook 登録を解除
 
 ```bash
 npm uninstall -g claude-spotter
-npm install -g claude-spotter
+npm install -g claude-spotter@1.8.0
 spotter --version
 spotter install -y
-spotter codex-hook install
 ```
 
+公開担当は検証済みcommitを`main`へmergeし、`main`から
+[Publish to npm](https://github.com/kitepon/Spotter/actions/workflows/publish.yml)へpackage versionを指定して実行します。
+workflowは指定versionと`main`への着地を検査してから`npm publish`します。
+初回だけ[npm packageのAccess設定](https://www.npmjs.com/package/claude-spotter/access)で
+GitHub ActionsのTrusted Publisherを登録してください。ownerは`kitepon`、repositoryは`Spotter`、
+workflow filenameは`publish.yml`、environmentは空欄、直接の`npm publish`を許可します。
+GitHubが管理するrunnerのOIDCを使うため、以降の公開にnpm tokenの保存やCLIログインは要りません。
+公開後はregistryのversionを確認し、対象端末へそのversionを指定してインストールします。
+
 ## 動作要件
 
 - **Node.js 22.13 以上**（npmの`engines.node`と同じ）
@@ -245,17 +255,12 @@ spotter dashboard device --id mac --name Mac
                          # この端末の評価DBを127.0.0.1:53940で配信
 spotter dashboard hub --config dashboard-hub.json --host 172.18.0.1
                          # 端末一覧と/devices/<id>/の端末別proxyを配信
-spotter codex risk-check --findings findings.json --host-agent claude
-                         # Spotter finding を codex-sidecar に渡して read-only risk analysis
-spotter codex review|explore|opinion --findings findings.json --host-agent claude
-                         # その他の read-only codex-sidecar second-pass workflow
-spotter codex work --findings findings.json --instruction "docs 更新" --approve-work \
-  --allowed-path docs/ --preserve-worktree
-                         # 承認済み codex-sidecar work を isolated worktree で実行
 spotter codex-hook install
                          # Codex native hooks の修復 / 明示登録 (通常は spotter install が実行)
 spotter codex-hook diagnostics
                          # Codex hook の登録/readiness を診断。trust は /hooks で review
+spotter grok-hook diagnostics
+                         # Grok native監査hookの登録を確認
 spotter auditor model-matrix --fixtures test/fixtures/auditor-model-matrix.v2.json --recent-turns 2 --body-cap 600
                          # pinned auditor model profile を再現可能に比較する experimental eval
 spotter uninstall        # hook 登録を解除 (~/.spotter は残す)
@@ -278,21 +283,11 @@ project/tool内訳、非採用case、監査対象request、任意の提案時Thr
 health確認は端末一覧request時だけなので、端末がofflineでもbackground監視や
 retry queueを作らず、その端末だけを切り離せる。
 
-4端末のservice、reverse tunnel、Caddy/Cloudflare構成は
+3端末のservice、reverse tunnel、Caddy/Cloudflare構成は
 [docs/11_dashboard-operations.md](https://github.com/kitepon/Spotter/blob/main/docs/11_dashboard-operations.md)を参照。
 Windows同梱のTask Scheduler installerはnpm・SSH用の対話ユーザープロファイルを維持しつつ、
 dashboardの2つのPowerShell actionを非対話・console非表示で起動する。
 
-Codex risk dispatch を daemon から非同期に流す場合:
-
-```bash
-SPOTTER_CODEX_RISK_CHECK=1 spotter daemon start --session-id ... --project-root ...
-```
-
-有効時は daemon が `pass:false` finding を detached process の
-`spotter codex risk-check` に渡します。hook 応答は Codex を待ちません。
-配線だけ確認する場合は `SPOTTER_CODEX_RISK_CHECK_DRY_RUN=1` を併用します。
-
 ## 端末内runtime error集計
 
 factory diagnosticsとruntime error集計は既定OFFです。canonicalなdotagents factory reporter設定で
@@ -320,7 +315,6 @@ Codex CLI auditor は versioned product policy を使い、production は反復
 profile から production へ自動昇格しません。`latest` alias や
 親 Codex の default を暗黙継承せず、失敗時に別 model へ retry しません。制御された実験では
 `SPOTTER_CODEX_CLI_MODEL` / `SPOTTER_CODEX_CLI_REASONING_EFFORT` で上書きでき、diagnostics は unverified と表示します。
-明示 smoke には `SPOTTER_AUDITOR_BACKEND=codex-sidecar` も使えます。
 
 ## 設計ドキュメント
 
@@ -344,7 +338,7 @@ profile から production へ自動昇格しません。`latest` alias や
 - **失敗は声に出して縮退、hostを固めない** (v1.4.15) — この版でbackend failureによるpromptのsilent消去を止めた。v1.4.19以降もnon-blocking挙動は維持し、旧model可視警告文は固定`systemMessage`・stderr・構造event診断へ置換した
 - **プラグイン形式の MCP サーバー対応** — `plugin:everything-claude-code:context7` のように名前に内部コロンを含むサーバーを正しくパースし、配下のツールをカタログに取り込めるようになった (旧版はこの形式のサーバーをすべて単一の `"plugin"` に潰して、Claude の監査から silent に脱落させていた)
 - **プロジェクト単位の監査隔離** — daemon が監査に使うのはローカル DB のみ。グローバル DB は description 再利用キャッシュに役割限定。**他プロジェクト**でインストールしたツールが現プロジェクトの監査に混入することはない
-- **手放しでカタログ維持** — `spotter install` が Claude DB を自動 seed、Claude / Codex それぞれの SessionStart が host-local DB を bg refresh する。手書き管理は一切不要
+- **手放しでカタログ維持** — `spotter install`が利用可能なhostのDBを作る。Claude / Codex / CursorはSessionStartでバックグラウンド更新し、Grokは初回監査前に更新完了を待つ
 - **Codex native hooks** — Codex host は primary auditor backend として Codex CLI を使い、`.spotter/tool-db.codex.json` を Claude DB と分離し、backend failure は Haiku fallback ではなく明示 error として扱う
 - **監査対象** — ユーザー追加分 (MCP / スキル / サブエージェント) のみ。Claude Code 本体側のツールは意図的に対象外 (Claude は元から自発率が高いため)
 - **実装規範** — フォールバック禁止 / silent fallback 禁止 / 暫定コード禁止 ([AGENTS.md §0](https://github.com/kitepon/Spotter/blob/main/AGENTS.md))

package/README.md

@@ -18,7 +18,7 @@ Built and maintained by [Quo](https://x.com/QLyun35332) at [kitepon.dev](https:/
 ## Ownership boundary
 
 This repository owns the complete Spotter product surface: auditor behavior,
-Claude/Codex hook adapters, project markers, catalog discovery and host-local
+Claude/Codex/Cursor/Grok hook adapters, project markers, catalog discovery and host-local
 tool databases, evaluation storage, dashboard servers, diagnostics, installers,
 and release packaging. [dotagents](https://github.com/kitepon/dotagents)
 owns shared agent instructions and the optional factory-reporter configuration
@@ -69,16 +69,18 @@ cd your-project
 spotter install
 ```
 
-On macOS with Homebrew Node, Codex hook commands use the stable
+On macOS with Homebrew Node, Codex and Grok hook commands use the stable
 `/opt/homebrew/bin/node` symlink when it resolves to the current Node binary,
 instead of a versioned `/opt/homebrew/Cellar/node/<version>/...` path. That keeps
-Codex hooks working across Homebrew Node upgrades.
+both sets of hooks working across Homebrew Node upgrades.
 
 Since `v0.3.0`, Spotter requires **explicit per-project install** (the earlier `postinstall` auto-registration was the leading cause of orphan daemons). `spotter install` writes hooks into the project's `.claude/settings.json`; the audit is then active only in Claude Code sessions for that project.
 When the Codex CLI is available, the same `spotter install` also registers user-level Codex native hooks. Project activation still depends on the same per-project `.spotter/marker.json`, so unrelated Codex sessions do not trigger Spotter.
 For Codex, install enables the current `[features].hooks = true` flag and still recognizes older `codex_hooks` diagnostics output for compatibility.
 Installer-owned Codex handlers use the current synchronous command schema. After install or upgrade, review them with `/hooks`, then open a fresh Codex session; `spotter codex-hook diagnostics` reports registration/readiness but does not guess hook trust.
 
+When Grok Build is installed, `spotter install` also registers native Grok hooks and seeds a separate `.spotter/tool-db.grok.json`. Grok prompt and final-response audits write findings to `.spotter/hook-events.jsonl` and the evaluation database. Grok 1.0.41 ignores stdout from passive hooks, so it does not show those findings in the parent conversation. Check registration with `spotter grok-hook diagnostics` and open a new Grok session after install.
+
 After upgrading Spotter, re-run `spotter install` in each installed project when release notes mention hook setting changes. The global package update changes the code path, but existing `.claude/settings.json` timeout values are not rewritten automatically.
 
 ```bash
@@ -89,12 +91,20 @@ Release install smoke:
 
 ```bash
 npm uninstall -g claude-spotter
-npm install -g claude-spotter
+npm install -g claude-spotter@1.8.0
 spotter --version
 spotter install -y
-spotter codex-hook install
 ```
 
+Maintainer release: merge the tested release commit into `main`, then run
+[Publish to npm](https://github.com/kitepon/Spotter/actions/workflows/publish.yml) from `main` with the package version.
+The workflow checks the requested version and the `main` ancestry gate before `npm publish`.
+For the one-time npm setup, open the [package access settings](https://www.npmjs.com/package/claude-spotter/access)
+and add a GitHub Actions trusted publisher: owner `kitepon`, repository `Spotter`,
+workflow filename `publish.yml`, no environment, and allow direct `npm publish`.
+The GitHub-hosted workflow uses OIDC, so later releases need no stored npm token or CLI login.
+After publication, verify the registry version and install that exact version on each target host.
+
 ## Requirements
 
 - **Node.js 22.13+**
@@ -249,17 +259,12 @@ spotter dashboard device --id mac --name Mac
                          # serve this terminal's local evaluation DB on 127.0.0.1:53940
 spotter dashboard hub --config dashboard-hub.json --host 172.18.0.1
                          # list terminals and proxy /devices/<id>/ to their local servers
-spotter codex risk-check --findings findings.json --host-agent claude
-                         # run read-only codex-sidecar risk analysis for Spotter findings
-spotter codex review|explore|opinion --findings findings.json --host-agent claude
-                         # run other read-only codex-sidecar second-pass workflows
-spotter codex work --findings findings.json --instruction "Update docs" --approve-work \
-  --allowed-path docs/ --preserve-worktree
-                         # run approved codex-sidecar work in an isolated worktree
 spotter codex-hook install
                          # repair / explicitly register Codex native hooks (normally handled by spotter install)
 spotter codex-hook diagnostics
                          # check Codex hook registration/readiness; trust is reviewed with /hooks
+spotter grok-hook diagnostics
+                         # check Grok native audit hook registration
 spotter auditor model-matrix --fixtures test/fixtures/auditor-model-matrix.v2.json --recent-turns 2 --body-cap 600
                          # experimental reproducible comparison of pinned auditor model profiles
 spotter uninstall        # remove hooks from this project (leaves ~/.spotter intact)
@@ -285,21 +290,11 @@ audited by Spotter, and optional proposal-time Throughline evidence. The hub che
 when the device list is requested, so an offline terminal is isolated without a background monitor
 or retry queue.
 
-The reference four-terminal service, reverse-tunnel, and Caddy/Cloudflare layout is documented in
+The reference three-terminal service, reverse-tunnel, and Caddy/Cloudflare layout is documented in
 [docs/11_dashboard-operations.md](https://github.com/kitepon/Spotter/blob/main/docs/11_dashboard-operations.md).
 On Windows, the bundled Task Scheduler installer keeps the interactive user's profile for npm and
 SSH while starting both dashboard PowerShell actions non-interactively with hidden console windows.
 
-Optional async Codex risk dispatch:
-
-```bash
-SPOTTER_CODEX_RISK_CHECK=1 spotter daemon start --session-id ... --project-root ...
-```
-
-When enabled, the daemon dispatches `pass:false` findings to `spotter codex risk-check`
-in a detached process. Hook responses do not wait for Codex. Add
-`SPOTTER_CODEX_RISK_CHECK_DRY_RUN=1` to exercise the wiring without calling Codex.
-
 Primary auditor backend policy: Claude hooks automatically select Codex CLI when it is available on PATH,
 otherwise the Haiku-compatible path. Codex native hooks automatically select Codex CLI. An explicit
 `SPOTTER_AUDITOR_BACKEND` override wins on either host; runtime failure never triggers a hidden fallback.
@@ -343,14 +338,13 @@ Codex CLI auditor child processes use a versioned product policy. The production
 Spotter does not inherit a `latest` alias or the parent Codex default, and an invocation failure never retries another model.
 `SPOTTER_CODEX_CLI_MODEL` and `SPOTTER_CODEX_CLI_REASONING_EFFORT` can override
 the production values for controlled experiments; diagnostics mark overrides as unverified.
-`SPOTTER_AUDITOR_BACKEND=codex-sidecar` is available for explicit sidecar auditor smoke.
 
 ## Design docs
 
 - **Current design** (catalog, discovery, classification axes): [docs/01_catalog-design.md](https://github.com/kitepon/Spotter/blob/main/docs/01_catalog-design.md) — source of truth from v1.0.0
 - **Open issues + unverified concerns**: [docs/open-issues.md](https://github.com/kitepon/Spotter/blob/main/docs/open-issues.md) — read this before starting new work
 - **Runtime contract**: [docs/02_spotter-claude-contract.md](https://github.com/kitepon/Spotter/blob/main/docs/02_spotter-claude-contract.md) — Claude hook / daemon / Haiku contract plus Codex native hook policy
-- **Implementation invariants (§0)**: [AGENTS.md](https://github.com/kitepon/Spotter/blob/main/AGENTS.md) — no fallbacks, no silent failures, no provisional code (`CLAUDE.md` is only its import entry)
+- **Implementation invariants (§0)**: [AGENTS.md](https://github.com/kitepon/Spotter/blob/main/AGENTS.md) — no fallbacks, no silent failures, no provisional code
 - **Archived plans and history**: [docs/archive/](https://github.com/kitepon/Spotter/tree/main/docs/archive) — completed Codex rollout plans, primary backend smoke logs, and the frozen v0.1 design discussion
 
 ## Known limitations
@@ -367,7 +361,7 @@ the production values for controlled experiments; diagnostics mark overrides as
 - **Failures degrade loudly, never freeze the host** (v1.4.15) — this release stopped backend failure from silently erasing a prompt. Since v1.4.19, the non-blocking behavior remains but the old model-visible warning text is replaced by fixed `systemMessage`, stderr, and structured event diagnostics
 - **Plugin-scoped MCP servers** — names like `plugin:everything-claude-code:context7` (with internal colons) are now parsed correctly and their tools enter the catalog. Earlier versions silently collapsed all plugin MCP servers into a single literal `"plugin"`, dropping their tools from Claude's audit
 - **Per-project / per-host audit isolation** — the daemon audits against the local DB only; global DBs are host-specific description caches. Tools discovered in *other* projects or another host can never bleed into this project's audit set
-- **Zero-touch catalog** — `spotter install` seeds the Claude DB automatically; Claude and Codex SessionStart hooks keep their host-local DBs fresh in the background. You never have to maintain the tool list by hand
+- **Zero-touch catalog** — `spotter install` seeds each available host's DB. Claude, Codex, and Cursor refresh in the background; Grok waits for refresh before its first audit
 - **Codex native hooks** — Codex host uses Codex CLI as the primary auditor backend, keeps a separate `.spotter/tool-db.codex.json`, and surfaces backend failures explicitly instead of falling back to Haiku
 - **Audit scope** — only user-added surface (MCP servers / skills / sub-agents). Claude Code's built-in tools are intentionally out of scope; Claude already uses those reliably
 - **Implementation invariants** — no fallbacks, no silent failures, no provisional code (see [§0 in AGENTS.md](https://github.com/kitepon/Spotter/blob/main/AGENTS.md))

package/bin/spotter.mjs

@@ -7,9 +7,9 @@ import { runUninstall } from '../src/cli/uninstall.mjs';
 import { runDoctor } from '../src/cli/doctor.mjs';
 import { runStatus } from '../src/cli/status.mjs';
 import { runDbList, runDbRefresh, runDbRebuild } from '../src/cli/db-cmd.mjs';
-import { runCodexCommand } from '../src/cli/codex-cmd.mjs';
 import { runCodexHookCommand } from '../src/cli/codex-hook-cmd.mjs';
 import { runCursorHookCommand } from '../src/cli/cursor-hook-cmd.mjs';
+import { runGrokHookCommand } from '../src/cli/grok-hook-cmd.mjs';
 import { runAuditorCommand } from '../src/cli/auditor-cmd.mjs';
 import { runDiagnosticsCommand } from '../src/cli/diagnostics-cmd.mjs';
 import { runEvaluationCommand } from '../src/cli/evaluation-cmd.mjs';
@@ -62,16 +62,12 @@ Usage:
   spotter dashboard device --id ID [--name NAME] [--host HOST] [--port PORT] [--db PATH]
   spotter dashboard hub --config FILE [--host HOST] [--port PORT]
                                         serve the local device-routed evaluation dashboard
-  spotter codex risk-check --findings FILE
-                                        run read-only codex-sidecar risk analysis
-  spotter codex review|explore|opinion --findings FILE
-                                        run read-only codex-sidecar second-pass workflows
-  spotter codex work --findings FILE --approve-work --allowed-path PATH
-                                        run approved codex-sidecar worktree workflow
   spotter codex-hook install|uninstall|diagnostics
                                         (experimental) manage Codex native hooks
   spotter cursor-hook install|uninstall|diagnostics
                                         manage Cursor native catalog-refresh hooks
+  spotter grok-hook install|uninstall|diagnostics
+                                        manage Grok native audit hooks
   spotter auditor judge --stage STAGE --input FILE
                                         (experimental) run primary auditor backend once
   spotter auditor matrix --stage STAGE --input FILE
@@ -128,15 +124,15 @@ async function main() {
     case 'doctor':
       await runDoctor();
       return;
-    case 'codex':
-      await runCodexCommand({ argv: rest });
-      return;
     case 'codex-hook':
       await runCodexHookCommand({ argv: rest });
       return;
     case 'cursor-hook':
       await runCursorHookCommand({ argv: rest });
       return;
+    case 'grok-hook':
+      await runGrokHookCommand({ argv: rest });
+      return;
     case 'auditor':
       await runAuditorCommand({ argv: rest });
       return;

package/docs/11_dashboard-operations.md

@@ -5,9 +5,8 @@
 
 ## 固定構成
 
-各端末のdevice serverはloopbackだけで待ち受ける。main-server、Mac、FOX WSL2は
-`127.0.0.1:53940`、FOX Windows nativeはWSL2 localhost relayとの衝突を避けて
-`127.0.0.1:53944`を使う。main-serverのhubは
+各端末のdevice serverはloopbackだけで待ち受ける。main-serverとMacは
+`127.0.0.1:53940`、FOX Windows nativeは`127.0.0.1:53944`を使う。main-serverのhubは
 Docker Caddyから到達できる`172.18.0.1:53940`で待ち受ける。評価DBは各端末の
 `~/.spotter/evaluation.db`をその場で読み、端末外へ複製しない。
 
@@ -15,7 +14,6 @@ Docker Caddyから到達できる`172.18.0.1:53940`で待ち受ける。評価DB
 |---|---|---|
 | main-server Ubuntu | `main-server` | `127.0.0.1:53940` |
 | Mac | `mac` | `127.0.0.1:53941` |
-| FOX WSL2 | `fox-wsl` | `127.0.0.1:53942` |
 | FOX Windows native | `fox-windows` | `127.0.0.1:53943` |
 
 hub設定の正本は`ops/dashboard/hub-config.json`である。hubは一覧request時に各upstreamの
@@ -60,27 +58,6 @@ curl --fail http://172.18.0.1:53940/
 
 device envにも同じPATH行を置く。値は各端末で実測したnpm binを使い、別の起動経路へfallbackしない。
 
-## FOX WSL2
-
-device unitとtunnel unitを`~/.config/systemd/user/`へ配置する。device env:
-
-```ini
-SPOTTER_DEVICE_ID=fox-wsl
-SPOTTER_DEVICE_NAME=FOX-WSL2
-```
-
-tunnel env:
-
-```ini
-SPOTTER_REMOTE_FORWARD=127.0.0.1:53942:127.0.0.1:53940
-SPOTTER_TUNNEL_TARGET=main-server
-```
-
-```sh
-systemctl --user daemon-reload
-systemctl --user enable --now spotter-dashboard-device.service spotter-dashboard-tunnel.service
-```
-
 ## FOX Windows native
 
 同梱された`ops/dashboard/windows/`のPowerShellを固定pathへ配置する。npm global版から
@@ -163,6 +140,6 @@ reverse tunnelを確認する。hubや別端末を再起動する必要はない
 公開受入:
 
 1. 未認証`https://spotter.kitepon.dev/`がCloudflare Accessへredirectされる。
-2. 認証後の`/`が4端末を表示する。
+2. 認証後の`/`が3端末を表示する。
 3. online端末のoverview、project/tool内訳、非採用case、case詳細を表示できる。
 4. 1端末を停止しても一覧と他端末が表示でき、停止端末だけoffline/502になる。

package/ops/dashboard/hub-config.json

@@ -1 +1 @@
-{"devices":[{"id":"main-server","name":"main-server","upstream":"http://127.0.0.1:53940"},{"id":"mac","name":"Mac","upstream":"http://127.0.0.1:53941"},{"id":"fox-wsl","name":"FOX WSL2","upstream":"http://127.0.0.1:53942"},{"id":"fox-windows","name":"FOX Windows native","upstream":"http://127.0.0.1:53943"}]}
+{"devices":[{"id":"main-server","name":"main-server","upstream":"http://127.0.0.1:53940"},{"id":"mac","name":"Mac","upstream":"http://127.0.0.1:53941"},{"id":"fox-windows","name":"FOX Windows native","upstream":"http://127.0.0.1:53943"}]}

package/package.json

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

package/src/cli/auditor-cmd.mjs

@@ -10,7 +10,7 @@ const AUDITOR_USAGE = `spotter auditor — experimental primary auditor smoke co
 Usage:
   spotter auditor judge --stage user_input|turn_end --input FILE
                         [--project DIR] [--host-agent claude|codex|automation|unknown]
-                        [--backend jev|haiku|codex-cli|codex-sidecar|auto]
+                        [--backend jev|haiku|codex-cli|auto]
   spotter auditor matrix --stage user_input|turn_end --input FILE [--project DIR]
   spotter auditor model-matrix --fixtures FILE [--profile baseline|luna|terra|terra-medium]...
                                [--repeat N] [--project DIR] [--output FILE]
@@ -134,9 +134,7 @@ export async function runAuditorMatrixCommand({
 
 const AUDITOR_MATRIX_ROWS = Object.freeze([
   Object.freeze({ id: 'claude.codex-cli', hostAgent: 'claude', backend: 'codex-cli' }),
-  Object.freeze({ id: 'claude.codex-sidecar', hostAgent: 'claude', backend: 'codex-sidecar' }),
   Object.freeze({ id: 'codex.codex-cli', hostAgent: 'codex', backend: 'codex-cli' }),
-  Object.freeze({ id: 'codex.codex-sidecar', hostAgent: 'codex', backend: 'codex-sidecar' }),
 ]);
 
 async function runAuditorMatrixRow({
@@ -207,15 +205,11 @@ function summarizeMatrix(matrix) {
     total: matrix.length,
     success: matrix.filter((row) => row.status === 'success').length,
     error: matrix.filter((row) => row.status === 'error').length,
-    sidecarPrimaryAuditorImplemented: matrix
-      .filter((row) => row.backend === 'codex-sidecar')
-      .some((row) => row.status === 'success'),
   };
 }
 
 function recursionSafetyFor(backend) {
   if (backend === 'codex-cli') return 'spotter_parent_pid_backend_env';
-  if (backend === 'codex-sidecar') return 'spotter_parent_pid_sidecar_env';
   return 'unknown';
 }
 

package/src/cli/db-cmd.mjs

@@ -14,9 +14,9 @@ import { writeFile } from 'node:fs/promises';
 const DB_USAGE = `spotter db — manage the host-specific tool-db
 
 Usage:
-  spotter db list [--host-agent claude|codex|automation|cursor]
-  spotter db refresh [--host-agent claude|codex|automation|cursor]
-  spotter db rebuild [--host-agent claude|codex|automation|cursor]
+  spotter db list [--host-agent claude|codex|automation|cursor|grok]
+  spotter db refresh [--host-agent claude|codex|automation|cursor|grok]
+  spotter db rebuild [--host-agent claude|codex|automation|cursor|grok]
 `;
 
 function requireProjectRoot() {

package/src/cli/doctor.mjs

@@ -9,6 +9,7 @@ import { resolveJevApiKey, JEV_MODEL } from '../core/jev-backend.mjs';
 import { loadDb, globalDbPath, localDbPath } from '../tool-db/loader.mjs';
 import { findSpotterMarker } from '../hooks/lib.mjs';
 import { codexHookDiagnostics } from './codex-hook-cmd.mjs';
+import { grokHookDiagnostics, isGrokHomePresent } from './grok-hook-cmd.mjs';
 import { buildWindowsCompatibleInvocation, execFileWindowsSafe } from '../platform/spawn.mjs';
 
 const execFileP = promisify(execFile);
@@ -75,11 +76,18 @@ export async function runDoctor() {
     warnings += 1;
   }
 
-  if (projectRoot) {
-    const sidecar = await codexSidecarAuditorReadiness(projectRoot);
-    mark(sidecar.ok, `codex-sidecar auditor: ${sidecar.status}`, sidecar.detail);
-    if (!sidecar.ok) warnings += 1;
+  if (isGrokHomePresent()) {
+    try {
+      const grokHooks = await grokHookDiagnostics();
+      mark(grokHooks.installed, `grok native hooks: ${grokHooks.installed ? 'installed' : 'not installed'}`);
+      if (!grokHooks.installed) warnings += 1;
+    } catch (err) {
+      mark(false, 'grok native hooks', err.message);
+      warnings += 1;
+    }
+  }
 
+  if (projectRoot) {
     const auditorContext = await inspectAuditorContextConfiguration({ projectRoot });
     mark(auditorContext.ok, `evaluation context: ${auditorContext.mode}`, auditorContext.detail);
     if (!auditorContext.ok) warnings += 1;
@@ -87,7 +95,7 @@ export async function runDoctor() {
 
   // tool-db (host-specific global caches). Since v1.2.0 these are not part of
   // audit input; each host audits its project-local DB only. Empty caches are fine.
-  for (const hostAgent of ['claude', 'codex']) {
+  for (const hostAgent of ['claude', 'codex', ...(isGrokHomePresent() ? ['grok'] : [])]) {
     try {
       const path = globalDbPath(hostAgent);
       const global = await loadDb(path);
@@ -109,6 +117,12 @@ export async function runDoctor() {
     const codexDb = await checkLocalAuditDb({ projectRoot, hostAgent: 'codex' });
     mark(codexDb.ok, `codex local audit DB: ${codexDb.count} tools at ${codexDb.path}`, codexDb.detail);
     if (!codexDb.ok) warnings += 1;
+
+    if (isGrokHomePresent()) {
+      const grokDb = await checkLocalAuditDb({ projectRoot, hostAgent: 'grok' });
+      mark(grokDb.ok, `grok local audit DB: ${grokDb.count} tools at ${grokDb.path}`, grokDb.detail);
+      if (!grokDb.ok) warnings += 1;
+    }
   }
 
   console.log('');
@@ -232,42 +246,6 @@ async function checkLocalAuditDb({ projectRoot, hostAgent }) {
   }
 }
 
-async function codexSidecarAuditorReadiness(projectRoot) {
-  const args = ['diagnostics', '--project', projectRoot, '--preset', 'auditor', '--json'];
-  const cliPath = process.env.SPOTTER_CODEX_SIDECAR_CLI_PATH;
-  const cmd = cliPath ? process.execPath : 'codex-sidecar';
-  const finalArgs = cliPath ? [cliPath, ...args] : args;
-  try {
-    const invocation = buildWindowsCompatibleInvocation({
-      command: cmd,
-      args: finalArgs,
-      env: process.env,
-      allowCmdFallback: false,
-    });
-    const { stdout } = await execFileP(invocation.command, invocation.args, {
-      timeout: 15_000,
-      windowsHide: true,
-      maxBuffer: 1024 * 1024,
-    });
-    const parsed = JSON.parse(stdout);
-    const ok = parsed?.status === 'ok' && parsed?.normalizedRequest?.workflow === 'auditor';
-    return {
-      ok,
-      status: ok ? 'available' : 'unavailable',
-      detail: ok
-        ? `workflow=${parsed.normalizedRequest.workflow}, reasoning=${parsed.normalizedRequest.modelReasoningEffort ?? 'default'}`
-        : `unexpected diagnostics: status=${parsed?.status ?? 'unknown'}`,
-    };
-  } catch (err) {
-    const stderr = typeof err?.stderr === 'string' && err.stderr.trim() ? ` stderr=${err.stderr.trim().split('\n').slice(-1)[0]}` : '';
-    return {
-      ok: false,
-      status: 'unavailable',
-      detail: `${err.message}${stderr}`,
-    };
-  }
-}
-
 async function exists(path) {
   try { await access(path); return true; }
   catch { return false; }