v5.7.0

Fixed

work-mode の session 識別子が実 ID と一致せず配線が無効だった問題 (Phase 132.7)

今まで: harness work-mode on は .claude/state/session.json の内部生成 ID で work_states 行を書いていました。guardrail hook は Claude Code が渡す実 session_id で行を引くため、両者は一致せず、書いた行は一度も読まれませんでした (132.3 の blocked 理由)。さらに SessionStart の env handler が CLAUDE_ENV_FILE へ KEY=VALUE (export なし) で書いており、公式仕様の export KEY=VALUE 形式でないため、書いた値が Bash ツールの環境に届いていませんでした (実測: 稼働セッションの printenv に HARNESS_VERSION が現れない)。

今後: SessionStart env handler が payload の実 session_id を export HARNESS_SESSION_ID='<id>' として書き出します (全行 export 化 + quote + resume 再発火の重複防止)。work-mode の解決順は --session-id フラグ → HARNESS_SESSION_ID env → .claude/state/last-session-id.json (UserPromptSubmit ごとに実 ID を記録、鮮度 2 時間) で、旧 session.json は受理を拒否します。SessionEnd で work state を解除し、24h TTL が背止めになります。実 session_id (独立ソース由来) での実測で on 前 ask → on 後 skip → 他 session 非波及 → off / SessionEnd で復帰の 6 系統を確認済み。CC が env file を Bash 環境へ反映する最終リンクのみ、リリース後の新セッションで要確認です。

R07 (codex mode) / R08 (breezing reviewer) が一度も発火できなかった問題 (Phase 132.6)

今まで: shell 版ガードは .claude/state/breezing-session-roles.json (role) と .claude/state/breezing-active.json の impl_mode (codex mode) をファイルで解決していましたが、Go 移行時にこの 2 経路が欠落し、env 参照だけが残りました。env を設定する仕組みは存在しないため、R07 (codex mode 中の直接 Write 禁止) と R08 (レビュー担当の書き込み禁止) は実装とテストを持ちながら本番で一度も発火していませんでした (2026-08-11 実測)。

今後: ファイルベース解決を guardrail/breezing_state.go として移植しました。R08 は roles ファイル (agent_id → session_id の 2 キー lookup) に加え、breezing 実行中の reviewer subagent を CC が付与する agent_type で直接判定します。role 自己登録 (breezing-role-*.json への Write を捕捉) も移植し、登録キーは hook payload 由来のみ (書かれた内容から他セッションへ role を付与できない)。R07 は impl_mode=codex と work-mode on --codex の両方で立ち、委譲先の codex host 自身は対象外です。R08 には shell 版と同じ .claude/state/ 書き込み例外があり、reviewer が自身の verdict artifact を書けます。

4 視点並列レビューが摘出した 2 件の欠陥 (132.6 実装の初版に対する修正)

上記 132.6/132.7 の実装は、コミット前の 4 視点並列レビュー (regression / security / effectiveness / consistency、稼働バイナリへの実プローブつき) で critical 2 件が見つかり、修正済みです。

1. R08 の state 例外が path traversal でバイパス可能だった: 初版の .claude/state/ 例外は素の substring 判定で、<root>/.claude/state/../../src/x.ts のような file_path が例外に落ちて reviewer が任意ファイルへ書けました (実測でバイパス成立を確認)。Clean 済みパスの封じ込め判定 (filepath.Rel ベース) へ置換し、traversal 3 形の回帰テストを追加しました。
2. agent_id / agent_type が実配線 (hookcodec.Normalize) で落ちていた: 新設フィールドを codec の rawPayload が拾っておらず、reviewer subagent の CC-native 判定が wire 上で死んでいました (unit テストは hand-built input で green のまま — 「unit は通るが wire が繋がっていない」型)。Normalize に両フィールドを追加し、raw JSON → codec → guardrail を通す wire round-trip テストを追加しました。

さらに修正版に対する敵対的再検証 (refuter 3 体) を回し、上記 1・2 の修正がそれぞれ別経路で破れることを実証されたため再修正しました。

3. R08 の state 例外が symlink 経由で破れた: traversal (..) は塞げていましたが、reviewer が ln -s で .claude/state/escape → <project>/src を作り、その経由で任意ファイルへ書ける経路が残っていました (実測で 2 ステップとも approve)。判定を lexical 封じ込め と filepath.EvalSymlinks による物理封じ込めの二段にし、あわせて R08 の禁止コマンドへ ln / tee を追加しました (パターンは 4 → 6 の純増。削除・緩和はゼロ)。self-audit の deny-surface baseline は R08 の 1 行のみ再生成し、他 9 行が不変であることを確認しています。
4. role 自己登録が session_id へ fallback して Lead を巻き添えにしていた: agent_id を持たないペイロードで登録すると session_id キーで書かれ、同じ session を共有する Lead 自身の Write まで reviewer と判定されて全滅する経路が残っていました (実測で再現)。登録キーを agent_id のみに限定しました。CC は subagent の tool call に必ず agent_id を付けるため正当な登録は通り、main thread は自分を reviewer にできません。worktree で spawn された teammate は独立セッションなので、従来どおり spawn 時の env を使います。

エージェント自身の記憶ディレクトリへの書き込みで R04 が毎回確認を出していた問題 (Phase 132.1)

今まで: R04:confirm-write-outside-project は、プロジェクトルート外への Write / Edit / MultiEdit に確認ダイアログを出します。ところが Claude Code はエージェントに ~/.claude/projects/<slug>/memory/ への記憶の保存を指示しており、この書き込みがそのまま R04 に当たっていました。3,099 セッションのログを走査したところ、R04 の発火は 1,099 件で全確認機構の最多、うち 299 件がこの記憶ディレクトリ、14 件が ~/.claude/plans/ でした。危険性がないにもかかわらず承認され続けた確認で、残る確認の信号価値を下げていました。

今後: shellscan.IsAgentStatePath を新設し、~/.claude/projects/<slug>/memory/** と ~/.claude/plans/** を R04 の確認対象から外します。<slug> は任意の 1 セグメントに一致します (記憶の slug は ProjectRoot から導出できないため)。~/.claude 配下でも settings* / skills/ / agents/ / commands/ / hooks/ / plugins/ / output-styles/ は対象外のままです。これらはデータではなく挙動を変えるためです。既存の IsAllowlistedTempPath には相乗りさせていません。同関数は runtimefloor の worktree 脱出判定と共有しており、拡張するとその床まで緩むためです。

観点	変更前	変更後
~/.claude/projects/<slug>/memory/ への Write	ask (実測 299 件)	確認なしで通る
~/.claude/plans/ への Write	ask (実測 14 件)	確認なしで通る
~/.claude/settings* / skills/ / agents/ 等	確認対象	確認対象のまま
~/.claude/plans-backup/、memory-extra/	確認対象	確認対象のまま (接頭辞衝突を明示的に拒否)
symlink された home	—	元の形と解決後の形の両方で判定
worktree 脱出判定 (runtimefloor)	—	影響なし (別関数のため)

WorkMode の skip 経路が実装されていながら一度も配線されていなかった問題 (Phase 132.2、docs)

今まで: docs/runtime-floor-secret-allowlist.md は「/work や /breezing の実行中は WorkMode が R04 の確認を skip する」と記述していました。実際には ctx.WorkMode を立てる経路が 2 つとも死んでおり、(a) HARNESS_WORK_MODE / ULTRAWORK_MODE を設定する箇所が skills / scripts / hooks に 1 つも存在せず、(b) state.SetWorkState の呼び出し元も自パッケージ外にありませんでした。skip 経路はコード上に存在するのに、通常の run では一度も到達できない状態でした。これが /breezing が確認で止まり続けていた直接の原因です。

今後: docs を実態に合わせて訂正し、未配線であること・暫定回避として ~/.claude/settings.json の env に HARNESS_WORK_MODE=1 を置けること・その場合は work run 以外でも skip が効くこと (リポジトリ間の書き込み確認も消える) を明記しました。破壊的削除は影響を受けません。R05 と protected-path deny が引き続き worktree 外の rm -rf を止めます。実際の配線は Phase 132.3 として起票しています。

Phase 128 の commit hash 台帳が squash merge で到達不可になっていた問題

今まで: Plans.md の Phase 128 (128.1-128.5) は、PR #282 の作業ブランチ上で作られた commit hash (7702ca45 / 476ea403) を記録していました。PR #282 は squash merge されたため、main に実際に入ったのは別の 1 commit (1f085a35) で、作業ブランチ側の commit は main の履歴から到達不可能になっていました。台帳としての記録が実体を指さない状態でしたが、これを機械検知するゲートは存在しませんでした。

今後: 台帳を main 上の実体 1f085a35 に訂正しました。あわせて scripts/ci/check-plans-hash-reachability.sh を新設し、Plans.md の cc:done / cc:完了 に記録された commit hash が現在の HEAD から到達可能であることを検証します。origin/main ではなく HEAD を基準にすることで、進行中の feature branch 上の記録も、squash merge で祖先から消える今回のようなケースも、正しく検出できます。

観点	変更前	変更後
Phase 128 の記録	7702ca45 / 476ea403 (作業ブランチ側、main から到達不可)	1f085a35 (main に入った実体)
記録が実体を指すか	指していない	全 11 hash が HEAD から到達可能
機械検証	なし (check-branch-alignment-ledger.sh は別ファイルが対象)	check-plans-hash-reachability.sh が tests/validate-plugin.sh 経由で毎回実行
到達不可を検出したときの挙動	何も起きない	違反 hash を列挙して fail
shallow clone	(該当なし)	検証不能のため not_observed として skip

producer | grep -q の検出器が producer を 3 種に限定しており、jq/find など他の producer 経由の同型欠陥が検出網から漏れていた問題 (Phase 130)

今まで: Phase 129 で導入した検出器 tests/test-pipefail-grep-q-safety.sh は、pipefail 下で結果が反転する producer | grep -q 構文の producer を printf / echo / cat の 3 つに限定していました。そのため jq / find / git / grep / head / シェル関数呼び出しなど、他の producer を持つ同型の書き方が検出網から漏れたまま残っていました。

tests/test-i18n-locale-resolver.sh:196 の jq -r '...' <<< "$内容" | grep -q '応答言語: 日本語' で実際に再現を確認しました。同一データで 20 回ずつ試行したところ、修正前は 20/20 で「無い」と誤判定されました (探している文字列は実際には先頭 4 バイト目にあり、常に存在します)。

今後: 検出器の producer 判定を「種類を問わない」へ広げました (パイプ右側が grep -q 系であれば、左側が何であっても検出対象)。広げた検出器を修正前のツリーへ適用すると 29 行を検出し (うち 1 行は && で連結した 3 段判定を含むため、実際の書き換え箇所は 34 箇所)、該当する 14 ファイルをすべて herestring または変数捕捉へ書き換えました。producer がコマンド呼び出しやシェル関数の場合は、まず変数へ捕捉してから <<< で判定する形に統一しています (X="$(producer)"; grep -q P <<<"$X")。

あわせて here-document の本文を走査対象から外しました。here-doc の中の | は実行されるパイプではなく、説明文やテンプレートの一部です。これを検出すると、正しいコードに対して検査が落ちる誤検出になります。<<- のタブ字下げ終端子にも対応し、本文の読み飛ばしが後続の実コードまで隠さないことを非退行 fixture で固定しています。

一方、複数行にまたがる二重引用符文字列 (python3 -c "..." のように " の開始行と終了行が異なる場合) は、引用符状態を論理行単位でリセットする実装上の制約により、引き続き検出対象外です。目視レビューで実例を 3 件発見し herestring 化しましたが、検出器自体はこの形を機械検出できません。

項目	変更前	変更後
producer の対象	printf / echo / cat の 3 種のみ	種類を問わない
検出漏れ (見逃し)	jq / find / git / grep / head / シェル関数呼び出しなど	複数行にまたがる二重引用符文字列のみ
誤検出	(該当なし)	here-document 本文を除外 (<<- 含む)
修正前ツリーでの検出行数	0 行 (対象外のため)	29 行 (実際の書き換え箇所は 34 箇所)
fixture	10 件	17 件

実測: tests/test-i18n-locale-resolver.sh を修正前後でそれぞれ 20 回連続実行したところ、修正前は 20 回中 19〜20 回失敗し (実行環境の状態によっては初回だけ通ります。work モードの状態が無いと出力が短く、バッファ境界を越えないためです)、修正後は 20 回すべて成功しました。まっさらな clone では出力が短いため CI では再現せず、緑のまま潜伏していました。

Added

rule↔context 配線カバレッジテスト — 「立てる手段の無いフィールド」を機械検知 (Phase 132.6/132.7 再発防止)

今まで: policy ルールには文脈を手組みするテストが 144 件ありましたが、実入力から文脈を組み立てる BuildContext 側の網羅検査がなく、producer を失ったフィールド (WorkMode / CodexMode / BreezingRole) が「テスト済みなのに本番で不発」のまま数ヶ月残りました。既存の rulecoverage ゲートは rule↔テストの軸しか見ないため、この型の欠陥を「カバー済み」と判定します。

今後: go/internal/guardrail/build_context_wiring_test.go が RuleContext の全フィールドについて「実在する producer (env / SQLite / state ファイル / harness.toml) 経由で値が届くこと」を検証します。reflection でフィールド一覧と照合するため、producer の証明なしにフィールドを増やすとテストが赤くなります。あわせて operator-supplied-knobs.v1.yaml は grandfather 登録を全廃し、全エントリに primary_producer (env 以外の一次供給経路) の明記を必須化しました。テスト側には全 knob env をゼロにする共有ヘルパを入れ、開発機の HARNESS_WORK_MODE=1 がテストプロセスへ漏れて期待値を反転させる事故 (2026-08-11 実測) を塞ぎました。

Grok のモデル pin が実在しない ID を指していた問題 (Phase 133.3)

今まで: scripts/model-routing.sh の grok tier 表は grok-4.5 と grok-composer-2.5-fast を pin していました。2026-08-12 に grok-cli v1.1.7 の src/grok/models.ts を直読して照合したところ、どちらもカタログに存在しない ID でした (後者は cursor 側の composer-2.5-fast の取り違えと見られます)。呼び出せば必ず失敗する pin が長期間残っていたことになります。テストは通っていましたが、router が自分自身と一致することしか確かめておらず、ID の実在は検査対象外でした。

今後: 実カタログへ更新しました。lite = grok-3-mini (grok で reasoning_effort を受け付ける唯一のモデル、値は low/high のみ)、standard = grok-4.20-non-reasoning、deep/advisor/review/release = grok-4.3 (DEFAULT_MODEL・flagship reasoning・1M ctx)、long-context = grok-4.20-0309-reasoning (2M ctx)。grok-4.20-multi-agent-0309 は responsesOnly かつ supportsClientTools:false のため、tool を使う harness role からは除外しています。effort も grok 自身の語彙 (low/high) 内に収めました (旧 medium は grok が受け付けない値)。回帰網として「全 tier が実在 ID のみを返す」「effort が grok の語彙内」の 2 検査を追加しています。hosts.toml と docs の 3 層すべてに降ろしました。

初版では同一ファイル内の 2 つ目の表 (Harness Role Defaults) の advisor / release 行だけ直し漏れ、独立レビューで指摘されました。根因は docs と正本 (scripts/model-routing.sh) の一致を機械検査する仕組みが無かったことです。docs の表の行に現れる grok pin を検証するゲートを追加しました。初版のゲートは敵対的再検証で 2 通りの回避が実証されたため強化しています: (i) 走査対象が 1 ファイルのみだった → grok の表を持つ doc 集合へ拡張、(ii) ID 集合への所属しか見ていなかった → tier 名の行はその tier の正解 ID が現れることまで検証。実在検査の基準は router の出力ではなく記録済みカタログにしてあります (カタログ一覧を載せる doc は router が使わない ID を含むのが正しいため)。回避シナリオを再現する変異検査で検知を確認しています。2 巡目の敵対的再検証がさらに 4 件の盲点 (tier セルの装飾・大文字で行判定が外れる / 行ごと削除が素通り / hosts.toml の pin が走査外 / tier 語彙がテスト側と二重管理) を実証したため、いずれも塞ぎました。最終的に 9 通りの変異 (別 doc への悪い ID、tier 対応の誤り 4 形、行削除、hosts.toml の drift、router 側 tier の追加漏れ、正当な追記) すべてで期待どおりの判定になることを確認しています。

なお gpt-5.6 の effort max は Codex CLI の config.toml での受理が未確証のため、xhigh 維持で変更していません。

Phase 133 起票 — 4 ツール (Claude / Codex / Grok / Cursor) の 2026-08 仕様調査

5 並列の調査で確証を取った適用候補を Phase 133 として起票しました。即時反映したのは hosts.toml の grok 記述のみです (grok-cli v1.1.7 の source 実査で「hook は user-level のみ、project-level hook は grok 自身が拒否」を確認し、admission-test evidence として記録)。cursor の binary 名変更 (agent が正、cursor-agent は legacy) / grok execution backend / モデルカタログ更新 (operator 裁定事項) / repair loop 状態外部化 / blind judge は task 化に留めています。

harness work-mode — 自律実行中だけ確認を止める配線の土台 (Phase 132.3。識別子問題は Phase 132.7 の Fixed で解消済み)

今まで: ctx.WorkMode が立つと R04 (プロジェクト外への書き込み) と R05 (削除) の確認を skip する経路は実装済みでした。しかしこれを立てる手段が 2 つとも死んでおり、HARNESS_WORK_MODE / ULTRAWORK_MODE を設定する箇所は skills / scripts / hooks に 1 つも無く、state.SetWorkState の呼び出し元も自パッケージ外にありませんでした。逃げ道は作られたまま一度も繋がれておらず、/breezing が確認ダイアログで止まり続けていました。

今回入れたもの: harness work-mode <on / off / status> を新設し、work_states への書き込みと読み出しを実装しました。session ID が解決できない場合は無言で成功せず、理由を出して非ゼロ終了します。work_states.session_id の FOREIGN KEY を満たすため、既存の sessions 行が無いときだけ最小行を作ります (無条件 upsert は mode / context_json を潰すため。この退行はテストで pin 済み)。

まだ動きません: 独立レビューと実測で、session ID の解決先が誤っていることが判明しました。hookhandler.ReadLocalSessionID が読む .claude/state/session.json はセッション監視の状態ファイルで、内部生成の timestamp ベース ID を持ちます。Claude Code が hook に渡す実 session_id とは別物です。実測では work-mode on の後でも、実 ID を含む payload に対して R04 は ask のままでした。識別子の解決を直すまで、この配線は no-op です。

現時点で /breezing の停止を止めているのは ~/.claude/settings.json の env に置く HARNESS_WORK_MODE=1 (operator 手動) です。識別子の修正は Plans.md 132.7 として起票しています。

観点	変更前	変更後
work_states への読み書き手段	無し	harness work-mode
session ID 未解決時	—	非ゼロ終了 + 理由出力
既存 sessions 行の保護	—	上書きしない (退行テストあり)
hook から見た実効性	無し	無し (識別子不一致。132.7 で対応)

未配線の設定ノブを検出するゲート (Phase 132.4)

今まで: 「コードが読む設定キーを、repo 内の誰も設定していない」という欠陥を検出する仕組みがありませんでした。コードを読むと分岐が実装済みに見えるため、producer を追跡しない限り気づけません。この型の欠陥は本 repo で繰り返し発生しています (.claude-plugin/settings.json の permissions が読まれない件、今回の HARNESS_WORK_MODE 件)。

今後: scripts/ci/check-config-knob-wiring.sh を新設しました。go/internal/guardrail と go/internal/policy が os.Getenv で読む HARNESS_* / ULTRAWORK_* の各キーについて、repo 内に producer があるか、templates/registry/operator-supplied-knobs.v1.yaml に operator 供給として登録されているかを検証します。tests/validate-plugin.sh から実行されます。

初回実行で 13 キー中 10 件の違反を検出しました。判明していた 2 件に加え、同型の未配線が 8 件見つかっています (HARNESS_BREEZING_ROLE / HARNESS_CODEX_MODE / HARNESS_ACTIVE_PHASE / HARNESS_ACTIVE_TASK / HARNESS_TDD_* 4 件)。ゲートを green で着地させるため registry へ grandfather 登録しましたが、registry 本文に「追認ではなく一時退避」と明記し、triage を Plans.md 132.6 として起票しています。

• Plans.md hash 台帳の到達可能性ゲート: scripts/ci/check-plans-hash-reachability.sh を新設し tests/validate-plugin.sh へ配線した。Status 欄の commit hash が HEAD から到達不可なら fail する。shallow clone では検証不能なため not_observed として skip し、既知の grandfather 対象があれば scripts/ci/plans-hash-baseline.txt で個別に除外できる (今回のリポジトリでは Phase 128 の訂正後、除外対象は 0 件)

Changed

防御層を追加・変更するときの影響確認を規約化 (Phase 132.5)

今まで: 防御層 (permissions / guardrail hook / sandbox) を足すときの手順が規定されておらず、「何を止めるか」だけを設計して「止めた結果、誰が通れなくなるか」を確認しない事故が起きました。2026-08-10 に同型の失敗を 1 日に 2 回起こしています。

今後: .claude/rules/defense-layer-blast-radius.md を新設し、CLAUDE.md の Permission Boundaries から参照しました。層ごとの強制力と影響範囲の対比 (permissions と hook は agent のみ / sandbox は OS がプロセスツリー全体に強制)、強制力が強い層ほど適用範囲を狭くする原則、追加前の 5 点チェック、excludedCommands が起動コマンド名にしか一致せずサブプロセスへ継承されない事実、user scope 昇格前に 1 プロジェクトで実経路を通す段階適用を定めています。scripts/ci/check-consistency.sh が存在と必須フレーズを検証します。

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

今まで: session-log.md の分割警告は 500 行で出ます。一方、/maintenance が実際に退避できるのは「直近 30 日より古いエントリ」だけです。この 2 つが噛み合っておらず、全エントリが 30 日以内に収まっていると、警告は出るのに移動対象が 1 件も無い状態になります。当リポジトリでは 520 行 / 全 20 エントリが 30 日以内という、まさにその状態で警告が出続けていました。行数だけを見て退避すると保持ルール違反になるため、警告に従うと規約を破ることになります。

今後: 上限を 600 行へ引き上げました。上限は読みやすさの目安であり、保持期間 30 日のように守りの強さを持つ値ではないため、噛み合わない箇所は上限側で解消します。保持期間は直近の作業履歴を本体に残す下限として 30 日のまま維持します。判断の根拠は skills/maintenance/references/cleanup.md の閾値表に注記として残しました。

項目	変更前	変更後
SESSION_LOG_MAX_LINES の既定値	500	600
520 行時点の挙動	警告あり (移動対象は 0 件)	警告なし
601 行時点の挙動	警告あり	警告あり (limit: 600 と表示)
保持期間	30 日	30 日 (変更なし)

環境変数 SESSION_LOG_MAX_LINES による上書きは従来どおり有効です。定義は Go 実装・scripts/auto-cleanup-hook.sh・templates/hooks/auto-cleanup-hook.sh・閾値表の 4 箇所にあり、すべて同時に更新しています。稼働している hook は Go 実装 (bin/harness hook auto-cleanup) のため、4 プラットフォームのバイナリを再生成しました。

---

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

依存	変更	備考
golang.org/x/sys	0.46.0 → 0.47.0	4 プラットフォームのバイナリを再生成
modernc.org/sqlite	1.54.0 → 1.55.0	4 プラットフォームのバイナリを再生成
github/codeql-action (init / analyze / upload-sarif)	4.37.1 → 4.37.3	-
ossf/scorecard-action	2.4.3 → 2.4.4	-
actions/setup-python	6.3.0 → 7.0.0	v7 の破壊的変更は pip-install 入力の削除。当リポジトリの呼び出しは python-version のみを渡すため影響なし
@vercel/agent-eval (Breezing ベンチ)	0.14.5 → 1.4.0	major 更新。使用している API は型 ExperimentConfig と CLI agent-eval <実験名> [--dry] だけで、experiments 20 本を 1.4.0 の型定義に当てた型検査は 0 error。設定キーの改名なし

Security

Breezing ベンチの監査済み依存ラインを 1.4.0 へ引き上げ、新規 advisory 3 件を塞いだ

今まで: benchmarks/breezing-bench/agent-eval の @vercel/agent-eval は ^0.14.1 に固定され、tests/test-breezing-agent-eval-deps.sh がその pin 文字列を検査していました。この固定は Dependabot alert を掃除したときの「監査済みラインから外れない」ための措置で、1.x が非互換だという判断ではありません。また同ゲートが実行する npm audit --audit-level=moderate は、その後に公開された advisory によって main 上でも失敗する状態になっていました。

今後: 監査済みラインそのものを 1.4.0 へ移しました。あわせて undici の override 範囲を引き上げ、nanoid と brace-expansion の override を追加して、high 3 件を解消しています。ゲート側の検査は 1 つも削らず、固定値を引き上げたうえで新しい override 2 件ぶんの検査を追加しました。

項目	変更前	変更後
@vercel/agent-eval	^0.14.1 (0.14.5 が解決)	~1.4.0 (1.4.0 が解決)
undici override	^7.24.0 (7.28.0 が解決)	^7.29.0 (7.29.0 が解決)
nanoid override	なし (3.3.11 が解決)	^3.3.17 (3.3.18 が解決)
brace-expansion override	なし (5.0.8 が解決)	^5.0.9 (5.0.9 が解決)
npm audit --audit-level=moderate	失敗 (high 3 件)	成功 (残りは閾値未満の low 5 件)
ゲートの検査本数	固定値の完全一致 4 件 / 最低バージョン 4 件	固定値の完全一致 6 件 / 最低バージョン 6 件

undici / nanoid / brace-expansion の 3 件は @vercel/agent-eval のバージョンとは無関係の推移的依存です。更新前の main の lockfile に対して同じ監査を実行しても同一の 3 件が出るため、この更新が持ち込んだものではありません。