v5.15.0

Added

• Add a self-contained Japanese product guide showing what to request and
  what results to expect. Keep model settings in expandable details and make
  the task flow readable on mobile screens.

Changed

• Describe current task execution, role defaults, manual model choices,
  progress reporting, and restart behavior in the English, Japanese, and Codex
  READMEs. Distinguish task-count progress from acceptance results.
• Route Claude deep-planning and advisor defaults to Fable 5.1/high and Codex frontier
  roles to GPT-6 astra. Keep lightweight workers and existing Codex role effort
  separate, and retain the isolated Sonnet security reviewer.
• Calibrate active workflow, agent, embedded CLI, and setup prompts around
  scoped outcomes, recoverable inputs, independent delegation, and observed
  completion evidence. Preserve required checks, review limits, and permissions.

Fixed

• Keep handoff timestamps numeric during session initialization and resume
  on both GNU and BSD systems, so Linux can restore structured handoffs.
• Isolate advisor configuration regression tests from the operator's active
  settings while continuing to verify explicit project model choices.
• Normalize supported working-directory aliases before native companion
  dispatch so reviews inspect the requested project.
• Deliver large plan context and worker status through input streams, avoiding
  operating-system argument limits while retaining full evidence and bounded summaries.
• Bind the managed Codex reviewer profile during setup so an existing default inline
  role cannot silently shadow its model and instructions. Preserve custom
  role bindings and distinguish native permission inheritance from companion
  read-only review execution.
• Preserve explicit Codex model and effort through companion dispatch, including
  Codex ultra, without prompt-based effort calculation replacing role settings.
• Resolve advisor defaults for the target project and preserve its explicit
  model choice instead of reading configuration from the installed plugin.
• Keep task execution and the primary-environment guard on the same working
  directory and write intent; reject unsupported config overrides and extra
  writable roots before dispatch.
• Include the runtime helpers required by advisor and loop execution in the
  Claude and Codex plugin packages.
• Carry the selected plan, completion criteria, concrete failure evidence, and
  prior advice through loop worker and advisor dispatch, including restart.
• Preserve Go worker task descriptions and review refinements, and make the
  opt-in review verdict contract explicit instead of accepting an APPROVE
  substring in contradictory text.
• Include task completion criteria, inferred scope, exclusions, and reviewer
  notes in browser review instructions without changing its schema or routes.

v5.14.1

Fixed

• secret-read floor: ~/ vs absolute allowlist, and write-only cat >:
  HARNESS_RUNTIME_FLOOR_SECRET_ALLOW compared command tokens and declarations
  as raw strings, so a declared /Users/<home>/LocalWork/ missed
  ~/LocalWork/.../.env. Matching now expands a leading ~/ on both sides
  (process home directory). That is spelling normalization, not a wider
  allowlist. Bare ~ / ~/ stay invalid. $HOME and ~user are not
  expanded. Separately, cat > file / cat >> file / cat > file <<EOF
  with no input file was treated as a read verb, so a later
  AISDR_ENV_FILE=.../.env bash script in the same Bash string was denied.
  Write-only cat is no longer a secret-read verb. cat FILE,
  cat FILE > out, cat FILE>/out, cat > out FILE, and cat < FILE
  still deny. &> / &>> are treated as redirections, not job separators,
  so cat > out &> /dev/null .env still denies.

v5.14.0

Added

• Deferred-ops approval flow (bin/harness deferred) + progress surface queue (Phase 140.2):
  the operator side of destructive_delete=defer. bin/harness deferred list shows the
  pending entries of .claude/state/deferred-ops.jsonl with a copy-paste approve command;
  bin/harness deferred approve <id> flips the single pending line with that id to
  approved, and the guardrail then lets the next identical run through exactly once
  (approved → consumed, one-shot consume — same shape as plan preapproval — with an
  R05_DEFER_APPROVED advisory message and a policy: defer record in
  destructive-delete.jsonl). Un-approved entries keep denying; after the approval is
  spent the same command denies and re-queues again. No "approve all", no auto-approval
  path. The progress surface gains an additive deferred_ops_pending section
  (progress-snapshot.v1) listing pending deletions with their approve commands
  (same shape as the Phase 136.2 writing-lint queue).
  Review follow-up (independent reviewer findings, both fixed pre-merge): (1) the
  "operator-only" boundary is now enforced, not just documented — new guardrail rule
  R16:no-self-approve-deferred denies agent Bash invocations of
  harness deferred approve (list stays allowed), and deferred-ops.jsonl /
  destructive-delete.jsonl joined the R02/R03 protected-path deny set so an agent
  cannot forge "status":"approved" lines (interpreter writes remain a documented
  residual, same class as the R05 symlink residual); approve stamps approved_by.
  (2) recordDeferredOp's dedup-check + append now runs under the same file lock as
  the approve/consume flips, closing a lost-write / duplicate-pending race. R05
  (defer deny) and R16 joined the deny-surface baseline and rule-coverage pins.

• destructive_delete: defer (Phase 140.1、無人 run の ask 停止対策): R05 (rm -rf / find -delete) で warn なら ask になる場面 (root 外の綴り・..・未解決 $VAR・glob・素の .) を、ask の代わりに deny + 行動契約 に置き換える設定値。deny は run を止めず (エージェントに理由が返り続行する)、操作は .claude/state/deferred-ops.jsonl に 1 行 (id / timestamp / session_id / agent_id / cwd / command / rule_id / policy / reason / status: pending) 積まれる。同一コマンドの再試行は deny のままキューに重複しない。warn が通す場面は defer でも warn のまま (allow + destructive-delete.jsonl 記録)。既定は引き続き warn。設定は harness.toml [safety.permissions] destructiveDelete / .claude-code-harness.config.yaml safety.destructive_delete / env HARNESS_DESTRUCTIVE_DELETE_POLICY。承認 CLI は 140.2 の bin/harness deferred で追加済み

場面	ask (opt-out)	warn (既定)	defer (新設)
削除対象が agent 所有と静的に証明できる	allow	allow	allow
相対 / root 配下の綴りだが前置コマンドあり	ask	allow + warn 記録	allow + warn 記録
root 外・..・$VAR・glob・素の .	ask	ask	deny + キュー (run は止まらない)

実効性契約: tests/test-r05-destructive-delete-policy.sh に実バイナリ probe 4 本 (deny + キュー 1 行 / 再試行で重複なし / warn 経路の回帰なし) を追加 (修正前 RED、修正後 GREEN)。Go 側は go/internal/policy と go/internal/guardrail に 10 本追加

v5.13.2

Fixed

• 配布経路の修理: SessionStart の scripts/sync-plugin-cache.sh が plugin cache と marketplace 複製を壊していた。他プロジェクトで claude plugin list が Agents (0) になり、claude plugin update が 5.13.1 を見つけられなかった原因は Claude Code ではなく CCH 自身の hook script (2026-08-29 に旧 script を空の HOME で走らせて再現)。

継ぎ目	変更前	変更後
版ごとの cache dir	まだ入っていない版の dir を同期分 (hooks / skills / scripts / output-styles / VERSION) だけで先に作る。Claude Code は後で既にある dir をそのまま使うので、agents / bin / templates の無い plugin になる (5.8.0 / 5.9.0 / 5.13.0 / 5.13.1)	既に入っている版だけ更新し、無ければ作らない
marketplace 複製の版	別 worktree の VERSION / plugin.json を複製へ書き戻す。claude plugin update は複製の plugin.json を最新判定に使うため「5.13.0 が最新」と答え、5.13.1 が入らない	複製の git HEAD が同じ版のときだけ同期し、VERSION / plugin.json / marketplace.json は書かない
複製の private path 削除	tracked の docs/research/* を削除し、複製の git を恒久 dirty (21 件の D) にする	削除は cache 側のみ
agents/	同期対象外	critical_dirs に追加 (既に入っている cache の欠けも埋まる)

契約テスト 4 本を tests/test-sync-plugin-cache.sh に追加 (旧 script で RED、修正後 GREEN)。manifest (plugin.json) と Go の生成コードは変更なし。agents/ は宣言なしで自動発見される。

Changed

• 同期レポート docs/reports/2026-08-27-harness-sync-status.html を追加 (docs): harness-sync の結果 (Plans.md と git のズレ 0 件、Phase 134〜142 の 49 task 中 32 完了) と配布欠けの判断材料。初版の推定「CC が manifest 宣言の部品だけ複製する」は上記の再現で否定されたため改訂済み。Plans.md に Phase 143 (この hotfix) を追加し、次スプリント順 143 → 140 → 142 → 138 を記録 (operator 裁定 2026-08-29)。判断の記録は .claude/memory/decisions.md D72

v5.13.1

Changed

• Plans.md: 2026-08-24 設計レビューの結論を反映。Phase 140（無人 run の ask 序盤停止対策）を次スプリントの最優先に明記し、Phase 142（記憶パイプライン修理・注入棚卸し・日本語 lint 辞書 seeding・ルール引退提案・native 機能重複点検、7 task。レビュー時の作業名は Phase 141 だったが、同時並行で main へ shipped したセッション協調パイプライン Phase 141 との番号衝突により着地時に Phase 142 へ改番）を新設。裏付けの 2 件の判断材料 HTML（2026-08-24 ハーネス設計レビュー、2026-08-26 Phase 140/141 追記レビュー）を docs/reports/ に追加し索引を更新

v5.13.0

Added

セッション協調パイプライン (Phase 141)

同じ PC 上の複数セッション (Claude Code / Codex / Cursor / Grok / hermes) が互いを名簿で見て、直接メッセージを送れるパイプラインを通しました。何に使うかは利用者に委ねる土台であり、送信の検証は既定オフです。

継ぎ目	変更前	変更後
名簿の寿命	Stop で presence を削除。Stop はターン境界なので、生きているセッションが最初の 1 ターン後に名簿から消えていた	削除は SessionEnd、Stop では mtime を更新。セッションが続く限り名簿に載り続ける
名簿の更新	SessionStart の 1 回のみ	毎ターン更新。refresh は mtime だけを触るので session declare の task/label は保持される
身分証	HARNESS_LIVEMSG_TEAM / ..._AGENT を読む側だけ存在し、書く側が誰もいなかった	hook session-register が CLAUDE_ENV_FILE へ export 形式で書き出す (素の KEY=VALUE は子プロセス env に届かない)。deliveryidentity.Resolve() の優先順位は不変
broadcast の届く範囲	presence は worktree 横断で共有、broadcast だけ worktree ローカル。姿は見えるのに通知が届かなかった	broadcast も git-common-dir 親の共有 scope へ統一
harness-mem との同居	active.json を自スキーマ決め打ちで読み、他ツールのエントリを 24h prune で削除していた	map[string]json.RawMessage で読み書きし、知らないエントリは触らず保持

• エージェント主導の送信: skills/session-send/SKILL.md を追加。bin/harness inbox send --team/--from/--to/--subject を案内し、送ってよいもの (完了通知 / これから触る場所の宣言 / 引き継ぎ) と送らないもの (作業中の相談 / 推測) を線引きする。根拠は CooperBench の測定 — 同一ファイルを 2 エージェントが触ると成功率が単独の約半分に落ち、失敗の 63% が相手の変更についての誤った思い込みだった
• 検証の関所 (opt-in、既定 off): [livemsg] verification = "off" | "on" を追加。解決は destructiveDelete と同じ 5 段 (env / project YAML / project harness.toml / plugin harness.toml / 既定)。off の間は送信経路が gate を呼ばないため、検証を使わない利用者にコストがかからない。on では機械チェック (ファイル実在 / commit 実在 / git status との一致) が判定を担う。機械で判定できない主張の委譲先として read-only agent の口 (Reviewer interface + agents/livemsg-gate.md) を用意しているが、本実行経路にはまだ接続していない。判定役が未設定のときは HOLD にせず not_observed を記録して機械チェックの結果を通す (判定役の不在は判定ではない。ここで止めると「テストが成功しました」のような完了通知が全て止まり、パイプラインの目的そのものを壊す)。HOLD は宛先へ 1 件も届けず、理由を送信側に返す (templates/schemas/livemsg-gate.v1.json)
• hermes を 5 ツール目として追加: hosts.toml に [hermes] を追加。hermes は ~/.hermes/config.yaml の YAML 宣言型のため hook ファイルは生成せず、turn delivery のみ配線
• 配線検証: scripts/ci/check-session-pipeline-wiring.sh (7 点) を tests/validate-plugin.sh に配線 (配線前 RED 実測済み)

Fixed

Phase 141 のレビューゲートが見つけた 5 件。いずれも「呼び出しは書かれているが、その結果が上の層で捨てられている」という同じ形をしていました (D58「配線した != 効いている」)。

• 検証 gate の verdict が捨てられていた: 送信経路が gate を呼びながら戻り値を無視していたため、HOLD を返しても配送されていた。verdict で分岐し、理由を送信側へ返す
• 検証 on が通常のメッセージを弾いていた: パス判定が「ドットを含むトークン」を全てファイル名とみなしていたため、Go 1.24.0 や alice@example.com を含む完了通知が HOLD になっていた。スラッシュを含まない綴りは既知の拡張子を要求する
• hermes の delivery がどこにも出力されていなかった: harness gen が enforcement hook の「生成保留」で先に return し、delivery 生成に到達していなかった。hosts.toml に宣言はあるのに実出力ゼロ。保留は enforcement だけに限定し、requires_home_path で未インストールのホストは明示的にスキップする
• メッセージの宛先を特定できなかった: session list に team / agent 列が無く、session-send skill はそれを読めと案内していた。breezing 実行中は agent が BREEZING_ROLE で session_id と一致しないため、案内どおりに送るとエラーも出ないまま未達になっていた。presence card が解決済みの identity を持ち、名簿がそれを表示する
• presence card の新フィールドが serialize 時に落ちていた: encodePresenceCard が Label / Task / Since しかコピーしておらず、追加した Team / Agent が黙って捨てられていた

配線チェック scripts/ci/check-session-pipeline-wiring.sh は、上記 3 件目を検出できませんでした (設定文字列の存在しか見ていなかった)。実バイナリを走らせて実出力を検査する形に変更しています。

v5.12.0

Added

• Codex Breezing の実装 Worker を gpt-5.6-luna / max に統一。Codex-native の breezing は setup が配置する managed custom agent worker.toml を選び、breezing --codex は中央の worker route を解決する。公式 companion 1.0.6 が受け付けない max は Harness が raw codex exec の reasoning config へ変換する。reviewer / advisor / deep は従来どおり gpt-5.6-sol / xhigh のまま
• Codex review に Sol/xhigh を確実に適用し、中断時の残留 process を防止。review ごとの local proxy が model / review_model / model_reasoning_effort を codex app-server へ渡し、official companion の結果形式を保持する。review --commit は provider dispatch 前に拒否し、成功した delegation だけを ledger に記録する。TERM/INT は companion と proxy へ同時転送し、最大 1 秒待機後に残存 child を KILL/reap する

Changed

• Codex setup と host distribution の安全境界を追加。local/remote setup は preflight 後に、Harness 所有の legacy [notify] 2 形態だけを backup + atomic migration する。custom/ambiguous shape は no-mutation fail とし、features.multi_agent と features.default_mode_request_user_input を欠落時に追加する。Claude/Codex dist は worker/reviewer profile と review runtime-helper closure を同梱し、Codex dist は fingerprint 実行に必要な Harness platform binaries も含める。primary-environment guard が拒否した task は provider 起動前に止め、成功 delegation の ledger に数えない
• README の Codex 導入説明を実効経路に同期。英語・日本語のトップ README と codex/README.md に、更新後の setup 再実行と Codex 再起動、Worker の Luna/max、Reviewer の Sol/xhigh、メインセッションと明示 backend は固定対象外という境界を追加する
• Harness release の公開手順を tag-triggered workflow に統一。古い直接 Release 作成・編集例を削除し、CHANGELOG を本文として公開する workflow と公開後の検証コマンドを正本にする

Verification boundary

• Windows named-pipe path は fixture/static checks のみで、live Windows provider/app-server は未観測。今回の実装は provider/API 呼び出し、実 HOME 変更、live install を行わない

v5.11.0

Changed

• guardrail R05: destructive_delete の既定値を ask → warn に変更 (operator 裁定 2026-08-22)。未設定のプロジェクトでも、静的に検証できない削除は「確認で停止」ではなく「allow + R05_WARN 警告 + .claude/state/destructive-delete.jsonl 記録」になる。root 外の綴り・..・未解決 $VAR・glob・素の . の常時 ask backstop と runtime floor は不変。従来挙動に戻すには repo の harness.toml の [safety.permissions] セクションに destructiveDelete = "ask" (または yaml safety.destructive_delete: ask)。明示された不正値は従来どおり ask に正規化 (fail-safe)。git 外の消えたら困るデータを root 配下に持つ repo と guardrail 開発時は ask への opt-out を推奨

v5.10.0

Added

• guardrail R05: destructive_delete = ask | warn (HOTL opt-in)。rm -rf / find -delete の対象を静的に「agent 所有」と証明できないとき (cd 後の相対パス、前置コマンドあり) は従来どおり既定 ask。warn を選ぶと、綴りが project root 配下 / 自セッション scratch / 相対の削除は確認なしで通し、R05_WARN 警告を注入して .claude/state/destructive-delete.jsonl に記録する (事後レビュー用)。root 外の綴り・..・未解決 $VAR・glob・素の . / / は warn でも ask のまま (HOTL 契約 invariant 3 の blast-radius backstop)。warn の approve は advisory 扱いで、同一 compound command が後続 deny/ask ルール (R06 force-push / R08 reviewer no-write / R10 / R11 / R12) にも該当する場合はそちらが常に勝つ (bot review 指摘の precedence 欠陥を修正)。設定は .claude-code-harness.config.yaml safety.destructive_delete / harness.toml [safety.permissions] destructiveDelete / env HARNESS_DESTRUCTIVE_DELETE_POLICY。133.10 の symlink 残余リスクは warn 下で意図的に受容 (既定は不変)。契約テスト tests/test-r05-destructive-delete-policy.sh (実バイナリ probe) を validate-plugin.sh に配線

Changed

• release: plugin tag ({plugin-name}--v{version}) を廃止し semver tag vX.Y.Z に一本化 (D69)。marketplace.json の source が相対パスで install は tag を参照しないため実効性が無く、v5.6.0 以降 3 リリース連続で欠番のまま実害が無かった。harness-release の手順・test pin を実態に合わせた。既存の claude-code-harness--v5.5.0 以前の tag は履歴として残す
• README.md / README_ja.md を再構成し重複を削減: 「The loop」のコマンド表とステージ表を 1 表に統合、Documentation 表からバッジ / Install by tool 表にすでに張ってあるリンク (Claude Code compatibility、Cursor integration) を除去。ピン済みの tier 表記・見出し・文言はすべて維持 (tests/test-readme-product-surface.sh 等 144/144 green)

v5.9.0

Added

検証チェーン配線修理 — HOTL 本実装 (Phase 134)

検証機構の継ぎ目 3 箇所を接続し、「やった体」の緑を潰しました。

継ぎ目	変更前	変更後
入口	reviewer_profile は常に既定 static (LLM 読解のみ)	risk_flags から自動昇格 (security-sensitive→runtime / ux-regression→browser)。--approve 時の ratchet が無言降格を exit 5 で拒否
中間	browser 検証が環境不足で PENDING_BROWSER に無言縮退し緑のまま	pending_validations として review-result に記録 (fail-visible)
出口	Accept の evidence は LLM の再申告	scripts/accept-collect-evidence.sh が実行 artifact (worker-report / review-result / runtime-review / browser-result) を機械読みし引用。pending 該当 criteria は passed: false になり recommendation は ship にならない

• scope leash (Phase 101 U0 spike) を本配線: sprint-contract に declared_scope を焼き込み、PreToolUse で圏外 Write を検査 ([scope_leash] enforce_level = off|warn|enforce、既定 warn)。DroppedScope は Stop で advisory 通知
• Playwright Screencast を browser evidence として収集し (artifacts[].kind: video)、Accept HTML に埋め込み。録画なしは縮退規則つき (kind: text + note)
• worker-report.v1 を .claude/state/review/<task-id>.worker-report.json へ永続化 (従来はプロンプト内報告のみでファイル不在)
• harness-plan / harness-review に再調査ステップ 1 回 (圏外の別系統案も 1 つ検討) を追加
• 検証の検証: scripts/ci/check-verification-chain-wiring.sh + 実効性契約テスト 3 本を tests/validate-plugin.sh に配線 (配線前 RED 実測済み)

日本語 writing lint (Phase 135)

• go/internal/writinglint/: NG パターン辞書 (JSONL、個人層 ~/.claude/writing-lint/rules.jsonl) + 文書集計検査 (文末 3 連続 / 敬体常体混在)。エンジンは repo、辞書は個人層 (D64)
• PostToolUse writing-lint: .md/.txt 書き込み直後に照合し「該当文を丸ごと書き直し + グッドパターン」を advisory 返却 (既定 off、writing_lint.enabled で opt-in)
• Stop writing-lint-stop: セッション終了時に変更 .md を全体再検査、severity: major 残存で 1 回だけ block (再入は警告のみ)
• 指摘→ルール登録ループ: skills/japanese-writing-drafter が proposal を自動ドラフト、昇格は scripts/writing-rule-approve.sh (人間 CLI のみ、自動昇格経路なし)
• claude-code-harness.config.schema.json に writing_lint と既存非公式 quality_pack を正式収録

surface チェリーピック (Phase 136) / ループエンジニアリング施策 (Phase 137)

• accept / plan-brief / progress の 3 surface にスマホ viewport + レスポンシブ CSS
• progress surface に writing lint 承認待ちキュー表示 (コピペ用 approve コマンド)
• diagram-design plugin の接続点 1 文 (インストール済みなら図描画に使う)
• 採点設計規律 (skills/harness-plan/references/criteria-design.md): DoD を「機械○×の床 / LLM 観点 / 本質 doc」の 3 層に翻訳
• blind 受け手検査: Accept 直前に採点基準を渡さない fresh 評価者で乖離を測る optional step (説得系/文書系のみ)
• 評価者 4 契約を agents/reviewer.md に明文化 (fresh context / 基準書き換え禁止 / 絶対評価 / 実物を開く)
• Worker 契約に NG-4 (一時領域の掃除で operator を停止させない) を追加

Fixed

session-log の分割警告が、移動できるエントリが 1 件も無い状態でも出続けていた問題

今まで: 警告は行数だけを見ていました。一方 /maintenance が実際に退避できるのは「直近 30 日より古いエントリ」だけです。全エントリが 30 日以内に収まっていると、警告は出るのに移動対象が 1 件も無い状態になります。従えば保持ルール違反、従わなければ毎回警告という詰みでした。

上限を 500 から 600 へ引き上げる手当ても行いましたが、数日で 688 行に到達して再び超過しました。数字を動かしても、不一致が起きる位置がずれるだけです。

今後: 発火条件を「行数超過 かつ 退避できるエントリが 1 件以上ある」に変えました。警告が出たら必ず対処できます。

状況	変更前	変更後
688 行 / 全エントリが 30 日以内	警告あり (対処不能)	警告なし
上限超過 / 古いエントリあり	警告あり	警告あり
上限内	警告なし	警告なし
日付が解析できない見出し	(判定なし)	退避可能として数える

日付が読めない見出しを「新しい」ではなく「退避可能」として数えるのは、解析が壊れたときに警告が黙って消えるのを避けるためです。上限そのものは 600 行のまま変えていません。

対処できない警告は無視される警告になり、他の警告の信用を削ります (patterns.md P43「承認され続ける ask は制御ではない」と同じ構造)。

追記専用の状態ファイルが、規約の対象外のまま増え続けていた問題

今まで: /maintenance の state トリム規約は agent-trace.jsonl と harness-usage.json だけを名指ししていましたが、どちらもこのリポジトリに存在しません。一方で実際に育っていたファイルは対象外のままでした。存在しないファイルを守る規約は、守っているつもりで何も守っていません。

今後: 名指しを実在ファイルへ合わせ、保持行数を実測から決めました。

ファイル	変更前	変更後
orchestration-ledger.jsonl	規約の対象外 (3,009 行 / 520KB)	末尾 2000 行
instructions-loaded.jsonl	規約の対象外	末尾 2000 行
session-events.jsonl	規約の対象外	末尾 2000 行
changed-files.jsonl	規約の対象外	末尾 2000 行
agent-trace.jsonl	末尾 1000 行	末尾 1000 行 (存在する場合のみ)

2000 行の根拠は実測です。30 日で 3,009 行、平均 約100 行/日、繁忙日は 614 行。平常時なら 約20 日分、繁忙が続いても直近 1 週間は残ります。日数ではなく行数で切るのは、日付項目の有無がファイルごとに違うためです。

サブディレクトリから呼ばれた tool は、プロジェクトの保護設定が丸ごと効かない場所で判定されていた問題 (Phase 133.11)

今まで: guardrail は hook が受け取った作業ディレクトリを、そのままプロジェクトルートとして扱っていました。そのためサブディレクトリで実行された tool は、そのサブディレクトリを「プロジェクト」とみなして判定されます。実測すると、同じセッション・作業モード ON でも、リポジトリ直下からの削除は通るのに go/ からの同じ削除には確認が出ました。作業モードの状態がリポジトリ直下にしか無く、go/ を見に行って見つけられないためです。

影響は作業モードだけではありません。保護パス判定・事前承認・TDD 設定もすべてプロジェクトルート基準なので、サブディレクトリ実行時は保護が効かない側にずれていました。痕跡として go/.claude/state/ と benchmarks/breezing-bench/agent-eval/.claude/state/ が残っており、どちらも状態ファイルだけで設定もルールも含まないことから、誤った解決が作った産物だと確認できます。

今後: .harness か .git を持つ最も近い上位ディレクトリまで遡ってプロジェクトルートを決めます。マーカーが無ければ従来どおりそのディレクトリのままです。

項目	変更前	変更後
<repo>/go からの tool 呼び出し	ルート = <repo>/go	ルート = <repo>
作業モード ON + サブディレクトリからの削除	確認あり	確認なし
作業モード OFF (対照)	確認あり	確認あり (変更なし)
保護パス判定の基準	呼び出し位置	プロジェクトルート

.claude はマーカーにしていません。この不具合が作った状態ディレクトリが自己確証してしまい、一度 tool を呼んだ場所にルートが固定されるためです。探索はホームディレクトリで止めます。プロジェクトルートは「確認なしで削除してよい範囲」でもあるため、dotfiles リポジトリの ~/.git を拾うとホーム全体が許可範囲になってしまいます。

保護パスへの書き込みが、リダイレクト以外の手段では素通りしていた問題 (Phase 133.12)

今まで: Bash からの書き込み検査はリダイレクトと tee しか見ていませんでした。実測した 8 手段のうち検出できていたのは 2 つだけです。

手段	変更前	変更後
echo x > <保護パス>	拒否	拒否
tee <保護パス>	拒否	拒否
ln -sf src <保護パス>	素通り	拒否
ln src <保護パス>	素通り	拒否
cp src <保護パス>	素通り	拒否
mv src <保護パス>	素通り	拒否
install src <保護パス>	素通り	拒否

今後: 宛先を最後の引数に取るコマンド (ln / cp / mv / install) をまとめて検査対象にしました。指摘は ln -s だけを挙げていましたが、それだけ塞いでも同じことができる経路が 3 つ残ります。取るのは最後の引数だけで、これにより install -m 755 の 755 を誤ってパスと読む事故も同時に防げます。引数が 1 つだけの形は、生成先がシェルの作業ディレクトリになり確実に特定できないため対象外です。

release preflight の host plugin dist gate が grok 配布物の意図した中身を FAIL と誤判定していた問題

grok 配布物には guardrail を動かすための .claude-plugin/plugin.json / hooks/hooks.json / bin/harness が意図的に同梱されています (Phase 133.8)。テスト側の期待値がこの変更に追随しておらず、release-preflight.sh の host plugin dist gate が同梱以降ずっと FAIL していました。期待値を実装済みの契約 (3 ファイルの存在確認) に合わせました。

Changed

依存関係を更新しました。Go 側の 2 件は、同梱バイナリがソースと依存から byte 単位で再現できることを検証する drift gate があるため、bump と同じ変更で 4 プラットフォームのバイナリを再生成しています。

依存	変更
modernc.org/sqlite	1.55.0 → 1.56.0 (modernc.org/libc 1.74.1 → 1.74.4、github.com/mattn/go-isatty 0.0.20 → 0.0.24 を伴う)
github.com/santhosh-tekuri/jsonschema/v6	6.0.2 → 6.0.3

grok の native hook を配線した (Phase 133.8)

今まで: grok 向けの配布物には hook が 1 つも入っておらず、hook ファイルの生成も「未対応のホスト」として失敗していました。判定エンジン自体は --host grok で正しく動いていたのに、そこへ到達する経路が無い状態です。

今後: 配布物に hook を同梱し、生成器に grok を追加しました。実機で確認できています。

項目	変更前	変更後
配布物の hook	同梱なし	hooks/hooks.json (27 イベント)
harness gen の grok	"unknown host" で失敗	.grok/hooks/harness-pretool.json を生成
生成コマンドのホスト指定	(生成されない)	--host grok を明示
grok が読み込む hook 数	35	36 (新規は project 由来の 1 件)

これは設定ファイルに残っていた「grok はプロジェクト単位の hook を拒否する」という記述を実測で覆します。その記述の出典は同名の別製品 (TypeScript 版) で、実際に動いているものとは系統が異なりました。能力を語る前に、実際に動くバイナリのバージョンを取るという原則をあらためて適用しています (今回も版が 0.2.118 から 1.0.3 へ動いていました)。

配布物経由の hook は、プラグインを入れ直すまで検証できないため未確認のまま残しています。設定ファイルに未確認事項として記録しました。

並列実行数の上限を明記した (Phase 133.9)

--parallel N は希望値で、実際の同時実行数は Claude Code 側が決めます (既定 20、超過分は待ち行列に入るだけでエラーにはなりません)。入れ子の起動は既定で深さ 3 までです。この関係を breezing と harness-work の説明に追記しました。ハーネス側では環境変数を明示設定せず、Claude Code の既定に従います。上書きすると本体側の更新に追随できなくなるためです。