[repo] レビュー由来の小さな問題まとめ (dead code / stale comment / 表示の細かい不整合)

[shinyaoguri]

2026-08-02 のプロジェクト全体レビューで見つかった、単独では Issue にするほどでない小さな問題をまとめる。個別に片付けても、まとめて 1 PR にしてもよい。

verify (web)

• TrustCalculator.ts:57-63: issue メッセージに shared の英語文言が素通しされる (message: verificationResult.message || t('trust.issueChainInvalid'))。ja ロケールで Previous hash mismatch at event 42: ... のような英文が混ざる
• TabBar.ts:79-93: removeTab が TabBar.activeTabId を無通知で付け替えるが VerifyTabManager.activeTabId は同期されない (TabController.handleTabClose:111-126)。タブを閉じた直後、選択タブと表示中の結果が別ファイルになる
• ResultPanel.ts:552-565: trustResult 未指定時のフォールバック isSuccess = result.chainValid && result.pureTyping が metadata 不正・exam 束縛失敗・スクショ改竄を無視する。現状は到達不能だが overclaim を生む地雷なのでフォールバックごと削除が安全
• ScreenshotLightbox.ts:294: screenshot.displayInfo.width は攻撃者制御の manifest 由来。displayInfo 欠落で TypeError
• ResultPanel.ts:878-883: exam カードが package 未提供時に緑バッジ。文言は正直だが、カードが既定折りたたみのため未提供注記が隠れる。warning 色 + 既定展開が望ましい
• VerificationController.ts:135-139: 複数 proof の ZIP で「最初に完了した proof」を自動で開くため、緑のタブが開いた状態で赤い兄弟タブを見落としうる (CLI にはある Summary: N/M proofs passed 相当の集約表示が web に無い)
• VerificationQueue.ts:246-266: clear()/terminate() が manifestMap を消していない (parsedDataMap/modeMap と非対称)

verify-cli

• cli.ts:221: process.exit() によるパイプ時の stdout 切り捨て。typedcode-verify x.zip | tee report.txt で末尾が欠けうる。process.exitCode = ... にして自然終了させる
• output.ts:397: audit モードの help が fast + deterministic PoSW sampling (placeholder) (= fast 相当) と読めるが、実装は full と同等 (spec §6.1 と一致)。あわせて result.poswSampled (サンプリング (audit)) が到達不能な dead string
• --analyzer の実行順: runAnalysis が pasteEvents/dropEvents の集計 (verify.ts:159-160) や summarizeProcess (:219) より先に走る。exit code / assurance は汚染されないが、表示上の統計は外部 analyzer に汚染されうる。凍結ビューを渡すか統計を先に計算しておくと不変条件が明快になる

editor

• OperationDetector.ts:83-106,146-151: 削除分類が粗い (rangeLength 2..49 は複数行でも deleteWordBackward、コメントとコード不一致)。advisory メタデータのみだが分析層の入力品質を下げる
• EventRecorder.ts:86-107 + TypingProof.ts:413-423: 記録エラー時のフォールバック index {index: events.length-1} により直前のイベントを二重処理する (LogViewer 二重表示 + IDB 再 append)
• dead code: TabManager.exportSingleTab / exportAllTabs / TabManager.reset() / SessionStorageService.pruneOldSessions
• StaticEventListeners.ts:331-333: beforeunload の deleteScreenshotsDB() は legacy DB のみ削除。コメントと実挙動が不一致
• TabManager.ts:685-699: 復元時の合成 tabSwitch (fromTabId=null) が sessionStorage 復元では蓄積し IDB 復旧では消失する。監査証跡が復元経路に依存して非決定的
• TypingProof.ts:927-929: 旧 API 名 waitForProcessingComplete() を参照する stale コメント

workers

• checkpoint.ts:99-122: 署名鍵キャッシュが keyId のみをキーにする。同一 keyId で JWK を差し替えると isolate が生きている限り旧鍵で署名する。「ローテは必ず keyId 変更を伴う」を CLAUDE.md に注記したい
• index.ts:270,359,428-433: /api/session/start /api/verify-captcha /api/verify-attestation に body サイズ上限が無い (MAX_BODY_BYTES は sign のみ)。turnstileToken の長さ上限も無い
• index.ts:326-341: handleVerifyCaptcha の catch がログなしの汎用 500。[workers] fetch ハンドラに包括 try/catch が無く未捕捉例外が 1101 (CORS/JSON なし) に落ちる #153 で session/start は揃えたが verify-captcha に残存
• API 応答に X-Content-Type-Options: nosniff 等のセキュリティヘッダが無い (純 JSON API なので実害は小)

e2e

• tests/helpers/app.ts:50-60: waitForSynced がイベント数安定を最大 ~9 秒で諦めて黙って続行する。flake 調査時に「同期未達のまま進んだ」ことがログから読めない

[shinyaoguri]

トリアージ (2026-08-23, HEAD b3d0116)

全 open Issue の事実確認・ドリフト検査の一環。21 項目を 1 つずつ現行コードで裏取りし、3 件は実行で再現した。

判定: 21 項目すべて現存 (前回の「20/21」は内訳が残っておらず再導出不能。45a647f 時点でも 21/21 だった)

verify (web)

#	項目	現行	判定 / 補足
v1	shared の英文が issue メッセージに素通し	TrustCalculator.ts:62 (英文の源は verification.ts:724 / ChainVerifier.ts:103,483)	現存。1 行。技術的な英文は chain カードに別途出るので情報は失われない
v2	TabBar.removeTab が activeTabId を無通知で付け替え	TabBar.ts:79-92、TabController.ts:102-117 は switchTab も sidebar.setActiveFile も呼ばない	現存。~5 行。#215 と同じ TabController の表示一貫性問題 → 同一 PR。補足: AppController.ts:320-337 handleFileRemove も manager (tabOrder[idx-1]) と bar (tabOrder[0]) で次タブの選び方が違い、3 タブ以上で同種のずれ (本文未記載)
v3	trustResult 未指定時フォールバック	ResultPanel.ts:555-569	現存 (到達不能を確認: resultPanel.render( の呼び出し元は TabController.ts:303 の 1 箇所のみで TrustResult を必ず渡す)。−14 行
v4	displayInfo 欠落で TypeError	ScreenshotLightbox.ts:294 (唯一の deref)。screenshotManifest.ts:15-38 は entry の中身を検証しない	現存。1-3 行
v5	exam カードが package 未提供時に緑 + 既定折りたたみ	ResultPanel.ts:826-841 (renderCard は success/error/pending のみ)。注記行 #exam-note-row は .expanded が付くまで非表示で、描画時に付ける箇所は無い (reset() :1083-1118 は呼び出し元ゼロ)	現存。~10 行 (warning クラスは CSS に既存)。#272 の影響なし
v6	複数 proof ZIP で最初に完了した proof を自動で開き、集約表示が無い	VerificationController.ts:140-144。集約は StatusBarUI.ts:30,38 の verifying current/total のみ	現存。40-80 行 + i18n。UI 設計が要るので単独 Issue に切り出す
v7	clear() / terminate() が manifestMap を消さない	VerificationQueue.ts:244-249, 254-264	現存だが両メソッドとも呼び出し元ゼロで実害なし。2 行 (dead メソッドごと消す選択もある)

verify-cli

#	項目	現行	判定 / 補足
c1	process.exit() によるパイプ時の stdout 切り捨て	cli.ts:222 (他 :42,51,59,87,94,109,135,146,225)	現存・再現した: stdout がパイプ かつ exit 時点で未 flush の出力が ≈64 KiB を超えると末尾が欠ける (POSIX のみ。ファイル redirect / TTY では起きない)。1 proof 分は最小 700 B なので単一 proof では起きないが、クラス単位の ZIP (数十 proof) を | tee / | less すると最後の === Summary: N/M proofs passed === から欠ける。~10 行 (process.exitCode)。注意: --analyzer の外部モジュールがハンドルを残すと自然終了しなくなる (README に一言)
c2	audit の help が fast 相当と読める + poswSampled dead	output.ts:439 (#263 で +42)。'sampled' を生成する箇所はゼロ → ResultPanel.ts:611-612 / ja.ts:112 / en.ts:113 / types.ts:67 が dead	現存。help 1 行 + dead 値の掃除 ~6 行 (4 ファイル)
c3	--analyzer が統計より先に走る	verify.ts:163 runAnalysis → その後に :181-182 paste/drop 集計、:197-221 deriveAssurance、:228 valid、:243 summarizeProcess	現存、ただし本文の「exit code / assurance は汚染されない」は誤り: AnalysisInput.verification は検証結果オブジェクトそのものの参照で、result.valid / chainValid / metadataValid / poswSkipped は runAnalysis の後に読まれる。一時 vitest で確認: input.verification.valid 等を書き換える analyzer を渡すと改竄 proof が valid:true (exit 0)・integrity が 'failed' 以外・pasteEvents 捏造になる。脅威主体は --analyzer を渡す採点者自身なので深刻度は低いが、ADR-0009 / 0023 の「advisory は valid / exit code に漏れない」不変条件が外部 analyzer に対しては構造的に破れている。~15-20 行 (result / events 由来の値を runAnalysis より前に全部計算し、後は analysis しか読まない形に並べ替える)

editor

#	項目	現行	判定 / 補足
e1	削除分類が粗い・コメント不一致	OperationDetector.ts:83-106, 146-151	現存 (advisory のみ。削除系 inputType はすべて ALLOWED_INPUT_TYPES なので pureTyping に無影響)。~15 行 + テスト
e2	記録エラー時のフォールバック index で直前イベントを二重処理	TypingProof.ts:415-425 の catch が { index: events.length - 1 } で resolve → EventRecorder.ts:86-104 が events[result.index] (= 直前の成功イベント) を LogViewer と IDB に再投入	現存 (潜在)・再現した: 2 件目の computeHash を 1 回だけ throw させると recordEvent が {index:0, hash:<1 件目>} で resolve、events.length === 1。IDB 側は unique index で黙って弾かれるので二重保存にはならず、LogViewer 二重表示のみ顕在化。到達性は低い (PoSW worker 障害は main-thread fallback で throw しなくなっている)。~10 行 (RecordEventResult に recorded: false を足す)
e3	dead code 4 件	exportSingleTab TabManager.ts:1558-1564 / exportAllTabs :1569-1623 / reset() :1524-1553 / pruneOldSessions SessionStorageService.ts:721-747 (+ 唯一の呼び出し元だった private deleteSessionById :752-824)	現存。exportSingleTab は waitForQueueDrain を通さず exportProof を呼ぶので、呼ばれれば #225 が再発する危険な dead API。−190 行程度
e4	beforeunload の deleteScreenshotsDB() は legacy DB のみ	StaticEventListeners.ts:331-332 / StorageClearHelper.ts:65-71 ('typedcode-screenshots' のみ)	現存 (コメント不一致のみ)。2 行
e5	復元時の合成 tabSwitch が経路依存	TabManager.ts:684-699: isRestoring 中は IDB への persistTabSwitch だけ抑止し tabSwitches.push と sessionStorage 保存は実行 → リロード毎に fromTabId:null が 1 件ずつ蓄積、IDB 復旧は IDB 由来 + 合成 1 件	現存 (advisory のみ)。1-3 行 + テスト
e6	stale コメント waitForProcessingComplete()	TypingProof.ts:954-956 (+27)	現存だが「旧 API 名」は不正確 — 同名の private メソッドが editor の ProofExporter.ts:130 に現存。stale なのは (a) shared から editor 内部名を参照している点、(b) 整合性の根拠が #225 以降 waitForQueueDrain + 未排出時の export 中止に移った点。2 行

workers

#	項目	現行	判定 / 補足
w1	署名鍵キャッシュが keyId のみをキー	checkpoint.ts:99-122	現存。補足: registry (shared/src/checkpointKeys/registry.ts:13-30) は publicKeyJwk.x/y を持つので、同一 keyId で JWK を差し替えると registry の公開鍵と食い違い、キャッシュの有無に関係なく署名が検証不能になる。CLAUDE.md 注記 3 行 + 決定論的ガード ~8 行 (importKey 前に JWK の x/y を registry と照合し不一致なら SIGNING_KEY_MISMATCH で fail-closed) + テスト
w2	body サイズ上限が sign のみ	MAX_BODY_BYTES (checkpoint.ts:65 8 KiB) は :146-170 (sign) だけ。index.ts:270 (verify-captcha) / :359 (verify-attestation) / :430 (session/start) は request.json() 無制限、turnstileToken の長さ検査なし (Cloudflare の Turnstile 参考実装は > 2048 を拒否)	現存。~30 行 (readJsonBodyLimited() に切り出して 4 エンドポイント共通化 + token ≤ 2048 + テスト)
w3	handleVerifyCaptcha の catch がログなし汎用 500	index.ts:326-341。handleVerifyAttestation の catch :400-408 も同じ (本文未記載)。JSON パース失敗も try 内なので 400 でなく 500	現存 (+1 箇所)。4-6 行
w4	セキュリティヘッダ無し	nosniff のヒット 0。index.ts:546-573 の fetch() が全経路を包むので 1 箇所で済む	現存。~10 行 + cors.test.ts にヘッダ assert

e2e

#	項目	現行	判定 / 補足
t1	waitForSynced が黙って続行	helpers/app.ts:50-60 (無変更)。#sync-status-item は 90 s assert で厳密、その後の event-count 安定待ち :53-59 だけが ≈9 s で無言 return	現存。3 行 (console.warn / test.info().annotations / throw)。#229 が同ヘルパを使うので先に

ドリフト (起票 → 45a647f → 現在)

担当範囲の実装ファイルで起票後に変わったのは TabController.ts / ResultPanel.ts / VerificationController.ts / TrustCalculator.ts / VerificationQueue.ts / cli.ts / output.ts / verify.ts / TypingProof.ts だが、どれも 21 項目の該当行そのものには触れていない (行番号のずれのみ: v3 +3 / v5 −52 / v6 +5 / c1 +1 / c2 +42 / e2 +2 / e6 +27)。editor の OperationDetector / EventRecorder / StaticEventListeners / TabManager / SessionStorageService、workers src/*、e2e app.ts:50-60 は起票以降無変更。

editor の dead API 一覧 (呼び出し元ゼロ、本文の 4 件 + #268 の 3 件 + 今回発見 7 件 = 14 件)

#	メソッド	位置	行数	出典	推奨
1	TabManager.exportSingleTab	TabManager.ts:1558-1564	7	#238	削除 (#225 再発の地雷)
2	TabManager.exportAllTabs	:1569-1623	55	#238	削除 (shared の MultiFileExportedProof / isMultiFileProof / types.test.ts も道連れ → #231(a))
3	TabManager.reset	:1524-1553	30	#238	削除 (JSDoc「reCAPTCHA」も stale)
4	SessionStorageService.pruneOldSessions	SessionStorageService.ts:721-747	27 (+73)	#238	削除 (deleteSessionById も)
5-7	updateSessionActivity / markSessionInactive / getInstanceId	:289-297 / :302-316 / :388-390	27	#268	#268 の判断に従う (getInstanceId は #237 で使う)
8	SessionStorageService.isSessionActive	:169-172	4	新規	#268 と一緒に判断
9	SessionStorageService.truncateEvents	:584-614	31	新規	削除
10	SessionStorageService.updateTabContent	:469-476	8	新規	削除
11	SessionStorageService.updateTabMetadata	:481-491	11	新規	削除
12	TabManager.getActiveContent	TabManager.ts:1628-1631	4	新規	削除
13	TabManager.getSessionService	:1516-1518	3	新規	削除
14	TabManager.getSyncStatus	:238-240	3	新規	削除

(verify 側の参考: VerificationQueue.clear/terminate と ResultPanel.reset() も呼び出し元ゼロ。後者は #215 の修正で使えるはずの片付け処理が未配線ということ)

深刻度の再評価

ラベル severity:medium はまとめとしては妥当だが中身は二層:

• medium 相当 (採点者が誤読 / 損をする): v2、v5 (package 未提供が緑で隠れる = overclaim 抑止方針に反する)、c1 (クラス単位 ZIP の Summary が消える)、c3 (不変条件の構造的な破れ)、w2 (無制限 body)
• low: v1 v3 v4 v6 v7 e1〜e6 w1 w3 w4 t1

推奨: サブシステム別に分割する

並行セッションの着手印 (status: in progress) が Issue 単位なので、1 Issue のままだと 1 セッションが 5 パッケージ分を占有し、Closes #238 を書けるのは最後の 1 PR だけになる。

新 Issue / PR	含める項目	備考
[verify] 小さな表示不整合まとめ	v1 v2 v3 v4 v5 v7 + c2 の web 側 ('sampled' 掃除)	v2 は #215 と同じ TabController → #215 と同一 PR か直後
[verify] 複数 proof の集約表示 (v6)	v6	UI 設計が要るので単独。優先度低
[verify-cli] exitCode 化 / audit help / analyzer 実行順	c1 c2(CLI) c3	#218 (cli.ts / verify.ts) と #266 (output.ts) と同じファイル → #218 または #266 の実装 PR に同乗が最も衝突が少ない
[editor] dead API 除去と小修正	e1 e2 e4 e5 e6 + dead API 1-4, 9-14	#268 の 3 件 (+8) は除外。exportAllTabs 除去で shared の MultiFileExportedProof も消し、#231(a) で §5.4 を削る
[workers] 小さな硬化まとめ	w1 w2 w3 w4	#226 / #227 と checkpoint.ts が重なるので順番に。1 PR
(単独 3 行 PR)	t1	#229 より先に。または #229 の PR に同乗

分割後は本 Issue に分割先を書いて close。分割しない場合でも PR は上の 5-6 本に分け、各 PR 本文に Refs #238 (v1,v2,…)、最後の PR に Closes #238。

判断が要る点

1. 分割するか (推奨: する)
2. v6 の見せ方: (A) ステータスバーに N/M passed + 失敗数 (自動オープンは維持) / (B) 失敗 proof があれば赤いタブを優先して開く。推奨 (A): CLI の Summary と語彙が揃う
3. e3 の dead API: 本文の 4 件 + 今回の 7 件は削除推奨 (特に exportSingleTab)。[editor] セッションのライフサイクル API が 3 つとも呼び出し元ゼロで、isActive が false に戻る経路が無い #268 の 3 件は [editor] セッションのライフサイクル API が 3 つとも呼び出し元ゼロで、isActive が false に戻る経路が無い #268 の方針に従う
4. w1 を注記で済ませるかガードを入れるか: 推奨 ガード (文書ルールより決定論的に強制でき、同一 keyId 差し替えという運用ミスをデプロイ直後の 500 で顕在化させる)
5. c1 で早期 exit (usage / flag error) も exitCode に揃えるか: 推奨 揃える

---

_{🤖 Assisted by Claude Code}