⚙️ Vault運用

2026-07-27_作業ログ

最終更新 2026年08月02日 ／ 90_Meta/Claude作業ログ/2026-07-27_作業ログ.md

作業ログ 2026-07-27

16:12 - /handoff 実行（全テーマ）

このセッションで扱ったテーマ（全部・7/21〜7/27の連続セッション）

  1. SCALE CRM リスト依頼まわりの根治+FMT刷新（v11.6.15/25/26/27） — システム作業 — 完了
  2. リストプール大改修（0件根治→per-row全面刷新→過去データ全量復旧118,072件→複数選択フィルタ） — システム作業 — 完了
  3. 架電リスト改善（地域フィルタ・フィルタ1行化） — システム作業 — 完了
  4. パートナー単価改定の全反映（CRM/Partner Program/マニュアル） — システム作業+運用 — 完了（E以降=契約書・アナウンス等はやらない確定）
  5. メンバー苦情の根治（最上部ワープ/タブ同期/復帰カクつき/分配経路） — システム作業 — 完了
  6. 【次セッション本題】パフォーマンス改善①〜④ 全部GO — 未着手 — 大串「同期の速さ・重さを絶対になくしたい・全部やりたい」

テーマ別の詳細

1. リスト依頼まわり（scale-lead）

  • v11.6.15: 中業界のグローバル残留で過去業種が通知に混入する問題を根治（描画/送信後リセット+送信時ガード+親子チェック連動）
  • v11.6.25〜27: Slack通知FMTを案A（作業指示書型）で刷新→3回のFBで確定。最終形=📋ヘッダ/依頼件数/【大業界】→中業界1行ずつ/「すべて対象」/▼仮説。FMT4原則を学びストックに記録済み（説明語より構造・絵文字最小・未指定行非表示・用語はメンバー行動基準）

2. リストプール（scale-lead）

  • v11.6.16: 0件表示根治（56MB一括GET限界→チャンク個別ロード）→ v11.6.17: スプレッドシート型に全面刷新（D1テーブル list_pool_rows・サーバー側ページング/検索/フィルタ/ソート・取込は行単位INSERT=上書き消失が構造的に不可能・分配済みマーキング assigned_json）
  • 過去データ全量復旧: 7/8〜11の消失事故をD1 Time Travelブックマーク往復（露出約50秒×3回・全カウント一致検証）+破損blobサルベージで復旧 → 最終 118,072件（5月18,715/6月50,766/7月48,591・全件ユニーク）。恒久バックアップ3本= ~/scale-lead-backups/list_pool_dump_*.json.gz
  • v11.6.19: 分配モーダルのセグメントをD1から全案件分直接取得（山本さん当日依頼が出ない問題根治）
  • v11.6.20: バッチ一覧の日付を batch_at（取込操作時刻）基準に+facets 60秒TTL
  • v11.6.22〜24: 全7フィルタをチェックボックス式複数選択に統一（汎用_lpMsHtml・地域は「関東 一括」等の地方ブロック・中業界は大業界グループ表示+選択業界連動）
  • 未判断の残課題: 旧blob+残骸チャンク約56MBのD1掃除（復旧完了+バックアップ3本ありでいつでも安全に消せる）

3. 架電リスト改善（scale-lead）

  • v11.6.18: 地域（都道府県）フィルタ新設（クライアント_clRowPassesとサーバーquery.tsの1:1同期箇所に注意）
  • v11.6.21: フィルタ行1行化（検索枠170px・この画面のみインライン指定）

4. 単価改定（2026-07-27 大串意思決定）

  • 新パートナー報酬（税抜）: 20,000/23,000/26,000/30,000/33,000＋消費税10%上乗せ（旧税込21,000〜37,000）
  • v11.6.28: CRMの5択/ランク表/時給換算/既存案件D1移行（6案件・カスタム15,000は不変・バックアップあり）。時給換算は消費税込の受取総額ベース＝旧表比で同等以上（大串指示「見え方悪くならないように」）
  • Partner Program公開サイト全7頁更新（直接prod=2026-07-13FBで自社サイト扱い確定済み）。biz/ownerマニュアルは別セッションが改定済みを本番確認
  • E以降（契約書巻き直し・適用開始日・免税事業者・募集文面・アナウンス）はやらない確定（大串 7/27）

5. メンバー苦情の根治

  • v11.6.29: 【重要】30秒ポーリングが起動専用showApp()を呼び、lastPage_（共有）でcurrentPage上書き→「勝手に最上部へ戻る」「2タブがページ同期される」の真因。ポーリングからのshowApp全廃+_appBootedフラグ二重ガード。トラブルシューティング集A20
  • v11.6.30: タブ復帰時の同期を重複排除で1本化+250ms/2.5s段階実行（カクつき軽減）
  • v11.6.31: 案件分配をblob全量上書き→/api/calls/bulk行単位upsertへ（完了保証・リトライ・分配先サーバー正本での重複判定=未読込案件の重複穴も封鎖）。次回分配の初回だけ実地確認推奨

6. 【次セッション本題】パフォーマンス改善①〜④（全部GO済み・未着手）

大串「とにかく同期の速さとかなんか重いっていうのを絶対になくしたい」「全部やりたい」

実測済みの現状値（7/27実測）:
- 他メンバーの編集が画面に出るまで: 平均約5秒・最悪約9秒（送信0.3〜0.7s＋8秒ポーリング＋D1応答0.55〜0.79s）
- /api/health: 0.1〜0.3s ／ /api/changes: 0.55〜0.79s
- 同一ブラウザ別タブはBCで即時。ポーリング定義: D1_POLL_INTERVAL_FAST=8000（core.js 2326付近）・per-row行ポーリングも8s系・full reconcile 120s

やること（推奨順）:
- ① 架電リスト表示中＋タブ前面のときだけポーリング8s→4s（同期遅延を平均2.5sへ半減・即日・低リスク）
- ② 「重い」実測ビーコン: 既存の window._perfStats（PerformanceObserver longtask・[PERF-LT]）を集計送信（error_log等へ）→誰の・どのPCで・どの操作が重いかをデータ特定→1週間貯めてワーストから潰す
- ③ 初回ロードのJS分割読み込み（非クリティカル: kickoff/ai/list_pool等を初回描画後に。読み込み順の依存に注意・中リスク）
- ④ 【本命】リアルタイムPush化（WebSocket/Cloudflare Durable Objects）: 同期遅延5秒→0〜1秒。段階導入=架電リストだけ先行・8秒ポーリングは安全網として並走（失敗しても現状に戻るだけ）。SCALE FORMへ横展開できる基盤
- 進め方: ①+②を即日→②のデータを見つつ④を設計・実装→③は合間に

このセッション全体の大串FB（重要）

  • 「スプレッドシートみたいに何件入れても重くならない仕様に」→ per-row化の設計思想として今後も適用
  • Slack通知FMT4原則（学びストック記録済み）: 説明語より構造/絵文字最小(目印1個可)/未指定行非表示/用語はメンバーの行動基準。改案は実データモック3案→大串が選ぶ→微調整2回で確定が速い
  • 「見え方悪くならないように」→ 数値の見せ方変更時は旧値と比較して下がる箇所を作らない/正直に注記
  • 提案の出し方: 棚卸し→番号付き提案→大串が選ぶ、が今週ずっと機能した型

注意点（新セッション向け）

  • scale-lead編集時: lib/.jsとmin両方はdeploy.shが自動。本番検証はエッジ伝播ラグあり*（ランダムクエリ付きcurlでリトライ・数十秒〜数分）
  • 架電リストのフィルタ述語はクライアント（lib/calllist_core.js _clRowPasses）とサーバー（functions/api/calls/query.ts rowPasses）の1:1同期必須（2重メンテ箇所）
  • 認証層（functions/_middleware.ts + auth.ts）は地雷。v11.6.17でper-row API列挙に1行追加した前例あり（列挙追加のみ可・ロジック変更は大串承認）
  • D1直接調査は npx wrangler d1 execute scale-lead-prod --remote --json が最速最強（A19の学び）
  • 「消えた?」系は画面でなくD1正本を見る／件数照合は1件のズレも追跡（Time Travel復旧でID衝突1件を検出した実績）

16:45 - テーマ6完了: パフォーマンス改善①〜④ 全部一気に実装・本番LIVE（v11.6.32）

大串「全部一気に実装していいよ」→ ①〜④を1リリースで実装・デプロイ・検証完了。

実装内容（正本=git 3bb76c4 + COCREATE_VERSIONS v11.6.32）

  • ④リアルタイムPush（本命）: 別Worker scale-lead-push（Durable Object PushHub・WebSocket Hibernation API・new_sqlite_classes）新設。Pages側 functions/api/push.ts がWS upgradeをDOへ転送（認証=既存セッションcookie・middleware変更ゼロ）。クライアントはfetch 1点フックで自分の書き込み(非GET 2xx)成功→ping送信→ハブが他の全接続へrelay→受信側は既存 _d1PollTick を即実行。同期 平均約5秒→0〜1秒。合図だけ運びデータ本体は従来の検証済み経路（Defense層全通過）。8秒ポーリングは安全網で並走=Pushが死んでも現状と同じ。
  • ①前面4秒ポーリング: FASTページ(架電リスト/オンライン状況)+タブ前面のみ8→4秒（D1_POLL_INTERVAL_FAST_VISIBLE）。Push が効かない環境の保険も半減。
  • ③初回JS分割: kickoff/list_pool/ai の min 3本(約206KB)を index.html から外し _lazyLoadAllMods が初回描画後に遅延ロード。renderPage のRマップをtypeofガード化+未ロードページはロード完了待ち再描画（dashboardに化けない）。
  • ②実測ビーコン: longtask のページ別内訳を60秒毎+pagehide時に /api/perf→D1 perf_log へ。1週間貯めてワースト画面/環境から潰す。集計SQL例=migrations/schema_v11632_perf_log.sql 冒頭。

検証済み（本番実機）

  • 本番 crm.scale-group.co.jp 200・service.min.js 実バイトで v11.6.32 確認・core.min.js に4機能マーカー全部あり
  • /api/push stats疎通（Pages→DOバインディングOK）・WebSocket E2E中継テスト成功（2接続でA送信→B受信・送信元へは返さない）
  • /api/perf テストPOST→D1 INSERT成功→テスト行削除済み・perf_log テーブル+index作成済み

学び（技術）

  • Cloudflare PagesはDO自前定義不可→別Workerに PushHub を置き wrangler.toml <span class="wikilink-dead">durable_objects.bindings</span> の script_name 参照で解決（Worker先デプロイが必須順序）
  • デプロイ直後の新設APIパスは、エッジ伝播ラグ中に旧デプロイのSPAフォールバック（古いindex.html）が返ることがある→ランダムクエリ付きリトライで再判定（既知の実バイト検証ルールの新パターン）
  • renderPage のRマップは直参照だと未ロード関数で ReferenceError→遅延ロード化とtypeofガード化は必ずセット

残タスク（次セッション）

  • ②のデータが1週間貯まったら perf_log ワースト集計→重い画面から潰す
  • ④の実地確認: メンバー2人が同時利用時の体感（0〜1秒同期）を大串/メンバーに確認依頼するのは任意
  • Worker scale-lead-push の更新は Pages と別デプロイ（cd workers/push && npx wrangler deploy）である点に注意

16:45 - リストプール旧blob残骸のD1掃除 完了（大串「掃除して」）

  • 削除前バックアップ: 117キー/56.0MB を10キーずつ12バッチでダンプ（56MB一括SELECTはD1レスポンス上限 code 7429 で不可=学び）→ ~/scale-lead-backups/list_pool_old_blob_dump_2026-07-27_1636.json.gz（9.5MB）
  • DELETE: app_data の list_pool_companies% 117行削除 → DB 1.42GB→1.25GB
  • 検証: 残骸0件 / 正本 list_pool_rows は118,160件（復旧時118,072件+その後の取込88件の自然増・DELETEはapp_dataのみで正本に無関係）
  • D1 Time Travel 30日も追加の保険として有効

16:50 - SCALE CRM v11.6.33: 架電対象から「アポ獲得」除外（大串指示・本番LIVE）

  • TARGET_ST から「アポ獲得」を削除（決着済み扱い）。クライアント lib/calllist_core.js とサーバー functions/api/calls/query.ts を1:1同期で変更+「?」条件詳細モーダルの表記更新
  • 「メール日程調整」は残留。CALL_ST/ST_B/CONNECTED_ST（ステータス選択肢・バッジ色・通電判定）のアポ獲得は無関係なので不変
  • 本番実バイト検証済み（v11.6.33・新TARGET_ST確認）・git 3699735
  • 「今日架電した行はステータスにかかわらず架電対象に残す」(v9.66)仕様が認識と違うかも、とのFB → 選択肢提示→大串「廃止する」を選択

16:58 - SCALE CRM v11.6.34: 今日架電の救済(v9.66)廃止（大串意思決定・本番LIVE）

  • 架電対象は「進行可能ステータスかどうか」だけで判定に統一。今日架電した行でも決着系(アポ獲得/失注/NG系等)は表示しない
  • 保存直後の行消失→画面ワープは直近30分編集ガード(v11.5.29)が引き続き防ぐ／当日の振り返りは「本日の架電履歴」プリセットが担当（役割分担明確化）
  • クライアント/サーバー1:1変更+「?」条件詳細モーダル更新・本番実バイト検証済み(v11.6.34・calledToday撤去確認)・git c77680b
  • 架電対象の仕様FB 2連続の学び: 架電対象プリセットは「例外・救済」を足すほど認識とズレる。シンプルな許可リスト判定＋消失防止は直近編集ガード＋振り返りは専用フィルタ、の役割分担が正

17:05 - SCALE CRM v11.6.35: 未使用機能の整理3点（大串指示・本番LIVE・git d069f52）

  1. 発信ログ管理を機能削除: 保存データは277KBと軽微だったが、発信クリックのたび最大100KB blobを全員に同期配信する構造コスト（Push化で即時配信になり悪化方向）。記録write廃止(calllist_misc 2箇所)・nav/Rマップ撤去。番号クリックのコピー機能は維持。D1の call_intents 5キーはバックアップ(call_intents_dump_*.json.gz)後削除。表示コード(renderIntentLog)は残置(到達不能・復元容易)
  2. 使い方ガイド・業界知識ガイドをアーカイブ: navの2行をコメントアウトのみ（コード・データ完全残置＝コメント解除だけで復元）
  3. 解約案件が横断画面に出る問題の根治: 真因=非表示になるのはstatus='archived'だけなのに、案件編集のステータスが稼働中/一時停止/完了の3択でアーカイブ導線が設定ページの奥(admin向けボタン群)にしか無かった。案件編集モーダルに「📦この案件をアーカイブ」ボタン+説明を追加(admin限定・既存archiveProject再利用=confirm/監査ログ/復元一覧付き)。大串は解約案件を案件編集からアーカイブすれば全画面から消える
    - 学び: 「使ってない機能の重さ」はストレージでなく書き込み頻度×blobサイズ×同期人数で評価する（発信ログ=277KBでも毎クリック100KB全員配信が真のコスト）

17:35 - SCALE CRM v11.6.36: 架電リスト「同期中...」長時間表示を根治（大串FB・本番LIVE・git bdfbd50）

  • 症状: 架電リストを開いた時・案件切替時に「架電リストを同期中...」全画面スピナーが長く出る（スクショ提供あり）
  • 真因: 前回データ即時表示用スナップ(v11.5.86 sb_clsnap_<pid>)が「最後に開いた1案件のみ」保持で、_clSaveSnapshot が保存のたび他案件のスナップを全削除していた（calllist_core.js:601）。案件を切り替えるたび前回データ無し→D1全量ロード完了(大型案件は数秒)までスピナー
  • 根治: スナップ保持を直近3案件LRU（sb_clsnap_lruで管理・LRU外は掃除）に変更。行き来する案件は前回データ即時表示+裏で最新化（既存機構がそのまま効く）。スピナーは「直近3案件外を久しぶりに開く初回」だけに
  • 容量安全: slim保存+_safeSetItemのQuotaExceeded自動掃除(snap系が第1掃除対象)の範囲内。D1正本は不変
  • 初回ロード自体は v11.6.5 の4並列チャンクDLが既に効いている（今回は表示体験の根治）

18:55 - SCALE CRM v11.6.37: 性能改善第2弾①④②（大串GO「推奨の流れで」・本番LIVE・git 540cef8）

性能アイデア7案を提示→大串が推奨順（①④②）でGO。
- ① Push健康時ポーリング自動緩和: WS健康時は安全網ポーリング4s→15s（同期はPush 0〜1秒が担う=体感不変・D1負荷/通信/電池減）。HB 30秒毎（DO側 setWebSocketAutoResponse でhb→hb-ack=DOを起こさずコストゼロ）＋95秒無受信で「静かに死んだWS」を検知→close→再接続→ポーリング即4s復帰。HB E2E検証済み（hb送信→hb-ack受信）
- ④ 実測監査の成果2つ:
1. 旧call_list blob書き込みがまだ生きていた（当日15:55に3.3MBのchunk書き込みを実測・updated_by=sync-chunk-N）。PS()はガード済みだがフラグ未ロード瞬間のフォールバック等でS()直行があり得る→S()に最終防衛ガード（per-row時のcall_list blob書き込みをdiffPush行単位に自動変換）。書き込み増幅・/changesノイズ・D1肥大の三重コスト根絶
2. cocreate_sessions（0.83MB・AI共創はv11.6.4削除済み・現行コード読者ゼロ）をboot除外 → bootペイロード 811キー/2.30MB（D1シミュレーションで検証）
- ② service.min.js(795KB)遅延化: 中身はほぼCOCREATE_VERSIONS（バージョン履歴テキスト）・実装本体はlib_bundle側と判明→安全に遅延化。バージョンバッジはロード完了時に自動更新。初回JSはv11.6.32比で計約1MB減
- おまけ根治: 新版検知が /service.js（v10.17のソース404化以降ずっと取得不能）を見ていて新版通知が死んでいた既存バグを発見→/service.min.js参照に修正して復活
- 未着手（大串判断待ちの将来候補）: ③担当案件の先読み／⑤架電リスト仮想スクロール（perf_logデータ確認後）／⑦保存の楽観更新総点検
- 残提案: 旧call_list blobチャンク47キー/約22MB（今回書き込み経路を遮断したので今後は増えない・stale遺物）のD1掃除はlist_pool同様「掃除して」の指示があればいつでも実施可能

2026-07-31 日報同一文言の調査 + 新ロゴ v11.6.38

19:00 - 「2人の日報の課題/解決策が同一」調査（大串「システムおかしいかも」）

  • 結論: 文言一致はシステム起因ではない（文言はコード内に不存在・D1全文検索で前野の1件のみ・日報プリフィルは自分の日付__メンバー行限定＝混線経路なし）→ 前野が山本の朝のSlack投稿を流用した可能性が高い（運用の話）
  • 副産物で本物のバグ3つ発見（未修正・大串のGO待ち）: autoCalcDailySilent(lib/pagecore_daily.js) が①dateのみ照合でmember無視（複数人同日で他人のレコードを合算値+連結名で上書き→_dtKey変化で行消失リスク）②workHoursをObject.assign順序バグで毎回0に破壊（山本0.39h→0を実データ確認）③日報reportが保存直後に古い値へ巻き戻る競合の実例あり（山本09:38の課題文言がD1から消失・daily_teleapoに巻き戻り防御なし）。修正案=自動集計はdate+member照合・数値のみ更新・workHours/report/note不可侵

19:20 - SCALE CRM v11.6.38: サイドバー新ロゴ（本番LIVE・git 0e6fac3）

  • 左上を旧アイコン+SCALE CRM+案件管理テキスト→新・鳥マーク横ロゴ1枚に刷新。元画像=~/Downloads/SCALEロゴ_横縦セット/02_SCALE_CRM_文字横.png→輝度→アルファ変換で背景透過(白ロゴ)+bboxトリム→icons/scale-crm-logo-w.png(1063×279・75KB)。高さ38px=旧行高と同一でスペース不変。ログイン画面/モバイルヘッダー/faviconは対象外
  • 学び: 本番の /index.html 直パスは308リダイレクトになった（実バイト検証は / を見る・旧手順のgrepが0件になる罠）

19:30 - v11.6.39: ロゴをブロック内で縦横中央配置（大串FB・本番LIVE・git 03b4608）上下パディング18px対称化(総高さ不変)+justify-content:center

2026-08-02 リストプールUX改善 v11.6.40（大串FB・本番LIVE）

中業界4選択で0件の調査 → システム正常

  • 中業界フィルタはIN句=OR（4つ全部出る・大串のイメージ通りの実装）。0件の真因=右端のバッチ絞り込み(結グループ_エアコン_山本_07-29等)がONのままAND併用→そのバッチに飲食系0件。プール全体では4中業界2,630件該当をD1実測で確認
  • 提案済み(未実装): 0件時に「どのフィルタで絞られているか」ガイド表示

v11.6.40: リストプールUX2点（git反映済み）

  1. バッチ絞り込みポップオーバー刷新: 長文2列尻切れ→案件ごとグループ表示(一括ボタン付き)・行=「取込者 MM/DD HH:MM・件数」短縮表示・新しい順。_lpMsHtml に blockItemMin 追加
  2. CSV取込バッジを「案件→セグメント」連動式に: 案件選択でその案件の segment_definitions がプルダウンに出る(キャッシュ即表示+/api/segment-def裏更新=v11.6.19分配モーダルと同型)。バッジ規則=案件名_セグメント名_日付。直接入力fallback残置。旧「リスト依頼者」入力は廃止(残参照ゼロをgrep確認)
    - 既存バッチラベル(案件_依頼者_日付)も新グループ表示の解析regexで正しく表示（後方互換）

v11.6.41: セグメント一覧の名前順ソート（大串FB「天野②がない」・本番LIVE）

  • 調査: 天野②はD1正本(segment_def_rows 21件)にもプルダウンにも実在（リスト依頼Slack投稿と同時刻の自動作成も正常）。真因=作成時刻順ソートで山本①〜⑮の連番の間に埋もれて実質探せない
  • 根治: _lpSortSegDefs(名前本体でグループ化+丸数字①〜⑳を番号順)を新設し、CSV取込セグメント選択+分配モーダルの両方に適用（横展開）
  • 学び: 「無い」系FBはデータ確認が先（実在なら並び順/表示の問題を疑う）

v11.6.42: 分配モーダルのセグメントを案件・担当者連動絞り込みに（大串FB・本番LIVE・git反映済み）

  • 既定=分配先案件のセグメントのみ+担当者選択でその人の名前対応(丸数字除去した本体との双方向部分一致)を優先表示。案件/担当者の選び直しで即追従(onchange連鎖)
  • 合致ゼロ→案件全件に自動フォールバック／「全セグメントを表示」チェックで旧v10.62の全案件表示を温存（過去FBの使い回しケースと衝突させない設計）

v11.6.43: 分配実行の「無反応」根治+119,016件分配インシデント（大串FB・本番LIVE・git 6932f63）

  • インシデント: 「分配実行を押しても先に進まない」の実体=抽出件数空欄でフィルタ後全件(119,016件)が対象になり、確認ダイアログなし・進捗表示なし・二重実行ガードなしで裏で数分の分配処理が実走。41,488件が結グループ_エアコン(担当:天野)のcall_rowsに追加された(updated_by=大串/lp-distribute 26,438+大串 15,050・12:48 JSTに停止確認)
  • 修正: ①実行前confirm(件数明示・1万件超は誤爆警告) ②ボタン進捗表示(対象取得/データ取得X/Y/照合/書き込みX/Y) ③二重実行ガード
  • 巻き戻し: 対象は importBatchId/imported_from=ListPool分配 メタで正確に特定可能。今日の分配行41,488件(全行が架電履歴なし)→大串の判断待ち
  • 学び: 「無反応」FBは (a)本当に止まっている (b)裏で走っているが見えない、の両方を疑う。D1のupdated_byタグ+件数差分で実走を確認できた

分配インシデント巻き戻し完了（大串「巻き戻す」選択・実行済み）

  • 内訳判明: 今日の41,488件=天野②への大型分配3バッチ41,189件(23,993+16,996+200・二重実行ガード無しで複数回実行)+金森①への299件(通常サイズ・assignマーキングまで完走=意図的分配とみなし残置)
  • 実行: 天野②3バッチをバックアップ(dist_rollback_amano2_2026-08-02_1327.json.gz・6.9MB・41,189件)→importBatchId厳密指定+架電履歴なし条件でDELETE 41,189行
  • 検証: 天野②残骸0件・金森①299件残置・案件全体4,481件(今朝4,182+金森299=完全一致)・プール側天野②マーキング残骸なし(assignは未実行だった)
  • 学び: 分配行は importBatchId で1分配=1バッチ特定できる設計(v9.226)が巻き戻しの決め手。巨大処理の中断は「書き込み済み分が残る」前提で必ずD1実数を確認

v11.6.44: ファビコンを新・鳥マークに刷新（大串指示・本番LIVE・git反映済み）

  • 横ロゴ(icons/scale-crm-logo-w.png)から鳥マークを自動抽出(空白帯検出はマーク幅=高さ0.7〜1.7倍の帯で判定・初回は閾値20pxでSCALE文字まで含む失敗→修正)→黒背景+白マークで32/64/180px生成
  • faviconリンクに?v=付与(SWの/favicon* cache-first対策・deploy.shが以後自動更新)・本番実バイト一致検証済み

SCALE LIST vs SCALE CRM アーキテクチャ分析（大串依頼・2026-08-02）

  • LIST(~/dev/scale-list・503万件で軽快)の速さの構造: ①常に50件だけ表示(サーバーLIMIT/OFFSET+用途特化インデックス7本) ②クライアントJS計71KB・状態レス(localStorage写し/同期/キャッシュ層なし・D1唯一の真実) ③列絞りSELECT ④書き込み経路1本
  • CRM perf_log 1週間実測(10人/108ビーコン): call_list longtask643回/最悪24秒・script 534回(ほぼ山本)・list_pool 354回/24秒・list_request 最悪70秒(金森)。ワースト=山本1,084回
  • CRMの構造課題: 全量クライアント主義(案件全行をブラウザに持ち全走査)+事故対応の防御層積層+JS 1.9MB(LISTの27倍)+描画/同期/防御が同居(calllist_core 1890行)。仮想スクロール(v11.5.99)とサーバー駆動モード(v11.6 Phase4・既定OFF)は実装済みだがデータ層が全量のため効果限定
  • 提案(GO待ち): ①架電リストのサーバー駆動本格移行(本命) ②script画面調査 ③list_request 70秒フリーズ調査 ④新規開発はLIST方式を標準化

v11.6.45: SCALE LIST方式へ本格移行①（大串「全部実装よろしく」・本番LIVE）

  • perf_log再集計(page_stats正確版): call_list 1,123回(山本1,056)・script実は31回のみ(前回集計はworst_ms列=セッション累計での誤帰属・page_stats JSONが正)。最大案件mnpg=17,321行/15.6MBが主犯
  • 実装: 8,000行超の案件は自動サーバー駆動(digest判定→localStorage sb_cl_srv_ キャッシュ)。全量ロード/clPollPerRow(full reconcile)停止→表示200行のみ・Push/tickで表示ウィンドウ軽量更新(9s集約)・編集/保存/日報集計は_clServerBridgeRows(_cache upsert+prevSnap同時更新=誤削除ゼロ)+today行プリフェッチで互換
  • キルスイッチ: localStorage sb_cl_server_off='1' or window._CL_SERVER_FORCE_OFF
  • 本番実測: 17k案件のサーバークエリ=0.94s/340KB/200行(従来15.6MB比 1/46)・digest count=15,830でON判定確認
  • ③list_request 70秒(金森)は単発・明白なホットスポットなし→正直に監視継続(ビーコンで再発を追う)
  • ④設計原則「SCALE LIST方式」を _SCALE_全システム実装ルール+scale-lead CLAUDE.md に明文化(commit+push済み)

Phase5(完全SalesNow化)開始（大串GO「時間かかっても凄い良いものを・進めて」・2026-08-02）

  • 要件確定: 常時サーバー駆動+操作感0ms(楽観更新徹底=自分の画面は即時・他人への反映遅延は許容)+複数人同時操作
  • 設計書: scale-lead/docs/PHASE5_SalesNow化_設計.md（Stage5.1完全SQL化→5.2常時ON→5.3楽観更新総点検+stats API→5.4計測撤去）
  • 発見: query.tsの実態=SQLは1次絞りのみで毎リクエストWorkerが該当全行(17k案件=1.5万行)をJSON.parse→JS述語→JSソート。0.94sの正体。完全SQL化で0.2-0.4s目標
  • Stage5.1土台 完了: call_rows仮想生成列5本追加(c_prefecture/c_script/c_segids/c_recall/c_search)+インデックス5本・D1適用済み(計13列/14index)・c_search機能確認済み(純追加=既存無影響)・git 674b47b
  • 次: query.ts完全SQL化(新旧並走で全案件×主要フィルタのtotal一致を機械照合→切替)

Phase5 Stage5.1完了: サーバークエリ完全SQL化 v11.6.46（本番LIVE）

  • 新旧並走照合: 本番実データ3案件×19ケース=57件で total完全一致(不一致0)を機械確認→既定SQL化
  • 実測: 17k案件 全件84ms/ステータス17ms/地域91ms/検索95ms/ソート345ms(旧0.9s・9〜56倍)。qの数字正規化はseparator除去5種で近似(照合で一致確認)
  • 安全網: 非対応ソート/SQL例外→jsエンジン自動フォールバック・?engine=jsで即切戻し
  • 次=Stage5.2: 常時サーバー駆動化(閾値撤廃+先読み+debounce+チラつきゼロ差し替え)→5.3楽観更新総点検+stats API

Phase5 Stage5.2+5.3完了: v11.6.47（本番LIVE・git反映済み）

  • 5.2常時サーバー駆動: 全案件で表示をサーバー駆動に統一(_clServerOn常true・キルスイッチ維持)。中小案件は全量ロードを裏並走(レポート/分析/日次集計の完全互換=退化ゼロ)・大案件のみ全量スキップ(v11.6.45)。スピナー全廃・seq+projectの応答競合ガード追加。clTBは0行でも常在=サーバー描画注入可を確認済み
  • 5.3: 楽観更新監査=保存経路にawait fetchゼロ(ローカル即時→裏push)を確認・/api/calls/stats新設(ステータス別/担当別GROUP BY・実測115-136ms)
  • 残: Stage5.4=perf_log数日蓄積→before/after比較→旧経路(全量ロード/full reconcile)の段階撤去・statsのUI接続

残タスク1〜5一括実装完了: v11.6.48（大串GO・本番LIVE・git反映済み）

  1. 日報autoCalcバグ3件根治: 日付×担当者単位に全面修正(_dtAggregateByDatePerson/_dtApplyAgg)・workHours/report/note不可侵・数値no-op skip・直近3日窓限定・旧連結名合算行(・入り+note=自動集計)の移行掃除・大案件(サーバー駆動)は誤集計書き込みガード
  2. 週次perfレポート自動化: scripts/perf_weekly_report.py+launchd com.scale.crm-perf-weekly(月曜8:00)。dry-run成功。送信先=D1 perf_report_config(既定#ai部署)・botTokenは案件slack_configから流用。初回投稿は月曜・チャンネル希望は大串確認事項
  3. リストプール0件ガイド: フィルタ0件時に「条件に一致0件」+フィルタ内訳チップ(バッチ強調)+全解除ボタン
  4. 集計正確性ガード(1に内包)+旧経路撤去はPhase5.4計測後の方針を維持(statsのUI接続も同時)
  5. 旧call_list blob掃除: 53キー/22.4MB+shadow残骸1キー(327KB)=計54キーをバックアップ(call_list_old_blob_dump/call_list_shadow_dump)後DELETE・残骸0件検証済み