作業ログ 2026-06-04 — SCALE CRM v11.5.57

13:08 - v11.5.57 LIVE（架電パートナーFB 3件根治）

対象

SCALE CRM (scale-lead) / 本番 https://crm.scale-group.co.jp/ / cache-bust v=202606041307

大串FB（3件・スクショ付き）

1. メンバー(喜多さん)が株式会社ワカヤマをアポ獲得・ステータス更新・モーダル入力・Slack通知も成功したのに、PM(大串)端末の架電リストではワカヤマのステータスが空のまま。本日の架電履歴にも出ない。「私のアカウントと架電メンバーで架電リストが同期されてないかも？」
2. 大串画面に「knowledge_hubの異常な縮小(5/5件)を検知しブロックしました」トースト頻発（スクショ右下）
3. Slackアポ報告に商談(お打ち合わせ)URLも入れて欲しい（URL：〜〜 の形）

戦略（v9.155教訓）

推測修正で17回失敗した轍を踏まないため、3 Agent 並列で全経路調査 → 真因確定 → 全保険1リリース。

真因①: since 窓落ちレース（同期されない・実害の主因）

• per-row 同期は updated_at > since（厳格 >）の差分pull
• クライアントは GET 成功のたび since を server現在時刻まで前進（core.js pollPerRow _setSyncAt(pid, j.now)）
• D1 の write→read 伝播遅延で、喜多さんのPUTコミットと大串のGETが交差すると、ワカヤマ行の updated_at <= since になり差分から恒久脱落 → 手動リロード（全件取得）まで復旧しない
• call_list は /api/changes（全体保険）が効かない差分専用経路（changes.ts は app_data のみ）なので一度落ちると直らない
• → 症状（大串側で空・本日履歴に出ない・喜多さん側は完了）と完全一致

真因②: knowledge_hub 異常縮小ガードの誤発火（トースト）

• v11.5.55 で異常縮小ガードを「3層共通 + prev≥2/30%」に緩めた
• knowledge_hub 等の object-singleton で、cache形状（_khFlattenCache による flatten後の複数キー: audio/docs/insights/updates/callKnowledge）と diff基準 prev 形状（_default 1キー）が永続的に食い違う
• pollPerRow reconcile diffPush が「prev=5 → next=0（100% removed）」と誤計算 → ガード誤発火（データは実在・トーストだけ出る）
• 各 pollPerRow は独立 try/catch なので、これが call_list 同期をブロックしているわけではない（症状①とは別問題）

真因③: アポ報告に商談URLが無い

• slackNotifyApo（lib/pagecore_slack.js）のメッセージに meetingUrl が含まれていなかった
• meetingUrl は既にアポ獲得モーダルの必須項目で保存済み → Slack文に1行足すだけ

修正内容（全保険1リリース v11.5.57）

①同期レース根治（3重保険）
| # | 修正 | ファイル:行 |
|---|---|---|
| 1 | pollPerRow の since を10秒オーバーラップ保存（_isoMinusMs 新設・直近10秒を毎tick再pull） | core.js:571, 3659 |
| 2 | サーバGET updated_at > → >=（境界窓を塞ぐ・client pend/prev で冪等吸収） | functions/api/calls/index.ts:36 + v2/sync/index.ts:61 |
| 3 | call_list は60秒ごとに since を捨てて全件再取得（window._clFullReconcileAt・差分窓落ちしても最大60秒で自動復旧＝二度と恒久脱落しない保証） | core.js:3651 |

②ガード是正（誤発火停止）
- 異常縮小ガードを call_list(array) 限定に戻す + 閾値是正（全消し next=0 かつ prev≥3 OR 大規模半減 prev≥10 かつ 50%以上）（core.js:3568付近）
- → knowledge_hub/targets/section_perms は対象外＝誤発火停止。members は v9.221 専用防御で保護継続。pull直後の数件減では誤発火しない

③アポ報告URL追加
- slackNotifyApo のアポ獲得報告に「URL：」を商談日の直後に追加（空の時は行省略）（lib/pagecore_slack.js:976付近）

デプロイ・検証

• bash deploy.sh → 全59関数OK・構文OK・本番200・D1 ok・cache-bust v=202606041307
• pre/post tar.gz（scale-lead-2026-06-04-1307-pre / 1308-post）
• 本番 core.min.js?v=202606041307 確認・Direct URL も200回復

非破壊

• v11.5.55 のステータス全消え防御（shadow / ORDER BY rowid / forceFetch skip / field-merge）不変
• AI共創・Defense系・per-row層 不変

未解決（別タスク化）

• knowledge_hub shape-mismatch の根本（flatten設計の誤PUT・30秒ごとに knowledge_hub_rows へ誤った行を書く・D1データ汚染の可能性）→ spawn_task で別タスク化（慎重対応・D1テーブル確認 + クリーンアップ + flatten設計修正）
• v11.5.57 はトースト表示を止めた（ガード call_list 限定）だけで、knowledge_hub の誤PUT自体は残る

実機検証依頼項目

1. 喜多さん（メンバー）→ ワカヤマ更新が大串端末に60秒以内に反映されるか（since レース根治確認）
2. knowledge_hub の異常縮小トーストが消えたか
3. アポ報告 Slack に「URL：<商談URL>」行が出るか
4. もし依然同期されない場合: 両端末で F12 → window._clRowSyncAt['RYS']（since値）と、喜多さん端末のPUT応答の now を比較 → さらなる真因特定

守るルール

• データ/同期系FBは推測修正禁止・トレーサ/全経路調査 + 全保険1リリース（v9.155教訓）
• per-row 同期の since は「オーバーラップ + 全件reconcile」で窓落ちを構造的に塞ぐのが定石

最新基準点: ~/Obsidian/SCALE-Brain/31_システム開発部/_SCALE_CRM_最新基準点.md (phase_v11_5_57_同期レース根治)
本番URL: https://crm.scale-group.co.jp/