バグ修正・障害対応トラッキング

本ドキュメントは、バグ修正・障害再発防止・コード品質改善の案件を管理するものです。 追加開発案件（TODO_future.md）のエンハンスメントとは分離して管理します。

修正状況サマリー（2026-06-15 時点）

1. 修正完了（29件）

優先度の定義

修正済みバグ一覧

| MAS-295 | テストT4-03: MAS-024 BEPセクションが未登録科目として検出 | 🟢 | 2026-04-16 | 2026-04-16 | MAS-024で追加した「📊損益分岐点分析(BEP)」セクションの行ラベルがテストのSKIP_PATTERNSに未登録のため、未登録科目として検出される | テストのSKIP_PATTERNSにBEPセクション用パターンが未追加だった | SKIP_PATTERNSに「📊」「損益分岐点」「BEP」等を追加 | — | | MAS-296 | テストT4-21: MAS-020 YoY差異列追加による最終月列のずれ | 🟢 | 2026-04-16 | 2026-04-16 | MAS-020で追加したYoY差異列（△YYYY-MM）がP/L末尾に配置されるため、最終月列の取得がずれる | テストが ytdHeaders.length - 1 で最終列を固定参照していた | △列と空白列をスキップして最後の実データ列を特定するよう修正 | — | | MAS-298 | Action A acc is not defined 未定義変数エラー | 🔴 | 2026-04-30 | 2026-04-30 | 「財務諸表マート再構築」実行時に acc is not defined で停止し、マート更新が完了しない実障害 | processInvoiceApprovals の auditLog 引数で未定義変数 acc を使用していた (リネーム漏れ・スコープ外参照) | auditLog 引数の acc を row[invIdx['科目名']] に置換 (mas/400_domain/410_subledger_engine.js・PR #460・commit 7104460) | — (PR #460 反映後の手動再実行で正常動作確認済・回帰テスト追加候補) | | MAS-299 | Action A & cc_importer findTrueLastRow_ is not defined 架空関数エラー | 🔴 | 2026-04-30 | 2026-04-30 | 「仕訳A (INV承認 → JNL生成)」実行時 + cc_importer 実行時に findTrueLastRow_ is not defined で停止 | 架空関数名 findTrueLastRow_ を呼出していた (mas/200_data/202_repository.js の正規関数名は findLastRow_)・failure_patterns #18-#20 (命名造語禁止) の事例 | findLastRow_ にリネーム (mas/400_domain/410_subledger_engine.js + mas/500_import/501_cc_importer.js・PR #460・commit fdc0b3a) | — (PR #460 反映後の手動再実行で正常動作確認済) | | MAS-300 | 73_bs_plan 計画 B/S が実績 71_bs と大きく乖離 (cash plug 過小) | 🟡 | 2026-04-30 | 2026-05-01 | 73_bs_plan の現預金が実績 71_bs と乖離 (2026-02 で約 -605K)。計画 B/S で資金見通しが過度に悲観的になり、経営判断ミスリードリスク | 計画 B/S が「全 INV 即決済前提」のため未払系負債が積み上がらず、現預金がマイナス側に振れる構造的バグ。期ずれが計画 B/S に蓄積されない | 3 段階のロジック改善 (commits d748ed5 → 3aaa04e → c21c3dc → 1f04ef5) で案 A 改 2 に確定。mas/600_report/601_datamart_ingest.js の dmIngestPlanData_ で INV の 決済日_実績 列を期ずれ解消月の判定起点とする: (a) 決済日_実績 記入済 → 実績 PHASE 2 と同月で期ずれ解消 (sStr = settleActStr) / (b) 決済日_実績 空 + 決済日_計画 ≤ 当月 → 未消込のまま残す (sStr = '9999-12') / (c) それ以外 → 決済日_計画 をそのまま使用。残乖離 ±30K: 地代家賃前払 INV 表示差で許容 (cash plug 効果は同値) | ✅ failure_patterns #34 (計画 B/S が実績と乖離・cash plug 過小) として教訓化済・PR #460 commit 1f04ef5 で確定 | | MAS-301 | 銀行 CSV 合算マッチング ±1 円厳密で口座振替割引等の少額差により外れる | 🟡 | 2026-05-01 | 2026-05-01 | 社会保険料 (厚年金 + 健保) の口座振替で銀行引落額 149,950 円 と STL 合計 150,950 円 (74,575 + 76,375) が ちょうど 1,000 円 ずれて合算候補に提案されない。社会保険料の引落仕訳が UNMATCHED 扱いで人手対応必要 (口座振替割引と推測) | 既存 Pass 2 (合算マッチ) の許容誤差が ±1 円ハードコードのため、実運用で発生する口座振替割引・端数調整等の少額差を救済できない | findComboGroup_(candidates, txAmt, txType, txYm, tolerance) に許容誤差を引数化リファクタ + Pass 2.5 (ソフト合算) 追加: 既存 Pass 2 (±1 円厳密) で不成立時に ±max(1000, txAmt × 1%) で再試行・ヒット時のラベル 合算候補(差額+1,000円) 等で差額明示・背景色は黄色 #FFF2CC (Pass 2 厳密合算 = 緑 #D5E8D4 と視覚区別)・確認FLG=false で書込 → 必ず人間確認を要求 (mas/500_import/502_bank_importer.js・PR #465・commit fb7b68c) | — (PR #465 反映後の手動確認で社会保険料合算が候補に上がることを確認・回帰テスト追加候補) | | MAS-302 | applyBankSettlement のフィルター silent-fail (決済日_実績等が書き込まれない) | 🔴 | 2026-05-01 | 2026-05-01 | 33_wrk_bank に「決済ステータス = 未処理」フィルターを設定した状態で消込実行すると、消込後に 33タブを見ても 決済日_実績 列が空のまま。Action B (自動仕訳生成) が起動条件 (33タブの「消込済 かつ 自動仕訳JNL_ID あり」判定) を満たさず止まる二次被害あり | setValue('消込済') で対象行が即時フィルター非表示化 → 後続の 決済日_実績 / 消込手段 / 取込ハッシュ setValue が silent-fail する Google Sheets API の挙動 (1 つ目の setValue でフィルター対象列が変わると Sheets が即フィルター再評価して行が hide され、後続 setValue が無効化される) | セル別 setValue 4 回 → 1 行 setValues 1 回に集約・API call 間にフィルター再評価が挟まる隙を排除する原子書込化 (mas/500_import/502_bank_importer.js・PR #465・commit c069b63) | ✅ failure_patterns #35 (フィルター適用中の連続 setValue が silent-fail) として教訓化済・PR #465 commit c069b63 で確定 | | MAS-361 | 73_bs_plan 売掛金が当月決済予定 INV で 1 ヶ月余分に残る (sStr 境界条件 ≤当月 → <当月) | 🟡 | 2026-05-07 | 2026-05-07 | dmIngestPlanData_ の sStr 判定条件 (b) 決済日_計画 ≤ 当月 が当月を含むため、決済日_計画 = 当月 かつ 決済日_実績 未入力の売上 INV が sStr = '9999-12' となり 73_bs_plan の売掛金が入金予定月で解消されず 1 ヶ月余分に残る | ≤ が当月も含む境界条件ミス。未消込扱いにすべきなのは「過去月」のみ | 601_datamart_ingest.js の dmIngestPlanData_ sStr 判定 (b) を ≤ 当月 → < 当月 に修正 (PR #509・commit d32cfa1) | — (PR #509 反映後の 73_bs_plan 目視確認で 2026-05 売掛金が解消済を確認) | | DRP-375 | chat UI 復元セッション + フォーム空で停止トグルが無反応 (required バリデーション遮断) | 🟡 | 2026-06-04 | 2026-06-04 | リロードで復元したセッション表示中、フォームが空のまま停止トグルを押すとボタンが form の required バリデーションに遮断されクリックが無反応になる。PR #1375 の mocked-route e2e が導入当日に発見 | 停止トグル button が form 内の submit 扱いで、フォーム必須項目が空だとバリデーションが先に発火しイベントが実行されない | button に formNoValidate を付与してバリデーションを迂回 (PR #1376) | ✅ mocked-route e2e (drp/test/e2e/ui/, CI ui-e2e job) でカバー | | DRP-374 | Decision Pipeline queue consumer が message を pickup せず session が queued のまま stall (EC-3 watchdog が idle 300s で error 終端・審査未実施) | 🟡 | 2026-06-04 | 2026-06-04 | draft docs-incremental-build の審査 run (session 906aafc2) が watchdog-timeout で終端し審査が一切実行されなかった。telemetry 実測で enqueue (06:22:23) と先行 run 開始 (06:22:24) が 1 秒差 — 実効直列 consumer (max_batch_size=1) の正常な順番待ち (8.3 分) だったと確定 | ①QUEUED_STUCK_MS=300s (起点=enqueue) が queue 順番待ちと取りこぼしを区別できず誤検知 ②error 終端後に配達された message を R4 終端ガードが ack-skip → 永久不実行 (遅延=死の合せ技) | 二段構え (PR #1398): ①QUEUED_STUCK_MS 5分→30分 (worst-case 1 run 占有 25分 をカバー) ②R4 ガードに回復路 — error.gate='queue_pickup' (consumer 未着手が確定している誤検知) は ack-skip せず実行再開 (isRecoverableQueuedTimeout())。完走 telemetry が INSERT OR REPLACE で偽 error 行を上書き。max_concurrency 引き上げは numbering 重複採番 (DRP-377) 再導入リスクで見送り | ✅ session_watchdog.test.ts 18 件 (回復判定 5 件追加) + 実機検証 2026-06-04: 並走 3 run で後発 2 run が queued 370s 超 (旧閾値なら死) を通過し完走、watchdog-timeout 新規 0 | | DRP-371 | chat UI 経路の draftId=null で ADR-0109 goalpost loop-breaker が構造的に無効 (無言スキップ) | 🟡 | 2026-06-04 | 2026-06-04 | chat UI 起点の全審査で telemetry の draft_id が NULL → loop-breaker ガード (state.draftId &&) で無言スキップ。2 連続 CV 却下 × 盲点全入替でも escalate されず plain 差し戻しのまま (draft crossval-systemic-fix で実発生)。escalate KPI も常時 0 で無効化が観測に乗らない | 真因はサーバ側 — chat UI は元から draft_id を送信していた (active-draft-id hidden input) が、/chat/start handler が body の draft_id を受領しておらず DO state の draftId が常に欠落 | PR #1402: ①サーバで draft_id 受領 (DRAFT_ID_RE 検証) → DO state 伝播 + triggerSource:'web-ui' 明示 ②loop-breaker スキップ時の crossval_loopbreaker_skipped 警告ログ ③UI 防御 — 紐付け可視チップ + ✕ 解除 + localStorage 永続化 (リロードで履歴連続性が切れる逆 stale も解消) | ✅ mocked-route e2e 3 本 (draft_binding.spec.ts: draft_id 送信/解除→未送信/リロード永続化)。実機: 次回 chat run の telemetry で draft_id/trigger_source 記録を確認 | | DRP-379 | chat UI 開始/停止トグルの誤連打で開始直後の審査が即キャンセルされる | 🟡 | 2026-06-04 | 2026-06-04 | ADR-0101 の単一トグルボタン (開始⇄停止) は、ダブルクリックすると 1 打目で審査開始 → ボタンが即「審査をキャンセル」にトグル → 2 打目がそれを踏んで開始した審査が即キャンセルされる。実運用で発生 (代表取締役観測・変更指示) | 開始と停止を同一ボタンに同居させた UI 設計 (ADR-0101 §決定「単一トグルボタン」)。連打への防御がトグル先のアクション実行になっていた | PR #1411 (ADR-0101 corrigendum 方式・決定本文不変): #cancel-btn (type=button) を新設し協調キャンセル/予約/復元停止を移設。審査中は #start-btn を disabled「審査中…」(二重 submit 防止・409 排他は従来どおり主防御)。副次効果: type=button 化で DRP-375 の formNoValidate 回避策が構造的に不要となり撤去 | ✅ mocked-route e2e を分離ボタン状態機械で全面更新 + 誤連打回帰テスト新設 (ダブルクリック → cancel 0 件・start 1 回)。e2e 11/11 pass | | COM-373 | docs サイトの glossary ホバー説明が表セル内で見切れる (tooltip overflow clip) | 🟢 | 2026-06-04 | 2026-06-04 | .glossary-term ツールチップ (absolute) が .table-wrapper { overflow-x:auto } に clip され、表内の用語では説明の後半が読めなかった | absolute 配置の tooltip は祖先 scroll コンテナに clip される CSS の構造的制約 | PR #1415: hover/focus 時に JS が viewport 座標を測り fixed 配置 (.gt-fixed / .gt-fixed-below) へ動的切替して overflow から脱出。PC のみ (モバイルは既存 @media fixed が担当)。上端近くは下向き表示・左端 clamp | ✅ docs-build 615 頁 + Playwright 実 hover で fixed/可視/座標追従を確認 (throwaway)。最終目視は Pages preview | | DRP-377 | Decision Pipeline numbering gate が open 中の ADR PR を考慮せず採番 → 並行起案で ADR 番号二重発行 | 🟢 | 2026-06-04 | 2026-06-04 | main の docs/adr/ 既存ファイルだけを見て採番するため、未マージ ADR PR が open 中の別 draft 通過で同一番号が二重発行 (ADR-0110 実発生 → 0111 リナンバー #1391) | 採番ロジックが open PR の予約番号を見ていなかった | PR #1416: GET /pulls?state=open → /pulls/:n/files から docs/adr/NNNN- を予約番号として抽出し main 最大と合算。fail-open (スキャン失敗は警告ログ + 従来動作、adr-lint duplicate が防壁の二段構え)。純粋関数 numbering_pure.ts に切り出し | ✅ numbering_pure.test.ts 8 件 (実シナリオ: main 0109 + open PR 0110 予約 → 0111 採番)。実機: 次回 numbering 実行時の numbering_pr_reserved ログ | | DRP-380 | chat 経路の escalate で slug/採番がスキップされ PR 起票不能 + 「PR を起票しました」虚偽表示 | 🟡 | 2026-06-04 | 2026-06-04 | DRP-371 修正で chat 経路の loop-breaker が初発火した先で露出。escalate 結果が adrSlug/adrNumber 欠落 → 自動 PR なし + 「PR 作成」ボタンも 400 で手詰まり、なのに「PR を起票しました」と表示 (session 23dc778e・draft agent-knowledge-layers-convention) | escalate の slug/numbering ガードが state.dryRun === false (CI 経路前提) で、chat 経路の dryRun 未設定 (null) がスキップ扱い。rejectionMsg は無条件ハードコード | PR #1420: ①ガードを dryRun !== true へ (明示 dry-run のみ副作用スキップ) ②buildEscalateAcceptMessage 純粋関数でメッセージを経路別出し分け (CI=起票済み / chat=ボタンから起票 / dry-run=プレビュー)。自動 PR 条件は不変 (chat は HITL でボタン起票) | ✅ buildEscalateAcceptMessage 4 件 (経路 3 分岐 + round-cap)。実機: 該当 draft の再 run で PR 作成ボタンが機能すること | | DRP-378 | chat UI 中間結果パネルの要否判定が常に「判定: - / モード: -」(triage partial 空) | 🟢 | 2026-05-30 | 2026-06-04 | ADR-0089 corrigendum (2026-05-30) の既知ギャップが 2026-06-04 ユーザー観測で再浮上。ステッパー②は Standard と確定表示されるのに中間結果パネルは「-」のままで矛盾。本日の全 run で partial:triage = {} を実測確認 (デプロイ退行ではない) | triage は preGraph (非ストリーミング) で実行され streaming ループの patchPartial が捕捉不能。main graph の triage ノードは needsAdr 設定済で {} を返し、空 partial が書き込まれて UI が - 表示 | PR #1405: ①consumer の pre 解決点で patchPartial('triage', ...) を明示書込 (early-reject でも判定理由を表示) ②extractGatePartial('triage') は needsAdr 不在の空出力で null を返し、streaming ループによる正値の {} 上書きを防止 ③ADR-0089 corrigendum に解消を追記 | — (実機: 次回 chat run で中間結果パネルに 判定/モード が表示されることを確認) | | DRP-376 | Decision Pipeline queue 再配信で全 gate 3 周再実行 (通過 result の差し戻し上書き・LLM 課金 ~3 周・telemetry 0 行) | 🔴 | 2026-06-04 | 2026-06-04 | ADR draft 審査 (session bedb9912) で発見。フル 10 gate 実行 (16 分) が Queues consumer の invocation 時間上限を超え、complete 書込後・ack 前に worker が kill → at-least-once 再配信が running 状態を素通りして全 gate を 3 周再実行。通過 result 2 件が差し戻し result に上書きされた | invocation 上限超過 kill と at-least-once 再配信の組合せに対し、再配信を検出して skip するガードが無かった | isInflightRedelivery() を追加: running かつ updatedAt 20 分鮮度内の再配信 message は ack-skip (PR #1382)。残課題 2 点 (未対応・記録のみ): ①フル run が invocation 上限を超える構造自体 (gate 単位 chunk 化等は将来の再設計) ②kill により telemetry が失われる問題 | — (実 run での再発監視。残課題①が解消されるまで根本原因は残存) | | COM-0381 | 外部 API 書込 (curl POST/DELETE 等) が層① hooks の対象外で承認の拡大解釈を技術的に防げない | 🟡 | 2026-06-04 | 2026-06-09 | 2026-06-04 セッション監査の実害③ (ADR-0115 §1.2)。包括的「yes」を外部 KV POST の承認とみなして curl で外部書込を実行。pre_bash_guard.sh + permissions.deny は main 直 push・rm -rf 等のローカル不可逆操作のみ対象で、外部 API 書込 (DRP KV POST/DELETE・外部 SaaS API) は技術強制外だった | 外部書込 (curl/wget の書込メソッド) を検知する技術ガードが存在せず、行動規範 (層④ memory・層⑤ Skill「原則」) の運用統制のみに依存していた | pre_bash_guard.sh に外部書込検知を追加。ハードブロックでなく permissionDecision=ask でハーネスにユーザー確認を要求 (curl/wget の -X POST/PUT/PATCH/DELETE・--request/--method・--upload-file。gh・localhost は除外、-X(大文字) で proxy -x と区別)。Claude が token 等で自己バイパスできない点が ask の要 (PR #1632) | ✅ ペイロード 7 ケース (ask/allow/block 分岐) + headless 実機で permissionBehavior=ask・curl 非実行を確認 | | DRP-0382 | ADR-0119 Phase C-flip が CV system プロンプトへの静的 evidence ルールで golden FN 回帰 + 修正前コミットを本番デプロイ (実害ゼロ) | 🟡 | 2026-06-09 | 2026-06-09 | Phase C-flip (PR #1600・verify_in_code × 非stale evidence で却下を降格) のデプロイで 2 事故が連鎖。①evidence-resolution 指示を CV の system プロンプトへ静的に載せた結果 undermines がドリフトし golden #11 が baseline FN 0/5 → 5/5 に回帰。②git checkout HEAD~0 で detach → amend → push したため branch ref が動かず 修正前 (回帰版) コミットを本番デプロイ。実害はゼロ (露出 04:48–05:02Z の 14 分間に実審査 run 0 件) | ①CV プロンプトは静的ルール追加に敏感で、付帯ルールを system に常時載せると evidence 無し run の判定境界がドリフト する ([[crossval-static-prompt-drift]])。②detached HEAD で amend → push は branch ref を更新せず旧コミットを push 先に上げる — 検証済みローカル HEAD ≠ push されたコミット ([[verify-pushed-sha]]) | hotfix PR #1603: ①evidence-resolution 指示を evidence 添付時のみ userMsg へ動的注入 (EVIDENCE_RESOLUTION_INSTRUCTION)。evidence 無し run は baseline と byte 同一 → golden #11 FN 0/5 復帰。②push/PR 後に git rev-parse origin/<branch> == ローカル HEAD・git show origin/main:<file> を grep して deployed bundle を SHA 突合 する手順を確立。05:02Z に正版デプロイ | ✅ golden eval を baseline (origin/main worktree) との multi-run 比較で #11 FN 0/5 を確認 (tmp/crossval_multirun.sh)。memory [[crossval-static-prompt-drift]] / [[verify-pushed-sha]] に教訓化。telemetry crossval_evidence_demoted_count (migrate-v10) を Phase C-flip 初回降格の tripwire として監視 (当面 0 想定・> 0 で初の実降格＝分類妥当性を要確認) | | DRP-382 | /chat/create-pr (webhookNode) が非冪等 — 既存 branch/file への再 POST で 422 | 🟡 | 2026-06-10 | 2026-06-11 | PR 作成後に再度 create-pr が走ると、既存 branch への POST /git/refs が 422 "Reference already exists"、既存 file への PUT /contents が 422 "sha wasn't supplied" で失敗し、既存 PR を返さずエラーになる構造だった | 多段 GitHub 操作 (branch 作成 → file 作成 → PR 作成) の各ステップに、既存リソースを検出して流用/更新する冪等化が無かった | PR #1722 (4f7f6122・元目的は断続 401 での多段操作の途中再開) の resume ロジックが本シナリオも構造的に解消: ①branch 既存 (422 Reference already exists) は catch して続行 ②file 既存は GET で sha 取得し PUT に付与 (in-place 更新) ③open PR 既存は GET /pulls で検出し既存 URL を返す (webhook.ts L99/L119/L182)。フロント側の再活性化抑止は PR #1679 で対応済 | — unit test 追加を試みたが vitest-pool-workers の制約で collect 不可 (webhook.ts は state.ts/gateway.ts への型依存経由で langchain→langsmith を引き worker pool で評価不能 = vitest.config 明記の Phase 0 制約)。2026-06-15 コード精査で 3 失敗パス全ての冪等化を確認し解消と判定 |

2. 未修正・調査中（5件）

調査ポイント

• 仕訳ステータス=='計上済' の判定漏れ有無（INV 側の 自動仕訳JNL_ID チェック L196）
• 自動仕訳JNL_ID が途中でクリアされるケース（手動編集 / RPA 再起票との相互作用）
• ordMap 初期化の 0 フォールバック currentBal \|\| totalIncTax（L143）と複合した残高復元シナリオ
• 同一 ORD に紐づく複数 INV を一括処理する際の ordBalUpdates の累積計算順序

3. バグ登録ガイドライン

ID採番ルール

• 形式: <PREFIX>-NNNN（4 桁ゼロ詰め・2026-06-04 改定）。番号空間は全 prefix 共有の連番（次は 0383、prefix を問わず重複させない）。旧 ID との対応を自明に保つため、リナンバー時も番号は変えず prefix のみ振り替える
  • 3 桁では不足見込みのため 4 桁化（ADR 番号 0001〜 と同じ体裁）。既存の 3 桁 ID（〜380）は grandfather — git コミットメッセージ内の旧 ID は書き換え不能のためリナンバー・ゼロ詰め化はしない。grep 時は 3 桁/4 桁の両表記を考慮する（例: MAS-38[0-9]\|MAS-038[0-9] ではなく番号部分で検索）
• PREFIX は対象システムで選ぶ:
  • MAS-: 管理会計 GAS（000_infra〜900_test, webapp_client, GAS デプロイ）
  • DRP-: Decision Pipeline（drp, chat UI, 審査 graph/queue/telemetry）
  • COM-: 共通基盤・横断（認証/secret 管理、docs サイトビルド基盤、CI/CD、複数システムにまたがるもの）
• docs 運用バックログは別軸の DOC-OPS-NN（TODO_future.md §7）。バグ・障害は本ファイル、エンハンスメントは TODO_future.md
• 旧表記「BUG-NNN（3桁連番）」は廃止（実態は MAS-NNN 採番だったため。2026-06-04 改定）

リナンバー対応表（2026-06-04 改定・旧 MAS prefix からの振替）

git のコミットメッセージ・マージ済み PR の merge commit 内には旧 ID が残る（書き換え不能）。旧 ID を見たら本表で読み替える:

（MAS-372 は案件未割当のまま欠番。MAS-370 以前はリナンバー対象外 = grandfather）

優先度の判定基準

必須記録項目

[2026-06-01] GAS デプロイ CI の secret stale 化 → prod push Requested entity was not found (PR #1231)

症状

prod GAS デプロイ CI が直近 60 回連続で失敗。clasp push が Requested entity was not found (404) を返し、prod Web アプリへの反映が停止していた。

根本原因

2 点の複合:

1. CLASPRC_JSON (clasp 認証トークン) の失効 — OAuth refresh token 失効。
2. CLASP_SCRIPT_ID_PROD secret の stale 化 — secret 設定日 (2026-04-02) が .clasp.prod.json の scriptId 修正コミット (2026-04-14, 末尾 …Bm_4 へ変更) より前だったため、GitHub Secret が旧 prod scriptId を保持。CI は stale な scriptId で push しようとして 404。

• 副次: deploy.yml の trigger が paths-ignore 方式で、非 GAS 変更 (drp/** 等) でも prod push が誤発火し失敗を量産していた。

修正

• CLASPRC_JSON を動作中の ~/.clasprc.json から再同期。
• CLASP_SCRIPT_ID_{DEV,PROD} を .clasp.{dev,prod}.json の値に再同期。
• CLASP_DEPLOYMENT_ID_{DEV,PROD} を scripts/deploy.sh のハードコード値 (= clasp deployments 実在 ID) に合わせて登録。
• deploy.yml の trigger を GAS 実体 allowlist (mas/000_infra/**〜mas/900_test/**, mas/templates/**, mas/appsscript.json, .clasp.{dev,prod}.json) + workflow_dispatch に限定 (PR #1231)。
• 結果: dev CI green → prod CI green、prod deployment …@17 → …@19。

再発防止 (地雷・切り分け順)

scriptId / OAuth を変更したら、GitHub Secret 5 本を .clasp.*.json から必ず再同期する: CLASPRC_JSON / CLASP_SCRIPT_ID_{DEV,PROD} / CLASP_DEPLOYMENT_ID_{DEV,PROD}。 secret は設定時点の値で固定され .clasp.*.json の後続コミットを追従しないため stale 化する (= 今回の罠)。 切り分け順: dev で gh workflow run deploy.yml --ref <feature-branch> (ref≠main → dev 対象) で green 確認 → --ref main で prod。

補足 (clasp 3.3.0 cp 切替の監査結論)

scripts/clasp-switch.sh の cp .clasp.${ENV}.json .clasp.json 方式は clasp 3.3.0 でも正しく機能 (cp dev→dev / cp prod→prod を実証)。「push:prod が dev を push していた」過去の懸念は再現せず＝監査問題なし。

関連ドキュメント

• 申し送り: tasks/prompts/handover_2026-06-01_gas-deploy-ci-resolved_to_sub.md / main_2026-06-01_gas-deploy-auth-ci-residuals.md
• changelog: 2026-06-01 PR #1231

[2026-05-27] Decision Pipeline async 実行時 null reference crash (PR #1035/#1036/#1037)

症状

Pipeline の async 実行 (Web UI / API 経由) で「Cannot read properties of null (reading 'needsAdr')」エラーが発生。Web UI では polling timeout (10 分) またはエラー表示。

根本原因

3 つの問題が重層していた:

1. conditional edge の null state: LangGraph の conditional edge で s.needsAdr を直接アクセスしていたが、triage ノードの LLM 呼出し失敗時に state s が null になることがあった
2. streamEvents の結果キャプチャ不備: Consumer Worker が event.name === 'LangGraph' でハードコードして最終結果を取得していたが、LangGraph の streamEvents v2 では実際のイベント名が異なり lastResult が常に null になっていた
3. Queue メッセージ滞留: 失敗した実行が max_retries=3 でリトライされキューに 21 件滞留。新規メッセージの処理が後回しになり polling timeout に至った

修正

• src/graph.ts: 全 conditional edge に optional chaining (s?.needsAdr / s?.socraticPass / s?.rejected) (PR #1035)
• src/index.ts: preGraph.invoke() null guard → 502 レスポンス (PR #1013)
• src/queues/pipeline_consumer.ts: preGraph null guard + lastResult null guard + streamEvents 結果キャプチャを event.data?.output に修正 (PR #1036/#1037)
• public/chat.html: pollSession の null result guard (PR #1036)

再発防止

• Pipeline README にエラーハンドリングテーブルと Queue 滞留時の Purge 手順を追記
• operator_guide §4.3.1 に差し戻し再投入ルールを明文化 (Pipeline 生成済み本文の再投入禁止)

[2026-05-14] Cloudflare Workers サブリクエスト上限超過 (PR #706)

症状

Decision Pipeline 実行時に Too many subrequests by single Worker invocation エラーが発生し、パイプラインが途中停止。

根本原因

consistency.ts が ADR ファイルを 1 件ずつ個別 fetch していた (38 件)。LLM 呼び出し (~10) + Durable Object 等と合計するとデフォルト上限 50 を超過。

修正

• wrangler.toml: [limits] subrequest_limit = 1000 追加（即時緩和）
• consistency.ts: GitHub GraphQL 一括取得に変更（39 → 2 サブリクエスト）

再発防止

• 新ノード追加時は fetch() 呼び出し数をカウントし、パイプライン合計が 50 を超えないか確認する
• 複数ファイルを取得する場合は GitHub GraphQL の field alias 一括取得パターンを使う

関連ドキュメント

• 追加開発案件 (TODO) — エンハンスメント（機能追加・改善）
• テスト手順 — 統合テスト
• データ整備 — データ修正・マイグレーション