作業ログ 2026-07-02

08:36 - /handoff 実行（全テーマ）

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

1. SCALE CRM Slack通知連携（v11.5.97〜98） — システム作業 — 完了・本番LIVE
2. Vault基準点のDrive競合消失と復元 — 運用事故対応 — 完了（教訓を恒久ルール化）
3. 架電リスト性能の洗い出し＋全面改善（v11.5.99〜v11.6.0 HubSpot体制Phase1-4） — システム作業 — 完了・本番LIVE
4. TERASU電話対応/問い合わせリストのHP列手動入力可（v11.6.1） — システム作業 — 完了
5. GitHub Actions自動デプロイ＋AUTH_SECRET無停止移行＋~/dev移行 — インフラ整備 — 完了（残1件あり）
6. 所属外案件を開けない権限ゲート（v11.6.2） — システム作業 — 完了・本番LIVE
7. 濵田①セグメント移行＋TERASU誤データ削除 — 本番D1データ操作 — 完了（残1件あり）

テーマ別の詳細

1. SCALE CRM Slack通知連携（v11.5.97〜98）

• 電話対応/問い合わせリスト（TERASU）の架電報告をSlack連携（アポ獲得以外を全部 teleapo_loss へ）。
• 二重通知（onchange/onblur二重→親スレ2本）を3層根治＋スレを架電/問い合わせ/電話対応で種別分離。
• 詳細: 作業ログ_2026-06-23 / 2026-06-24。

2. Vault基準点のDrive競合消失と復元

• 基準点が6/17(v11.5.82)まで巻き戻り phase_v83〜96 消失 → 本番デプロイ済み service.js の COCREATE_VERSIONS から全15版復元。
• 恒久教訓: 基準点等の重要Vault更新は編集後すぐ git commit+push（memory: vault-baseline-commit-immediately）。コード内changelogがVault消失時の最後の砦。

3. 架電リスト性能改善（v11.5.99〜v11.6.0）

• 洗い出し: 最大案件6,134行×20列=約12万DOM要素の全行DOM化が「重くて開けない」主因（Vault: _SCALE_CRM_リスト性能_根本原因とHubSpot対比）。
• ①仮想スクロール（可視範囲のみDOM・O(1)描画）本番LIVE。緊急時 window._clVirtualOn=false でフォールバック。
• HubSpot体制Phase1-4（Vault: _SCALE_CRM_HubSpot体制移行_実装計画）: D1 generated column+index / c_latest_status索引 / サーバークエリAPI(/api/calls/query) / クライアントサーバー駆動。Phase4は window._clServerMode 既定OFF（現規模6千行は①が最速・数十万行でON）。
• 注意: フィルタ述語は query.ts と _clRowPasses の2重メンテ。

4. HP列手動入力可（v11.6.1）

• TERASU電話対応/問い合わせリスト限定で website を手動入力可（一覧「＋HP入力」/「✎」・詳細モーダル）。通常架電リストはSalesNow自動入力のまま編集不可＝退化なし。

5. GitHub Actions自動デプロイ＋AUTH_SECRET移行＋~/dev移行

• 正本 = ~/dev/scale-lead（Drive外・2026-06-29移行）。旧 ~/株式会社SCALE/scale-lead は凍結。
• git push origin main で自動デプロイ（node22必須・repo secret ●●●●●●/ACCOUNT_ID）。手動 bash deploy.sh（退化チェック付き）併用可＝重要変更はこちら推奨。
• AUTH_SECRET を wrangler.toml 平文 → CF Pages Secret へ無停止移行（全員ログイン維持・実証済み）。ローカルは .dev.vars（git除外）。
• ~~残: GitHub履歴の旧コミットに旧AUTH_SECRETが残る。完全消去は鍵ローテ＝全員一度再ログイン → 大串判断待ち・やるなら業務時間外。~~ → 大串判断（2026-07-02）: ローテはやらない（クローズ）。現行運用（CF Pages Secret化・無停止移行済み）のままでOK。

6. 所属外案件を開けない権限ゲート（v11.6.2）

• 結グループのみ所属の濵田さんがTERASU案件のリスト依頼を作成できた件。真因＝案件選択UI（getVisibleProjects=見せない）だけで、switchProject に権限ゲート（させない）が無かった。
• 3層ゲート: ①switchProject権限チェック ②submitListRequest検証 ③_ensureProjectAccess+renderPage毎に自動修正。admin/PM不変。
• 設計教訓: 「表示の制限」と「権限のゲート」は別物。権限は実行点でゲートする。

7. 濵田①セグメント移行＋TERASU誤データ削除（本番D1操作）

• 結グループに濵田①追加（per-row segment_def_rows + blob proj_X_segment_definitions の両方に同一idで整合追加）。TERASUから誤セグメント＋誤リスト依頼を削除（デモ①は保持）。backup=~/scale-lead-backups/segdef/。
• 恒久教訓: セグメント定義・リスト依頼は per-row＋blob の二系統。必ず両方を整合操作。
• ~~残: Slackの誤投稿メッセージ（terasu_テレアポ支援_リスト依頼チャンネルの6/30「リスト作成依頼」）はSlack上に残存。消すかは大串判断待ち。~~ → 大串判断（2026-07-02）: 削除しない・そのまま残置でクローズ。

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

• 「やれることは全部やって100点にしたい」「HubSpotやSalesforceと同じ体制で」→ 長期スケール志向。
• AUTH_SECRET漏洩対処は「無停止で移行だけ」（ローテは見送り）。
• 「そのメンバーが所属の案件しか開けないようにすればいい」→ 権限ゲート3層で実装済み。
• デプロイ検証は本番実バイトで（wrangler成功表示を信じない）。

次セッションの候補（大串が決める）

• メンバー実機確認: 仮想スクロール（重い案件）/ 権限ゲート（所属外弾き）/ HP列入力。
• ~~大串判断待ち2件: AUTH_SECRETローテ（業務時間外）/ Slack誤投稿メッセージ削除。~~ → 2026-07-02 大串判断: 両方とも「やらない」で確定・クローズ（残タスクではない）。