作業ログ 2026-06-24

09:30〜09:56 - SCALE CRM v11.5.98 架電報告の二重通知を根治 + スレをリスト種別で分離（本番LIVE）

対象

SCALE CRM（scale-lead / crm.scale-group.co.jp / 正本 ~/株式会社SCALE/scale-lead/）。本番 v=202606240952 / アプリ v11.5.98。

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

1. TERASUの電話対応リストから架電するとSlack通知が2つ飛ぶ（同じ内容の「架電報告」スレが2本立つ）
2. スレタイトルに「架電リスト/問い合わせリスト/電話対応リスト」のどれの架電報告か出したい（3つ別スレにしたい・今は両方電話対応リストなのに同じ内容で2スレ）
3. 作業報告の通知が飛ばない

調査（本番D1の物証で真因確定）

• 一覧のステータスselectは onchange="clInlineSave(this)" onblur="clInlineSave(this)"（calllist_core.js:1533）＝onchange/onblur両方でclInlineSaveを呼ぶ。モーダル不要ステータス（コールのみ/担当不在/連絡不可）を選ぶと、選択(onchange)→フォーカスアウト(onblur)で _checkSlackOnStatusChange が2回発火。
• スレ親作成 _slackGetOrCreateCallReportThread のkeyは proj_<id>_call_report_thread_<member>_<date> で listTypeを含まない＝3リストが同じスレに集約。
• 本番D1物証：call_report_thread_二宮_2026-06-24 は1件キャッシュなのにSlackには2スレ＝D(key)=null を二重に踏んだ親作成レース。
• 作業報告（teleapo_work）は調査で全て正常：チャンネルC0BAL1UMKT2設定済・botToken有・notifications.daily_report=true。本番D1の daily_thread は二宮_2026-06-11が最後＝6/11以降 稼働タイマー（稼働開始/終了）が押されていないため飛んでいないだけ（架電報告はタイマー無関係に飛ぶ）。設定でなく運用。

修正（v11.5.98・3層根治＋スレ分離）

• ①二重通知 3層根治（pagecore_slack.js / calllist_core.js）
• (A) clInlineSave の通知に newVal!==oldVal 必須化＝値が実変化した時だけ発火（onblur二重を断つ）
• (B) _slackGetOrCreateCallReportThread に in-flight Promiseガード（window._slackCallThreadInflight）＝同一keyの親作成が進行中なら待って同じスレ共有（レースを構造封じ）
• (C) _checkSlackOnStatusChange に同一 [projectId|callId|field|val] 8秒デデュープ（window._slackStChgDedup）＝全保存経路(clInlineSave/saveCallStatusModal/saveCallField)＋アポ獲得通知の二重も同時防止
• ②スレ種別分離：listType(call/inquiry/phone)をkeyとタイトルに追加。架電リスト=旧key互換（無印=既存スレ継続）、問い合わせ・電話対応=種別付きkey=別スレ。タイトル「MM/DD 架電報告（担当）／電話対応リスト」+子投稿ヘッダーにも種別。_clListTypeLabel/_clListTypeOf 新設。
• ③作業報告：コード変更なし（設定正常・タイマー未使用が真因）。大串に稼働タイマー運用を案内。

編集ファイル

• lib/calllist_core.js（clInlineSave 通知に newVal!==oldVal）
• lib/pagecore_slack.js（_checkSlackOnStatusChange デデュープ / _clListTypeLabel・_clListTypeOf 新設 / _slackPostCallReportToThread listType解決+子ヘッダー種別 / _slackGetOrCreateCallReportThread listType引数+key+title+in-flightレース防止）
• service.js（COCREATE_VERSIONS に v11.5.98 追記）

デプロイ・検証

• bash deploy.sh（直接prod・社内ツール）。全59関数OK・minify（lib_bundle.min.js 38 files）・pre/postバックアップ・本番200・D1正常。
• backup: scale-lead-2026-06-24-0952-pre-deploy.tar.gz / -0956-post-deploy.tar.gz
• 本番実体検証（lib_bundle.min.js を python実測）：_clListTypeLabel×4 / _clListTypeOf×2 / _slackCallThreadInflight×6 / _slackStChgDedup×5 / 電話対応リスト×2 / 問い合わせリスト×2 反映確認。service.min.js に v11.5.98。

注意・退化リスク

• service.js changelog は template literal内＝バッククォート禁止（今回も不使用でnode --check OK）
• 架電リスト（アウトバウンド）はスレッドkey無印継続＝既存スレに集約・通知対象・文面とも無変更（退化なし）
• 既存の問い合わせ/電話対応スレは今後新keyで別スレ化（過去分の旧無印スレは残るが、今日以降は種別別スレに分離される）

次（大串の実機確認＋運用）

• 電話対応リストで「コールのみ」等を変更→架電報告が1本だけ飛び、タイトルに「電話対応リスト」が出るか
• 問い合わせリスト・架電リストでも別スレに分かれるか
• 作業報告を出したい場合は稼働タイマー（稼働開始→稼働終了）を押す運用（押せば teleapo_work に日報が飛ぶ）

D1調査の認証メモ（再利用）

本番D1読み取りは ~/.cf_token（Pages用）はD1権限なし(7403)→ unset CLOUDFLARE_API_TOKEN でwrangler OAuthに切替えると読める。npx wrangler d1 execute scale-lead-prod --remote --json --command "..."。

10:12 - WEB制作マニュアル新設＋StockSun4資料を取り込み

• 大串依頼: FSが「説明」止まりでなくWeb知見で「提案」できるよう、FS商談マニュアルとは別に「WEB制作マニュアル」を新設。StockSunのWP4本の内容を反映。
• 新サイト: https://terasu-web-manual.pages.dev/ （正本 ~/dev/terasu-web-manual・gen.py方式・FS manualと同デザイン）。Cloudflare Pages project=terasu-web-manual 新規作成。社内向け直接prod。
• 構成15ページ: はじめに(目的=説明→提案) / Web基礎(良いHP・目的別・構成導線・デザイン・コピー・CV導線・フォーム改善EFO・SEO) / AI時代に勝つ(AI時代のサイト設計・LLMO) / 提案スキル(現状HP診断・課題→提案フレーム・業種別・NG提案)
• StockSun取り込み: ①AI時代に勝てるサイト設計→aisite(3階層/成果出ない5大要因/新要件5/制作プロセス) ②LLMO入門→llmo(AI純粋想起・3要素[頻度/一貫性/ソース質]・GEO・クエリファンアウト・3メディア・SEOがAI最適化の8割) ③問合せフォームCVR改善→form(CV2倍掛け算・フットインザドア/サンクコスト・ハードルを下げる20施策・外部流入排除でCVR1.6倍・カイ二乗検定) ④Webサイト制作ガイドライン→戦略設計の要点を各所に（戦略レイヤー欠落が8割等）
• FS商談マニュアル側: サイドバー「公式サイト」にWEB制作マニュアル↗ 追加（全14ページ）＋「商談の心構え」冒頭に案内バナー。deploy済。
• backup: terasu-web-manual_2026-06-24_1002_stocksun.tar.gz / terasu-fs-manual_2026-06-24_1012_weblink.tar.gz

10:28 - WEB制作マニュアル 大増強（MEO/TD/用語図鑑＋既存4ページ厚く）

• 大串FB「ボリューム超たっぷりで。ネット記事もガンガン。MEO系入れたい(エステ/脱毛サロンでHP×MEO密接)。TD設定ポイント詰めたい。クエリ等の用語図鑑ページ欲しい」
• 新3ページ: ①TD設計(タイトル4ポイント/ディスクリプション/検索意図クエリ4分類Know-Go-Do-Buy/良いTD例) ②MEO(Googleマップ集客=エステ脱毛等店舗系の生命線/順位3要素[関連性距離知名度・2026は口コミ評価大幅上昇]/GBP最適化チェック/NAP統一・HP連携・LocalBusiness構造化/サロン特化/ネット参考リンク3本) ③用語図鑑(34語・集客検索/成果分析/サイト制作/AI時代の4カテゴリ・クエリCV CVR CTA KGI KPI 構造化 NAP canonical等やさしく解説)
• 既存増強: structure(サイトマップ/内部リンク/CTA設計2-3倍/ワイヤー) copy(30本出す/中2に分かる/見出しCVR) design(好みで決めない/コンセプトシート/レギュレーション) seo(検索意図/構造化データ/sitemap robots/URL正規化canonical/E-E-A-T/TD MEO LLMOへ導線)
• ソース: StockSun4資料全読(AI設計/LLMO/フォームCVR/制作ガイドライン全56p) + WebSearch(MEO/GBP 2026最新)
• 計18ページ。backup terasu-web-manual_2026-06-24_1028。https://terasu-web-manual.pages.dev/

17:53 - /handoff 実行

対象システム

TERASU CRM（terasu-mgmt / crm.terasu.scale-group.co.jp）＋ システム開発ルール学習

セッション背景

前セッションで「商談管理をアポ獲得リスト一本から同期(v3.0.319)」を実装したが、紹介の坂口さん(SL SALON)が商談管理に出ない問題が継続。加えてデプロイ未達の幻・Drive巻き戻り事故の再発防止ルールを学習する流れ。

完了タスク（詳細）

• デプロイ検証ルールを恒久化（大串FB「このミスおきないように学習して・システム開発のルールよ」）：実装ルールStep4(デプロイ後)に「デプロイ成功表示を信じず本番実バイトver＋CF API canonical_deploymentで検証」を最優先ルールとして追記。学びストック2026-06-24・ローカルmemory feedback_deploy_verify_canonical も作成。Vault git push済み(7685d5a..25ddcc0)・origin実バイト確認済み。
• デプロイ方法の確定：TERASU CRMは手動wrangler(npx wrangler pages deploy . --project-name=terasu-mgmt --branch=main --commit-dirty=true)。GitHub Actions自動デプロイではない。ローカルはgitリポジトリ(y-ogushi-scale/scale-company)だがDrive上。
• 坂口さん問題の調査（未解決）：本番deals.jsが新版(v3.0.319・getAutoAppointments一本化・console.log含む)であることを実バイト確認(同期ログ文字列=1, getAutoAppointments=3, sourceType:apt=1, 旧linkedin=0, ローカルと同サイズ89366)。コード(rfソース・_dealSyncFromSources・core.js:2128 deals→renderDeals引数なし)も全て正しいと確認。「skipDeals容疑」「_allDeals版」「nav.js」は全て出力破損が生んだ幻だった。

編集ファイル

• Vault: 31_システム開発部/_SCALE_全システム実装ルール.md (Step4) / 22_AI運用ルール/Claude_学びストック.md (2026-06-24) → git push済み
• TERASU CRMコードは今回未編集（前セッションのv3.0.319のまま）

試したこと・学び

• Chrome拡張(claude-in-chrome)で実行時データを読もうとしたが list_connected_browsers=[] で未接続。
• 出力破損が/clear後も継続。多行出力・repr・grep -n行番号が破損。対策＝python実バイトで小ファイル抽出→Read、grep -c単一値、heredocでスクリプト作成。
• 坂口さんが出ない原因の仮説：「ログも出ない＝added=0＝getAutoAppointments()が商談管理ページの実行時にSL SALONを返していない(データ無し or 実行時エラーでcatch→return 0)」が濃厚。コードは正しいので実行時の問題。

ユーザーFB（重要）

• 「最新にはなったけど坂口さんが入ってない」「出ないしverそのまま、リロード問題ではない」→ コンソール/リロードでは解決しない。
• 「githubで毎回デプロイしてる？」→ 答え：いいえ手動wrangler。
• 「ちゃんとTERASU CRMのシステム開発についてしっかり学習して着手してね」→ 推測で直すな・正しく理解してから。
• 「このdriveの問題、FSに限らずいろんなところで起こり得るやばい問題じゃない？」→ その通り。~/dev移行が根治(task_b386e3de切り出し済み)。

注意ポイント・退化リスク

• 出力破損が酷い：Read/grep表示を信じず実バイト(python)・単一値で確認。矛盾したら止める。
• Drive巻き戻り：~/株式会社SCALE/hp/terasu/ はDrive同期で旧版に巻き戻る。デプロイ直前にローカル実バイト(grep -c getAutoAppointments等)再確認必須。
• デプロイ未達の幻：wrangler「成功」表示を信じず、CF API canonical_deployment(acct=9c601cdb4666c746e5cb97fa00187f06・token=~/.cf_token)＋本番HTML実バイトverで検証。
• 坂口さん問題は推測で直さない。実行時データ(getAutoAppointmentsの戻り値)を確認してから。

次のセッションで取り得る選択肢

1. アポ獲得リスト(マーケ部署)に坂口さんが出るかスクショ/Chrome接続で確認→getAutoAppointmentsが返すか切り分け
2. _dealSyncFromSourcesのcatchにconsole.error、added=0でもapts/rf件数をログする一時デバッグ版をデプロイ→原因特定
3. getAutoAppointments全体(appointments.js 72-228行)を小ファイル抽出して精読し実行時エラー源を探す

引き継ぎファイル

/tmp/handoff_20260624_175300.txt