[tracking] 2026-08 プロジェクト全体レビュー (コンセプト + 実装) の指摘まとめ

[shinyaoguri]

2026-08-02 に main (bca25f7 時点) に対して実施したプロジェクト全体レビューの親 Issue。コンセプト評価と実装評価の両面で、shared / editor / verify+verify-cli / workers+e2e+CI / docs↔実装整合の 5 面から点検した。

総評

コンセプトと設計判断は高い水準にあり、shared の暗号・検証コアも信頼できる。 暗号的なコア (ハッシュチェーン / PoSW / ECDSA / exam 束縛) に偽造を許す欠陥は見つからなかった。三層保証語彙 (ADR-0020) が deriveAssurance の実装や #131 のゲートまでコードレベルで貫通していること、ADR-0023 の「判定しない」原則が advisory の直交性として web/CLI 双方で厳密に守られていることを確認した。

問題は その正しさをユーザーに伝える最後の一段 — verify の表示層とドキュメント — に集中している。

根本原因 2 つ

1. 「判定ロジックは shared に単一実装」が文書ルールとしてしか強制されていない。 今回の主要な乖離 ([verify] verificationWorker が verifyProofFile に委譲せずレイヤ合成を再実装 (sessionId 突合の欠落・整合性チップの反転) #211 [verify] フォルダ読込でスクショのチェーン裏付け検査が無効化される (ZIP と結論が食い違う) #212 [verify] web にスクショ剥ぎ取り (chainOnly) の検出が無い (CLI にはある) #213) は例外なく「shared に委譲していない箇所」に集中し、委譲されている部分には乖離が無かった。→ [verify/verify-cli] web↔CLI の結論一致を CI で固定するパリティテストを追加する #216 (web↔CLI パリティテスト) が根本対策
2. ドキュメントの鮮度が CLAUDE.md ≫ system-spec ≫ README の順。 overclaim 抑止が生命線の製品として向きが逆 → [docs] README 群 (root/verify/workers/verify-cli/editor) が陳腐化し overclaim を含む #230 [docs] system-spec の陳腐化 (§5.4 dead なマルチファイル形式 / §5.3 フィールド欠落 / firstSeenAt と上限の per-tab 化など) #231 [docs] ADR と実装の乖離 (ADR-0017 手順5 未実装 / ADR-0011 §6 能力集合未記録 / ADR-0020 が実装より弱い) #232

推奨対応順

1. [verify] proof.json の mode で assurance chip に XSS (検証結果の表示を偽装できる) #210 verify の XSS (単独で緊急。他のすべての保証表示の前提)
2. [verify] verificationWorker が verifyProofFile に委譲せずレイヤ合成を再実装 (sessionId 突合の欠落・整合性チップの反転) #211 verificationWorker を verifyProofFile へ委譲 (乖離 2 件が構造的に消える)
3. [shared] exam の time-box が ADR-0013「advisory・失格条件にしない」に反して失格条件になっている #220 ADR-0013 time-box の矛盾をどちらに寄せるか決定 (判断が要る)
4. [verify/verify-cli] web↔CLI の結論一致を CI で固定するパリティテストを追加する #216 web↔CLI パリティテスト (2 の再発防止)
5. [editor] exportCurrentTab に best-effort 分岐が無く、class/assignment が Turnstile 不達で export 不能になる #224 [editor] waitForQueueDrain timeout 時の export が content replay で invalid になる proof を生む #225 editor の export 2 件 (正直な利用者が損をする経路)
6. [e2e] 署名済み checkpoint の存在を assert しておらず、sign API の全損を CI が見逃す #228 E2E に署名済み cp の assert (1 行で CI の盲点が塞がる)
7. [shared] events 配列の要素型が未検証で、null 要素により totalEvents/totalTypingTime を水増しできる #221 [docs] README 群 (root/verify/workers/verify-cli/editor) が陳腐化し overclaim を含む #230 shared の events 要素型検証 / README 刷新

起票一覧

critical

• [verify] proof.json の mode で assurance chip に XSS (検証結果の表示を偽装できる) #210 [verify] proof.json の mode で assurance chip に XSS (検証結果の表示を偽装できる)

high

• [verify] verificationWorker が verifyProofFile に委譲せずレイヤ合成を再実装 (sessionId 突合の欠落・整合性チップの反転) #211 [verify] verificationWorker が verifyProofFile に委譲せずレイヤ合成を再実装
• [verify] フォルダ読込でスクショのチェーン裏付け検査が無効化される (ZIP と結論が食い違う) #212 [verify] フォルダ読込でスクショのチェーン裏付け検査が無効化される
• [verify] web にスクショ剥ぎ取り (chainOnly) の検出が無い (CLI にはある) #213 [verify] web にスクショ剥ぎ取り (chainOnly) の検出が無い
• [verify/verify-cli] fast モードで PoSW 未実施なのに「整合性: 証明済み」と表示される (overclaim) #214 [verify/verify-cli] fast モードで PoSW 未実施なのに「整合性: 証明済み」
• [verify/verify-cli] web↔CLI の結論一致を CI で固定するパリティテストを追加する #216 [verify/verify-cli] web↔CLI パリティテストを追加する
• [shared] exam の time-box が ADR-0013「advisory・失格条件にしない」に反して失格条件になっている #220 (保留: 判断待ち) [shared] exam の time-box が ADR-0013 に反して失格条件になっている
• [shared] events 配列の要素型が未検証で、null 要素により totalEvents/totalTypingTime を水増しできる #221 [shared] events 配列の要素型が未検証で totalEvents を水増しできる
• [editor] exportCurrentTab に best-effort 分岐が無く、class/assignment が Turnstile 不達で export 不能になる #224 [editor] exportCurrentTab に best-effort 分岐が無く class/assignment が export 不能
• [editor] waitForQueueDrain timeout 時の export が content replay で invalid になる proof を生む #225 [editor] waitForQueueDrain timeout 時の export が invalid な proof を生む
• [e2e] 署名済み checkpoint の存在を assert しておらず、sign API の全損を CI が見逃す #228 [e2e] 署名済み checkpoint の assert が無く sign API の全損を CI が見逃す
• [docs] README 群 (root/verify/workers/verify-cli/editor) が陳腐化し overclaim を含む #230 [docs] README 群が陳腐化し overclaim を含む

medium

• [verify] 検証エラーのタブに切り替えると直前 proof の結果パネルが残り続ける #215 [verify] 検証エラーのタブに直前 proof の結果が残る
• [verify-cli] スクショ改竄のみで失敗すると「Error: All hashes verified successfully」と矛盾した出力になる #217 [verify-cli] スクショ改竄のみの失敗で矛盾した Error 行が出る
• [verify-cli] --exam-package を渡しても proof に exam ブロックが無ければ黙って無視され exit 0 になる #218 [verify-cli] --exam-package が exam ブロック無しで黙って無視され exit 0
• [verify-cli] --analysis-bundle の integrityValid に gate 込みの総合 valid を渡している (ADR-0024 の契約違反) #219 [verify-cli] --analysis-bundle の integrityValid に総合 valid を渡している
• [shared] VALID_EVENT_TYPES が 26 種で stale (examOpened / environmentProbe / fullscreenChange が欠落) #222 [shared] VALID_EVENT_TYPES が 26 種で stale
• [shared] MIN_SUPPORTED_VERSION のバージョンゲートが検証経路に配線されていない (exam の formatVersion も同様) #223 [shared] MIN_SUPPORTED_VERSION のバージョンゲートが未配線
• [workers] serverTimestamp の単調性をサーバがクランプしておらず、クロックスキューで正直な proof が検証失敗しうる #226 [workers] serverTimestamp をサーバがクランプしていない
• [workers] sessionStartToken に有効期限が無く、KV TTL 7 日ごとに DoS 上限がリセットされる #227 [workers] sessionStartToken に有効期限が無い
• [e2e] exam モードの round-trip E2E が無い (最も保証レベルの高いモードが実機未検証) #229 [e2e] exam モードの round-trip E2E が無い
• [docs] system-spec の陳腐化 (§5.4 dead なマルチファイル形式 / §5.3 フィールド欠落 / firstSeenAt と上限の per-tab 化など) #231 [docs] system-spec の陳腐化 (§5.4 dead なマルチファイル形式など)
• [docs] ADR と実装の乖離 (ADR-0017 手順5 未実装 / ADR-0011 §6 能力集合未記録 / ADR-0020 が実装より弱い) #232 [docs] ADR と実装の乖離 (ADR-0017 手順5 / ADR-0011 §6 / ADR-0020)
• [shared] registry エントリの日時が parse 不能だと鍵の有効性検査が黙って素通りする (失効鍵が信頼されうる) #233 [shared] registry の日時が parse 不能だと失効鍵が信頼されうる
• [shared] ZIP 爆弾ガードが JSZip の内部 API 依存で fail-open (依存更新で静かに無防備化しうる) #234 [shared] ZIP 爆弾ガードが JSZip 内部 API 依存で fail-open
• [shared/editor] 正常な編集だけで isPureTyping が false になる (括弧自動閉じが既定 on) #235 [shared/editor] 正常な編集だけで isPureTyping が false になる
• [editor] exam の best-effort 経路: #0 attestation を常に合成 / 署名 token の再取得契機が無い #236 [editor] exam の best-effort 経路 (#0 attestation / token 再取得)
• [editor] タブ凍結時に SingleInstanceGuard をすり抜けた二重インスタンスがチェーンを壊しうる #237 [editor] タブ凍結時の二重インスタンスがチェーンを壊しうる
• [repo] レビュー由来の小さな問題まとめ (dead code / stale comment / 表示の細かい不整合) #238 [repo] 小さな問題まとめ (dead code / stale comment / 表示の不整合)
• [repo] CI の磨き込み (PR プレビューの文字列直展開 / permissions 絞り / Playwright キャッシュ) #239 [repo] CI の磨き込み

コンセプト (判断が要る)

• [concept] 「窓内・同一マシンの忠実な転写は防げない」ことの期待値調整が製品説明に落ちていない #240 [concept] 「転写は防げない」ことの期待値調整が製品説明に落ちていない
• [concept] PoSW のコスト構造を再評価する (時刻アンカーと目的が重複している) #241 [concept] PoSW のコスト構造を再評価する
• [concept] fingerprint の収集範囲が「匿名」の主張に対して過剰でないか検討する #242 [concept] fingerprint の収集範囲が「匿名」の主張に対して過剰でないか

確認して問題が無かった主な項目

• spec §10 の定数一覧は全項目が実装と一致
• spec §7 攻撃マトリクス全 16 行が、主張どおりのレイヤで検出されることをコードで確認
• registry-only 信頼アンカーが署名 cp / session token / exam package の 3 系統で同型に実装され、各系統にネガティブテストがある
• ECDSA raw r‖s (P1363) の扱いは正しく、署名 malleability がどのハッシュ連鎖にも影響しない構造
• ADR-0009/0023 の advisory 直交性: analysis が valid / exit code に漏れ込んでいないことを web/CLI 両方で確認
• ADR-0027 の実装 (token 検証が KV read より前) と、それを固定するテスト (expect(kv.store.size).toBe(0))
• CORS が fail-closed + wildcard 不使用、deploy 誤実行防止が多層

[shinyaoguri]

進捗: critical + high の 12 件が完了 (#220 のみ保留)

2026-08-05 時点。着地した PR は以下のとおり (すべて main へ squash merge・CI 全 green)。

Issue	PR	内容
#210	#245	proof の mode を allowlist 検証 + エスケープ。verify の innerHTML 50 箇所を洗い直し、他に未エスケープ経路が無いことも確認
#221	#246	verifyProofMetadata の手前に events 構造検証ゲートを追加
#224	#244	best-effort 分岐を共通メソッドへ抽出 (二重定義そのものを解消)
#228	#247	happy-path で署名済み envelope の存在を assert
#230	#249	README 群を実装に合わせて刷新
#225	#250	排出待ちを進捗ベース化し、未排出時は export を中止
#212 #213	#251	chainImageHashes 必須化・chainOnly を shared へ集約・「0 枚 vs 未検査」を区別
#211 #216	#252	検証合成を verifyProofFile へ全面委譲 + web↔CLI パリティテスト (11 ケース)
#214	#253	fast モードで整合性を proven に上げない (ADR-0031)

根本原因への対処

親 Issue に挙げた根本原因 2 つに、それぞれ決定論的な歯止めを入れた。

1. shared 非委譲 → webCliParity.test.ts が web と CLI の結論一致 (valid / 三層保証 / exam 束縛 / スクショ軸) を CI で固定。片側だけ直すと赤くなることを実測で確認済み。あわせて chainImageHashes ([verify] フォルダ読込でスクショのチェーン裏付け検査が無効化される (ZIP と結論が食い違う) #212) と poswSkipped ([verify/verify-cli] fast モードで PoSW 未実施なのに「整合性: 証明済み」と表示される (overclaim) #214) を必須引数にして、渡し忘れが fail-open にならないようにした
2. README 陳腐化 → docs: README 群を実装に合わせて刷新し overclaim を解消する #249 で実装に同期。packages/verify/CLAUDE.md に不変条件 6〜8 (スクショ判定の shared 委譲・必須引数・「0 枚 vs 未検査」) を追記

設計判断

• ADR-0031 を追加 (fix(verify): fast モードで PoSW 未検証を明示し整合性を proven にしない #253): IntegrityLevel に partial を足し、省略した検査があるときは proven に上げない。ADR-0020 の「整合性は二値」は「検証器は常に全レイヤを実行する」という暗黙の前提に立っており、fast モードと最初から両立していなかった。ADR-0020 の Status に ADR-0031 への参照を付けた (原典だけ読んだ人が古い値域を信じないため)
• [shared] exam の time-box が ADR-0013「advisory・失格条件にしない」に反して失格条件になっている #220 (exam time-box) は保留。ADR-0013 を正とするか実装を正とするかの決定待ち

follow-up

• [verify] proof 由来の language が無検証で className に入る (#210 と同種の構造) #248 を新規起票 (proof 由来の language が無検証で className に入る。[verify] proof.json の mode で assurance chip に XSS (検証結果の表示を偽装できる) #210 と同種の構造だが XSS ではない)

残りは medium 21 件とコンセプト 3 件。

[shinyaoguri]

残り 24 件の事実確認 (全件) と P3 の着地

2026-08-16 時点。medium 21 + concept 3 + 未起票分を含む open 全 29 件を HEAD 45a647f の実コードに対して検証し、うち低コストの 8 件を着地させた。

判定の内訳

判定	件数
再現 (現存)	19
部分的	3 (#234 #235 #239)
仕様判断待ち	4 (#220 #240 #241 #242)
常設・重複	2 (#261 は自動生成の常設 Issue で、内容は #258 と同一 + dependabot 担当分)

誤りで close すべきものはゼロ。 ただし 6 件で Issue 本文の記述が事実とずれており、うち 2 件は深刻度が逆方向に動く。

---

1. 判定が変わった 6 件 (優先して読むべき)

#234 — medium → high 相当に格上げ。指摘された機序は誤りだが、より悪い穴が実在

Issue の「JSZip 内部 API 依存で fail-open」は現行 3.10.1 では成立しない (loadAsync 経路のファイルエントリでは _data.uncompressedSize が必ず取れることを実測。undefined になるのはディレクトリと in-memory エントリのみ)。

代わりに、同じ assertZipWithinBudget (packages/shared/src/fileProcessing/parser.ts:35-49) に今日動く DoS がある。uncompressedSize は ZIP ヘッダ由来 = 攻撃者の申告値:

zip bytes: 305875                        # 300MB のゼロを deflate した 305KB
declared uncompressedSize after patch: 1 # local header +22 / central dir +24 を 1 に改竄
extract threw: Bug : uncompressed data size mismatch
rss delta MB: 317                        # ← 例外が飛ぶ「前」に 317MB 消費済み

• 256MB ガード (parser.ts:23) は合計 1 バイトと判定して素通り
• JSZip の整合性チェックは全展開後に投げるので、メモリは既に食われている
• extractScreenshotArtifactsFromZip (parser.ts:332-337) は manifest の画像を全部 Map に保持するので、エントリ上限 5000 内で複数並べれば加算される
• 呼び出し元は ZipFileProcessor.ts:44 = verify web を開いた採点者のブラウザが直撃

修正方針も変わる。fail-closed 化だけでは不十分で、圧縮比ガードか展開時の実バイト上限が要る。

#241 — 検証コストの主因は反復数ではなく実装だった

verifyPoSW が 1 反復ごとに await crypto.subtle.digest を回しているため実測 113.8 ms/event。同じ 10,000 反復を同期ハッシュにすると 4.07 ms/event で 28 倍差。

つまり Issue が検討している「反復数を 1/10 に下げる」(全 proof のフォーマット互換設計が必要。poswIterations は署名 cp payload と session start token payload にも焼かれているため署名済み envelope まで一斉に fail する) より前に、互換性コストゼロで 1/28 が取れる。#241 の設計判断とは独立なので #267 として分離起票した。

あわせて spec §6.1 の「full = 1000 events で ~10〜60 秒」は実測 ~114 秒で 2〜10 倍楽観的。#231 のリストに無い項目なので #267 に含めた。

#248 — 「実害は確認されていない」が誤り

.hidden { display: none !important; } が packages/verify/src/styles/base/_reset.css:122-124 に現存する (git log -S によれば 629ba82 以来ずっとある)。"language": "ts hidden" という proof.json で <code> に .hidden が付き、採点者のコードプレビューが丸ごと消える。XSS ではないが「将来 CSS にユーティリティが入ると成立しうる」ではなく今日成立する。

#235 — 部分的。採点側は起票前から解消済み → low

verifier は isBenignEditorInsert で括弧自動閉じを benign 扱いしており (d7124f3、#235 起票の 2026-08-02 より前)、verify web も CLI もその値を使う。採点者が「外部入力あり」を見ることはない。 残っていたのは誰も検証に使わない metadata.isPureTyping の自己申告値のみ。→ 本日 #264 で解消。

#219 — 影響記述が過大 → low

packages/shared/src/analysis/cohort.ts は integrityValid を一切参照していない (grep 確認済み)。「採点者が集めたコホート分布が歪む」は成立せず、実害は契約違反とレコードの誤情報のみ。→ 本日 #263 で解消。

#239 — 部分的。子項目①の前提が CI の実測で崩れた

PR #254 との重複は無し (#254 は新規 workflow 2 本の追加のみで deploy.yml に触れていない)。

子項目	結論
① command: の文字列直展開	非該当。Issue の前提が誤り
① command-output の直接展開	実在。修正した
② top-level permissions	実効はリポ設定 (default_workflow_permissions: read) で解消済み。YAML の明示のみ追加
③ Playwright キャッシュ	未解決だったので追加

①について: 一度 env: 経由に変えたところ deploy-preview が落ちた。

[command] npx wrangler pages deploy ./dist --project-name=$CF_PROJECT_NAME ...
✘ [ERROR] The Pages project "$CF_PROJECT_NAME" does not exist.

wrangler-action v4 は command: をシェルに渡さず、トークン分割して npx を直接 exec する。 よってシェルは介在せず、head_ref の ; $ バッククォートは不活性 (git はブランチ名に空白を許さないので引数分割も起きない)。直接展開のまま戻し、次に読む人が同じ「修正」を当てて再びデプロイを壊さないよう実測の根拠をコメントで残した。

一方 actions/github-script の script: は本物の JS 評価なので、command-output の直接展開は実在の問題 (wrangler 出力にバッククォートや ${ が混ざると job ごと落ちる)。

そのほか、Issue に書かれていなかった事実

• [shared] exam の time-box が ADR-0013「advisory・失格条件にしない」に反して失格条件になっている #220 は波及が本文より広い。binding.valid=false は CLI の exit code だけでなく assurance.integrity (→ 遅刻提出だけで 'failed' = 改ざん検出と同じ語彙)・assurance.temporal (exam-t0 から降格)・--require-root-anchor の exam 免除喪失、の 4 系統へ伝播する。ただし発現するのは verify-cli で --submitted-at を渡した場合のみ (verify web は submissionTimeMs を渡さない)
• [editor] exam の best-effort 経路: #0 attestation を常に合成 / 署名 token の再取得契機が無い #236 は fix(editor): 単一タブ export の事前認証を best-effort 化する #244 と重複しない。fix(editor): 単一タブ export の事前認証を best-effort 化する #244 が触ったのは ProofExporter.ts のエクスポート前 attestation で、[editor] exam の best-effort 経路: #0 attestation を常に合成 / 署名 token の再取得契機が無い #236 は TabManager.ts のタブ生成時 #0 と署名 token 取得。TabManager.ts は 2026-07-03 以降未変更
• typescript 7 (ネイティブコンパイラ) への移行を検討 #208 の障害は 1 ファイルだけ。TS 7.0.2 を隔離インストールして全 6 パッケージで tsc --noEmit を実行 → 全部 exit 0。tsconfig 側の障害はゼロで、詰まっているのは TypeScriptExecutor.ts:8 の import * as ts from 'typescript' のみ (TS7 は Go バイナリへの RPC で transpileModule をブラウザに公開しない)。しかもアプリは Monaco 同梱の TS 5.9.3 worker (7.6MB) を既に配信しているので、そちらへ寄せれば重複コンパイラ 3.5MB を削減しつつ依存ごと消せる
• [e2e] exam モードの round-trip E2E が無い (最も保証レベルの高いモードが実機未検証) #229 は spec ゼロ。e2e の全 14 spec に exam のラウンドトリップは無い。実装には exam authority 鍵の実行時生成 (checkpoint 鍵と同方式) が必須。なお解錠 UI (ExamStartGate) は自動化可能で、README が挙げる「フルスクリーン」は解錠のブロッキング条件ではない
• [docs] system-spec の陳腐化 (§5.4 dead なマルチファイル形式 / §5.3 フィールド欠落 / firstSeenAt と上限の per-tab 化など) #231 は 8/8 小項目すべて現存、[docs] ADR と実装の乖離 (ADR-0017 手順5 未実装 / ADR-0011 §6 能力集合未記録 / ADR-0020 が実装より弱い) #232 は 4/4 現存 (PR fix(verify): fast モードで PoSW 未検証を明示し整合性を proven にしない #253 が付けた ADR-0031 参照は Status 行の integrity 値域についてのみで、Decision 4 の exam-t0 規則には触れていない)、[repo] レビュー由来の小さな問題まとめ (dead code / stale comment / 表示の細かい不整合) #238 は 21 項目中 20 が現存
• docs(adr): ADR-0004 が存在しないパス packages/verify/src/core/VerificationEngine.ts を参照している #258 と chore: 鮮度チェックの検知結果 (自動) #261 は完全に同一の 1 件。リポ全体の Markdown をワークフローと同じロジックで走査してリンク切れは ADR-0004 の 1 件のみだった

---

2. 本日着地した P3 (低コスト 8 件)

サブシステム別に 4 PR。すべて squash merge・CI 全 green。

PR	Issue	内容
#262	#258 #257	ADR-0004 の死んだリンク / README 依存表。README.md:26 の「SWC」が完全な誤記だった (リポに SWC は存在せず実装は ts.transpileModule) — #208 の調査を誤誘導するのでバージョン表記より優先
#263	#217 #219	スクショ改竄のみの失敗ヘッダ / bundle の integrityValid。写像を純関数 toBundleIntegrityValid へ切り出してテスト可能にした
#264	#222 #235	VALID_EVENT_TYPES を Record<EventType, true> から導出 / isPureTyping 判定を evaluatePureTyping に一本化
#265	#239 #198	command-output の env 経由化・top-level permissions・Playwright キャッシュ / e2e のポート伝播

根本原因への対処 (親 Issue の「根本原因 2 つ」の続き)

今回も決定論的な歯止めを優先した。

• [shared] VALID_EVENT_TYPES が 26 種で stale (examOpened / environmentProbe / fullscreenChange が欠落) #222: 手書き Set をやめ union から導出。以後 EventType に型を足すと tsc が記入漏れを検出する。同期を文書ルールでなく型で強制
• [shared/editor] 正常な編集だけで isPureTyping が false になる (括弧自動閉じが既定 on) #235: isPureTyping の判定点を structuralEdit.ts の evaluatePureTyping 1 箇所に集約し、export 時の自己申告 (TypingProof) と採点側の再計算 (verifyProofMetadata) が同じ関数を呼ぶようにした。packages/shared/CLAUDE.md に不変条件 8 として明記。副次的に、export 側で素通しだった複数行の一括投入 (insertParagraph) も申告に反映されるようになった
• 後方互換の根拠: metadata.isPureTyping は typingProofData に含まれず typingProofHash の入力ではないので、値が変わっても既存 proof のハッシュ照合に影響しない。metadata.bulkInsertEvents は isSuspiciousBulkInsert の素のカウントのままで verifyProofMetadata の完全一致検査も不変。webCliParity.test.ts は 12 件 green のまま

各 PR ともテストを先に書き、実装前に赤くなることを実測してから仕上げている (例: 括弧自動閉じのケースは修正前に expected false to be true で落ちることを確認)。

---

3. 新規起票 4 件

Issue	内容
#266	verify-cli の Language: 行に proof 由来の文字列が無検証で出る。改行 + ANSI で Hash Chain: PASS に見える偽行を注入できることを実行確認。#248 の CLI 版
#267	PoSW 検証の非同期オーバーヘッド (28 倍) + spec §6.1 の時間記述の乖離。#241 の判断とは独立
#268	セッションライフサイクル API 3 つが呼び出し元ゼロで isActive が false に戻らない。#237 段階 2 の前提
#269	README 依存表 vs package.json の自動突合。#257 の再発防止 (dependabot が package.json だけ更新するため構造的にドリフトする)

---

4. 残りの優先度

P0 — 今日実害が出る / 判断さえ出れば即着地

• [shared] ZIP 爆弾ガードが JSZip の内部 API 依存で fail-open (依存更新で静かに無防備化しうる) #234 ZIP 申告値詐称の DoS (採点者ブラウザ直撃)。2-3 ファイル 60-100 行
• [shared] exam の time-box が ADR-0013「advisory・失格条件にしない」に反して失格条件になっている #220 exam time-box。判断待ちだが (A) ADR を正とする を推す — 「(B) 実装を正とすれば文書だけで済む」という前提は成り立たない。integrity: 'failed' を遅刻提出に使うのは ADR-0020 の語彙定義と衝突し、避けるには binding.valid と windowValid の分離が必要で (A) より大きくなる。(A) ならコード実質 20 行

P1 — 保証の中核が黙って弱くなる

• [verify-cli] --exam-package を渡しても proof に exam ブロックが無ければ黙って無視され exit 0 になる #218 --exam-package のサイレント無効化 (medium → medium〜high)。cli.ts 15 行
• [editor] exam の best-effort 経路: #0 attestation を常に合成 / 署名 token の再取得契機が無い #236 全 exam proof が恒常的に #0 verified=false, signature='unsigned' / 起動時オフラインでセッション全体が無署名。(a)(b) は「監督コード入力で数分ブロックする runExamUnlock の窓で Turnstile を先行取得する」一手で同時に解ける
• [verify] proof 由来の language が無検証で className に入る (#210 と同種の構造) #248 コードプレビューを消せる
• [shared] registry エントリの日時が parse 不能だと鍵の有効性検査が黙って素通りする (失効鍵が信頼されうる) #233 鍵失効の typo が黙って無効化 (sessionStartToken 側は完全サイレント)

P2 — 計画的に

#229 (#236 の方針決定後に spec の assert を確定するのが手戻りが少ない) / #226 / #237 (+#268) / #215 / #223 / #231 / #232 / #238 / #208 / #227 (+#232(d))

判断待ち

#220 / #240 / #241 / #242 / #223 の上限方針 / #227 の失効時リカバリ

---

_{🤖 Assisted by Claude Code}