💻 システム開発

2026-05-13_SCALE_CRM_v9.171-v9.195_作業ログ

最終更新 2026年05月13日／ 31_システム開発部/SCALE_CRM/2026-05-13_SCALE_CRM_v9.171-v9.195_作業ログ.md

2026-05-13 SCALE CRM 改修ログ（v9.171〜v9.195 / 25バージョン）

12:31 - v9.195 デプロイ（v9.194で塞ぎきれなかった削除復活バグ削除ログ独立永続化+ゴミ箱自動修復 8経路二重三重防御）

FB（v9.194 でも再発）

「またリロードしたら復元しちゃった。スクショ送るね / リロード前はちゃんと削除されてて、上の削除ボタンの横の(）の中に削除した件数も出るんだけど、そこタップしたら削除したものはないって出る / ここもなんか問題ありそう」

v9.194 では塞ぎきれなかった理由（再分析）

window._clJustPurged は 5秒タイマー + リロードで消える — タイミング次第で防御が効かない
localStorage 自体の deleted_at が消えると _initSupabase の deleted_at 差分判定も発動しない
結果: D1値で local 上書き → call_list本体とゴミ箱両方から削除情報が消失（FB「ゴミ箱が空」が証拠）

修正内容（v9.194 の上に積み増し・1リリースで全部）

①削除ログ独立永続化 (core.js): sb__deletelog_call_list_<projId> という別キーに {id, deleted_at, deleted_by} を記録 / call_list 本体が D1 値で上書きされてもここから deleted_at を再付与できる
②3つの API 新設: _clRecordDeleteLog / _clApplyDeleteLog / _clRemoveDeleteLog / 90日経過で自動 purge
③_clJustPurged を localStorage 永続化 (core.js): sb__cl_just_deleted_until キーに 60秒間の until タイムスタンプ / リロードを跨いで _initSupabase 防御を効かせる / _clMarkJustDeleted() / _clIsJustDeleted()
④_initSupabase 防御強化 (core.js): D1 fetch 後すぐに _clApplyDeleteLog で deleted_at 再付与 → その後で防御判定 / _clIsJustDeleted true なら確実に local 維持 + D1 逆同期
⑤localStorage 再シリアライズ (core.js): call_list の場合は deleted_at 再付与済の v を JSON.stringify して localStorage 反映 / 元の raw r.value で上書きしていた経路を断つ
⑥ゴミ箱食い違い自動修復 (calllist.js showCallTrash): 開いた瞬間に _clApplyDeleteLog 実行 → 削除ログにあるが call_list 本体に deleted_at が無いケースを検出して自動復元 + D1 PUT + 通知 toast
⑦_flushCallListToD1 3回リトライ (core.js): 500ms / 1500ms バックオフ / 3回全失敗時はユーザーに警告 toast
⑧トレース: [DEL-LOG] / [CL-TRASH v9.195] / [_initSupabase v9.195] / [FLUSH-CL-D1] — 削除→保存→D1→リロードのすべてのステップで観測可能

編集ファイル

core.js (_clRecordDeleteLog/_clApplyDeleteLog/_clRemoveDeleteLog/_clMarkJustDeleted/_clIsJustDeleted 新設、_flushCallListToD1 3回リトライ、_initSupabase 削除ログ適用+再シリアライズ)
calllist.js (_clBulkDelete/delCall/restoreCall/permanentDelCall/emptyCallTrash 全部に削除ログ呼び出し、showCallTrash に自動修復)
service.js (COCREATE_VERSIONS v9.195 追加)

バックアップ

pre-deploy: ~/scale-lead-backups/scale-lead-2026-05-13-1231-pre-deploy.tar.gz
post-deploy: ~/scale-lead-backups/scale-lead-2026-05-13-1231-post-deploy.tar.gz

退化リスクメモ（v9.195 で追加）

sb__deletelog_call_list_<projId> キーを _safeSetItem のクリーンアップ対象に絶対に入れない — 削除ログが消えると自動復元できなくなる
sb__cl_just_deleted_until キーも同様
削除系関数の async/await 順序: _clRecordDeleteLog → _clMarkJustDeleted → PS → _flushCallListToD1 → toast この順序を守る
showCallTrash の自動修復ロジック: 削除ログとの食い違いを発見したら自動で復元するため、ユーザーが「ゴミ箱が空」と報告したら自動修復が走ったことを伝える

12:21 - v9.194 デプロイ（架電リスト削除→リロードで復活バグ 7経路一気に根治）

FB

「＜架電リスト＞選択をして削除を押したんだけどリロードすると、それが消えてなく戻っちゃう / 表示は削除しましたって出るんだけど」

真因 1点確定

PS('call_list',calls) 内部の _syncToSupabase は 300ms debounce で D1 PUT する設計。削除直後にリロードすると debounce 待ち中で D1 PUT が走らず、D1 には削除前データのまま → リロード時 _initSupabase が古い D1 値で local を上書きして deleted_at が消える → 復活して見える。

修正内容（1リリースで全部）

①_flushCallListToD1(reason) ヘルパー新設 (core.js): debounce バイパスして即時 D1 PUT を await
②全削除関数 async化 + _flushCallListToD1 呼び出し (calllist.js): _clBulkDelete / delCall / restoreCall / permanentDelCall / emptyCallTrash
③_clJustPurged フラグ拡張: 従来は purgeAllCallList (全件削除) のみだったが、個別削除でも 5秒間立てる → _initSupabase / forceFetchCallListFromD1 防御を確実に発動
④_initSupabase 防御に deleted_at 差分判定: local deleted_at 件数 > D1 deleted_at 件数 なら local 優先 + D1 逆同期
⑤forceFetchCallListFromD1 v9.146防御に deleted_at 差分判定: 同上
⑥beforeunload 保険: _syncTimers に残った pending PUT を fetch keepalive で強制送信（タブクローズ/リロード時も D1 に届く）
⑦トレース3種: [FLUSH-CL-D1] / [_initSupabase 防御 v9.194] / [forceFetchCallListFromD1 v9.194]

編集ファイル

core.js (_flushCallListToD1 / _initSupabase 防御 / forceFetchCallListFromD1 / beforeunload)
calllist.js (_clBulkDelete / delCall / restoreCall / permanentDelCall / emptyCallTrash → 全部async化)
service.js (COCREATE_VERSIONS v9.194 追加)

バックアップ

pre-deploy: ~/scale-lead-backups/scale-lead-2026-05-13-1221-pre-deploy.tar.gz
post-deploy: ~/scale-lead-backups/scale-lead-2026-05-13-1221-post-deploy.tar.gz

退化リスクメモ（v9.194 で追加）

_flushCallListToD1 は削除系関数の PS の直後で必ず呼ぶ — debounce バイパスして D1 即時反映
window._clJustPurged は個別削除でも 5秒間立てる — _initSupabase / forceFetchCallListFromD1 防御スキップに必須
_initSupabase の防御条件は OR で _localHasMoreDeletes を含める — 削除1件でも確実に発動
beforeunload の keepalive fetch を削除禁止 — debounce 待ちのデータが D1 に届かない事故防止

12:13 - v9.193 デプロイ（PM担当セレクト+Slack自動招待 4経路一気に根治・ラリー最小化ルール初適用）

FB

「リスト依頼のチャンネル新設に伴って、既存案件を案件編集のところから、自動作成でチャンネル作ったときに自動で細川も入っちゃう。PM権限なくして、担当メンバーにも選択していないのに。多分初期設計で上書きされているのか案件編集のところチェックしたパートナーだけ反映される以外の違う設定されてるかも。案件編集のPM担当（複数選択可）のところにも、まだ細川が残っているし（ここはメンバー編集でPM権限与えているメンバーだけ見れるようにしたいね）」

ラリー最小化バッチ対応（5/13 大串FBルール初適用・成功例）

想定原因 4経路全部 をリサーチ → 1リリースで全部根治
トレース3種を全経路に同時投入
ユーザー検証依頼も1メッセージで全部同梱
1ラリーで完了

真因 4経路（全部同時根治）

core.js:2589-2593 — fallbackNames=['大串','細川'] ハードコードでPM候補に強制追加 / メンバー編集で外しても案件編集を開くたびに復活
core.js:1747 — DEFAULT_MEMBERS に細川 {role:'admin',type:'pm'} ハードコード / stored から消えると stored.unshift(dm) で復活
pages.js:4421 _slackInviteProjectMembers — m.name==='大串' || m.role==='admin' || m.type==='pm' || pms.includes(m.name) で admin/pm なら案件問わず強制招待
p.pms 永続データ — 過去にチェックされた「細川」名前が pms.includes() で引っかかる

修正内容（1リリースで全部）

①PM候補fallback廃止 (core.js): 強制追加コード削除 + 「メンバー編集でPM権限を持つメンバーだけ表示」ヘルプ文 + 0人時の警告UI
②DEFAULT_MEMBERS縮小 (core.js): 細川を DEFAULT_MEMBERS から削除 / 残るは大串(admin) 1人のみ
③Slack招待ロジック簡素化 (pages.js): 「現在PM権限ある人 (validPms) + 案件アサインパートナーのみ」/ admin/pm/大串の強制招待を全廃
④p.pms 過去残骸フィルタ (core.js × 2 + pages.js): 保存時+招待時に「現在PM権限を持つメンバーの名前」だけ残す
⑤_slackBulkInviteAll 整合化 (pages.js): m.name==='大串' ハードコード削除
⑥トレース3種: [SLACK-INVITE] / [SLACK-INVITE-TARGETS] / [SLACK-BULK-INVITE] / [PMS-FILTER createProject/updateProject]

既存案件への適用フロー

案件編集を開いて保存するだけで p.pms から細川が自動的に消える。自動作成も同タイミングで細川除外される。新規 teleapo_list_request チャンネル作成時も発動。

編集ファイル

core.js (DEFAULT_MEMBERS / pmCandidates fallback / pms保存×2箇所)
pages.js (_slackInviteProjectMembers / _slackBulkInviteAll)
service.js (COCREATE_VERSIONS v9.193 追加)

バックアップ

pre: ~/scale-lead-backups/scale-lead-2026-05-13-1210-pre-pm-slack-fix.tar.gz
pre-deploy: ~/scale-lead-backups/scale-lead-2026-05-13-1213-pre-deploy.tar.gz
post-deploy: ~/scale-lead-backups/scale-lead-2026-05-13-1213-post-deploy.tar.gz

退化リスクメモ（v9.193 で追加）

DEFAULT_MEMBERS に細川を再追加禁止 — 通常メンバーとしてメンバー編集で管理する
fallbackNames=['大串','細川'] を再追加禁止 — UI 0人時の警告で対応
_slackInviteProjectMembers の招待条件: pms (validPms) + 案件アサインパートナーのみ。admin/pm/大串の強制招待は v9.193 で意図的に廃止
p.pms は保存時に validPmNames でフィルタ — createProjectFromModal / updateProject の両方で必須

11:56 - /handoff 実行

対象システム

SCALE CRM (scale-lead) — 1日で v9.171→v9.192 まで 22バージョン デプロイ

セッション背景

2026-05-12 (前日) の Phase 1〜5 + v9.163-170 連続Polish (14バージョン) を引き継ぎ、本日は Slack通知系の大規模再設計 + メンバー編集消失バグの長期追跡(8バージョン)+真因確定根治 を実施。

最後にユーザーから ラリー最小化ルール が出され、Vault 4ファイルに恒久反映。

完了タスク（v9.171〜v9.192 / 22バージョン）

Slack 通知大規模再設計 (v9.171-v9.174)

v9.171: 作業報告スレッド型化 (案件×メンバー×日付で1スレッド) / 設定セクションに案件別Slackチャンネル設定UI追加 (ダッシュボードと同期)
v9.172: オンライン表示案件スコープ化 (_isOnlineInCurrentProject) / 架電報告スレッド集約 (6種類→teleapo_loss に集約) / メンション全廃止 / teleapo_loss 表示「失注報告」→「架電報告」
v9.173: アポ報告のみ teleapo_apo 単発投稿に戻す (FB対応)
v9.174: メール日程調整を架電報告スレッドへ (未確定アポ判定) / リスト依頼通知送信先見直し (案件専用 teleapo_general 優先) / 文面メンション削除

トレーサ追加 + 設定同期 (v9.175-v9.181)

v9.175-180: [SLACK-TRACE] [ONLINE-TRACE] 各経路にトレース仕込み (Slack 投稿成功してたがチャンネル招待不足で見られず → 大串Slackで確認OK判明)
v9.181: 案件別Slackチャンネル設定 D1強制fetch同期 (ダッシュボード自動作成と設定ページの非同期問題)

Slack バグ修正 + UX改善 (v9.182-v9.184)

v9.182: 大バグ修正 - saveCallStatusModal に _checkSlackOnStatusChange トリガー追加 → 必須項目モーダル経由のステータス変更で Slack 通知が一度も呼ばれていなかった
v9.183: リスト依頼案件専用チャンネル化 (teleapo_list_request 新設)
v9.184: ステータスモーダル過去値クリア (KEEP_PREVIOUS のみ前回値) / 電話番号クリックコピー強化 / リスト依頼ドラフト自動復元廃止

細かいFB (v9.190)

v9.190: 「日報入力に戻る」ボタン削除

メンバー編集消失バグ追跡 8バージョン (v9.185-v9.192)

長期戦の振り返り (反省例):
- v9.185: _refreshOnlineMembersUI D1 fetch ガード → 違う
- v9.186: MEMBER-TRACE 仕込み
- v9.187: BroadcastChannel/D1Poll 防御 → 違う
- v9.188: _cache.members setter 傍受 → 警告出ない
- v9.189: cache-bust 強制更新
- v9.191: 配列要素 Proxy 検出 → 真犯人発見!
- v9.192: 真因確定+根治 - getMembers() の stored[idx]={...stored[idx],...dm} で DEFAULT_MEMBERS が stored を上書き / 大串・細川 (DEFAULT_MEMBERS ハードコード) が getMembers 呼び出しのたびに role/type=admin/pm に強制リセット / 修正: merge 順序逆転 {...dm,...stored[idx]} で stored 優先

ラリー最小化ルール恒久化 (Vault 4ファイル更新)

22_AI運用ルール/Claude_動き方ガイド.md → 大串の3大原則に「5. エラー対応・システム開発はラリー最小化」追加
31_システム開発部/_SCALE_共通_トラブルシューティング集.md → 冒頭に「最上位ルール: ラリー最小化バッチ対応」+ D3パターン追加
90_Meta/CLAUDE_global.md → 同ルール反映
grep 検出パターン公開 (DEFAULT_* 上書き系バグの未然検出)

編集ファイル

/Users/oogushiyuuki/株式会社SCALE/scale-lead/core.js — getMembers() merge順序逆転 / _cache.members setter+Proxy 傍受 / BroadcastChannel + _d1PollTick で members 防御
/Users/oogushiyuuki/株式会社SCALE/scale-lead/pages.js — saveMember トレース / _slackPostStartReport 等のスレッド型通知 / _slackPostCallReportToThread / _slackGetOrCreateDailyThread / オンライン表示D1強制fetch / SLACK_PROJECT_CHANNEL_DEFS+SLACK_GLOBAL_CHANNELS に teleapo_list_request 追加 / _refreshOnlineMembersUI でメンバー編集10秒以内D1fetchスキップ / メンバーモーダル過去値クリア
/Users/oogushiyuuki/株式会社SCALE/scale-lead/calllist.js — saveCallStatusModal に _checkSlackOnStatusChange トリガー追加 / submitListRequest 送信先優先順位変更 + メンション全削除 / 電話番号クリックコピー強化 / リスト依頼ドラフト自動復元廃止 / 日報入力に戻るボタン削除
/Users/oogushiyuuki/株式会社SCALE/scale-lead/service.js — COCREATE_VERSIONS v9.171〜v9.192 追加 / AI共創 prompt は前日のまま
/Users/oogushiyuuki/株式会社SCALE/scale-lead/index.html — cache-bust 多数更新

デプロイ・バックアップ

本日のデプロイ回数: 22回 (v9.171〜v9.192)
最終デプロイ: 2026-05-13 11:50 (v9.192)
本番URL: https://crm.scale-group.co.jp/
最新バックアップ: ~/Library/CloudStorage/.../scale-lead-backups/scale-lead-2026-05-13-1150-post-deploy.tar.gz

試したこと・学び（重要）

メンバー編集消失バグの 8バージョン追跡 (ラリー反省)

書き込み側 (saveMember) ばかり疑って、読み取り関数 (getMembers) に副作用がある可能性を最後まで疑わなかった
v9.191 で Proxy 仕込んでようやく真犯人特定 — でも v9.185 から数えて 8バージョン使った
→ トラブルシューティング集 D3 として登録
→ 「ラリー最小化」ルールが今後の標準に

ラリー最小化ルール (大串FB原文)

「今回みたいにエラーが起きたときに何回やっても治らないのが一番タイムロスでしんどい。1個ずつ検証して・1個ずつ依頼して、ではなく一気に人間が試すこと依頼しつつ、一気に実装、全部やれることリサーチして、全部一気に修正、みたいにまとめてやりたい。ラリーは最小化したい、一回が重くても。」

→ Vault 4ファイルに恒久反映済

ユーザーFB（重要なやつ全部）

Slack 通知系

「作業終了/中断/開始通知が違うグループに来る・案件ごとのグループに送って」→ v9.171 案件専用 teleapo_work 優先化
「SCALE Baseの作業報告と同じく1日ごとのタイトル付き親メッセージにスレッド型」→ v9.171 _slackGetOrCreateDailyThread
「ダッシュボードと設定セクションで同期させて」→ v9.171 案件別Slack設定UI / v9.181 D1強制fetch
「失注報告グループ名を架電報告に変更・6種類全部スレッド集約」→ v9.172 / v9.173 / v9.174 で 5種類確定
「メンション全部なし」→ v9.172-v9.174
「リスト依頼通知が来ない・各案件のグループ化」→ v9.183 teleapo_list_request 新設
「アポ報告は今まで通り (タイトル付けず・teleapo_apo 単発)」→ v9.173
「メール日程調整はアポ判定じゃないから分けたい」→ v9.174 架電報告へ移動
「リスト依頼の文面 * と (SalesNow完全統一) は削除」→ v9.177
「クライアント名 [結グループ] タイトルに不要」→ v9.179

架電リスト UX

「ステータスモーダルの過去値自動反映で誤送信事故・毎回まっさら」→ v9.184 KEEP_PREVIOUS 限定
「電話番号クリックでコピー」→ v9.184 強化 (実は v9.184 以前から動作・toast 強化のみ)
「日報入力に戻るボタンの謎仕様なくして」→ v9.190
「Aさんが A案件にログイン中、B案件でもオンライン表示」→ v9.172 案件スコープ化

リスト依頼

「前回内容が残ってる・毎回まっさら」→ v9.184 ドラフト自動復元廃止
「履歴は全員分見れる」→ 既存仕様で OK 確認

メンバー編集 (長期戦)

「権限/タイプ変更しても保存後に元に戻る」→ v9.185-v9.192 で 8V 追跡 → v9.192 真因確定根治

開発スタンス FB (最重要)

「ラリー最小化したい・一気に試すこと依頼・一気に実装」→ Vault 4ファイル恒久反映

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

getMembers() の merge 順序: 必ず {...dm,...stored[idx]} (stored優先)。逆にすると v9.192 バグ再発
DEFAULT_* と stored の merge は spread 順序に注意: トラブルシューティング集 D3 参照
_cache.members は Object.defineProperty で setter 傍受 + Proxy で配列要素も傍受: 通常時は quiet、saveMember 10秒以内のみ warn
saveCallStatusModal の Slack 通知トリガー: v9.182 で追加・削除すると Slack 通知再発不可
_memberJustSavedAt フラグ: window グローバル / 10秒間 / _refreshOnlineMembersUI + BroadcastChannel + _d1PollTick で参照
Slack 親スレッド ts は D1 key "proj_daily_thread" / "projcall_report_thread_" に保存: 同日中なら同じスレッドに集約
teleapo_list_request 新規キー: 既存案件で空のため、案件編集の「全Slackチャンネル一括作成」を再実行する必要あり

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

ユーザーFB待ち — v9.192 の動作確認結果 (細川 role/type 編集の永続化確認)
AI共創品質確認 — v9.162 で品質第一モードに転換した AI共創を実機で確認
架電リスト一括選択UI の実機確認 — v9.168 でデプロイ・一括ステータス変更/削除/担当者変更
トレーサのクリーンアップ — [MEMBER-TRACE] [SLACK-TRACE] [ONLINE-TRACE] は本番でも常時出力 → 真因確定後の整理が必要なら次回
他システム (TERASU CRM 等) への横展開 — getMembers() の DEFAULT_* 上書きパターン grep + 修正

引き継ぎファイル

/tmp/handoff_20260513_115604.txt

累積効果まとめ（v9.171〜v9.192）

Slack 通知系: スレッド型化 / 案件専用チャンネル化 / メンション全廃止 / 設定2方向同期 / リスト依頼専用ch
架電リスト: ステータスモーダル過去値クリア / 電話番号確実コピー / 一括選択UI（前日）/ 日報入力ボタン削除
メンバー編集: 真因確定+根治（DEFAULT_MEMBERS 上書きバグ）/ Vault D3 パターン追記
オンライン表示: 案件スコープ化 / D1 強制fetch で別端末即時反映
運用ルール: ラリー最小化バッチ対応 を Vault 4ファイルに恒久反映

→ SCALE CRM が「Slack通知が正しいチャンネルにスレッド集約される」+「メンバー編集が確実に保存される」状態に到達。
→ ラリー最小化ルールが今後の開発の標準動作に。

12:02 - /handoff 実行（SCALE Base 大規模リファクタ）

対象システム

SCALE Base（/Users/oogushiyuuki/Library/CloudStorage/GoogleDrive-y-ogushi@scale-group.co.jp/マイドライブ/AI/scale-base/）

セッション背景

SCALE Base の UX / 機能改修を連続で対応。ユーザー FB ベースで「サイドバー左下に役職表示じゃなくバージョン表示してほしい」「アイコンタップで設定モーダル」「画像アップロード対応」「FS と PM を SCALE Lead に統合」「TERASU セクション追加」「マイタスクの絞り込み調整」「定例タスクの累計実働が日毎に足されて超過扱いになる」「想定所要時間を作業時間に改名」を順次対応。

完了タスク（詳細・8件）

ce-2026-05-13-01 アプリバージョン表示
- lib/app-version.ts 新規: APP_VERSION = v1.${CHANGELOG.length}
- Header 右上 + SystemSidebar 左下に表示・クリックで /changelog 遷移
- 役職（departmentName）表示を撤廃
- メンバー設定の icon / iconBg を avatar に反映
- app/(dashboard)/layout.tsx: TasksProvider を /tasks 限定 → 全ページラップに変更
- lib/tasks-api.tsx に useTasksOptional 追加（祖先 Provider なしでもエラー出ない）
ce-2026-05-13-02 アイコン設定モーダル
- components/layout/IconPickerModal.tsx 新規
- 左下 avatar / 右上 avatar クリックでモーダル起動
- 自分のメンバーレコードだけを編集（他人は触らない）
- 「なし」「アイコンをクリア」「キャンセル」「保存」
ce-2026-05-13-03 画像アップロード対応
- lib/tasks-api.tsx TaskMember 型に iconImage?: string 追加（base64 data URL）
- IconPickerModal に画像選択 UI + Canvas で 256x256 中央クロップ + JPEG 85% 圧縮
- 10MB 上限・画像設定中は emoji UI を非表示（モード切替）
- 表示優先: iconImage > icon+iconBg > 頭文字
ce-2026-05-13-04 FS + PM → SCALE Lead 統合
- lib/systems.ts id="fs" の name を「FS」→「SCALE Lead」、shortName を「Lead」に
- id="pm" エントリ完全削除（externalUrl は scale-pm.pages.dev だった）
- SystemId 型から "pm" 削除
- departmentGroups 「FS/PM/品質管理」→「SCALE Lead/品質管理」
- auth-context の allowedSystems から "pm" 削除
- admin-data の SYSTEM_LABELS から "pm" 削除・"fs" → "SCALE Lead"
- DEFAULT_DEPARTMENTS: 経営から pm 削除、PM 部門 → 「SCALE Lead 運用」改名
- externalUrl: https://scale-fs.pages.dev/login/
ce-2026-05-13-05 TERASU セクション新設
- lib/systems.ts id="terasu" エントリ追加（icon: Sparkles / orange）
- SystemId 型に "terasu"
- departmentGroups の SCALE Lead/品質管理に追加
- auth-context allowedSystems に "terasu" 追加
- external-auth SKIP_AUTH_DOMAINS に crm.terasu.scale-group.co.jp 追加
- externalUrl: https://crm.terasu.scale-group.co.jp/
ce-2026-05-13-06 マイタスク再度セッション内除外
- inSession 除外を復活
- 各行の「セッション中」バッジ + 「+ 追加」分岐
- → ユーザーから「朝日報追加未完了が消える」FB
ce-2026-05-13-07 マイタスク全タスク表示に戻す（仕様揺れ）
- フィルタを isMineAssignee + status !== "完了" のみに
- 「セッション中」バッジ完全削除
- 重複追加防止は addExistingBaseTask 側で progress.some(...) で return
ce-2026-05-13-08 定例タスク累計リセット + 想定所要 → 作業時間
- lib/work-log.ts getAccumulatedMsForTask に sinceISO 引数追加
- lib/tasks-api.tsx getRoutinePeriodStartISO / getPeriodStartForTaskName 新設
- daily/everyday → 当日00:00 / weekly → 月曜起点 / biweekly → 14日前 / monthly → 当月1日 / quarter → 当四半期初日 / adhoc → undefined
- 全呼び出し（ActiveBoard / start / end / night / morning）で routine 由来なら sinceISO を渡す
- start ページ「想定所要時間」「想定所要」を「作業時間」に統一（ラベル / Slack通知 / 合計時間カード / 警告文）
- work-log/page.tsx の pause/resume で user null チェック追加（TS エラー解消）

編集ファイル

lib/app-version.ts（新規）
components/layout/IconPickerModal.tsx（新規）
lib/changelog.ts（8 件追記）
lib/systems.ts
lib/auth-context.tsx
lib/admin-data.ts
lib/external-auth.ts
lib/tasks-api.tsx
lib/work-log.ts
components/layout/SystemSidebar.tsx
components/layout/Header.tsx
app/(dashboard)/layout.tsx
app/(dashboard)/tasks/members/page.tsx
app/(dashboard)/tasks/work-log/morning/page.tsx
app/(dashboard)/tasks/work-log/start/page.tsx
app/(dashboard)/tasks/work-log/end/page.tsx
app/(dashboard)/tasks/work-log/night/page.tsx
app/(dashboard)/tasks/work-log/page.tsx
components/tasks/work-log/ActiveBoard.tsx

デプロイ・バックアップ

pre-deploy: 2026-05-13_104941_pre-deploy.tar.gz
post-deploy: 2026-05-13_120043_post-deploy.tar.gz
本番URL: ✅ HTTP 200（home / active / start / routines）
changelog: ce-2026-05-13-01 〜 ce-2026-05-13-08（8件）
アプリver: v1.189

試したこと・学び

マイタスクの仕様は3回揺れた（07: 全表示+バッジ → 06: 除外+バッジなし → 07: 全表示+バッジなし）→ ユーザー利用感に沿って収束
TasksProvider を全ページに広げると、useTasksOptional がなくても全画面で members を取れる（よりシンプル化）
画像アップロードは base64 で十分（256x256 で約 30KB・KV 25MB 上限に余裕）
定例頻度リセットは getAccumulatedMsForTask の sinceISO 引数1つで全画面対応できた（呼び出し元で getPeriodStartForTaskName を渡すだけ）

ユーザーFB（重要）

「経営みたいな役職表示いらない」→ 廃止
「ver が CRM みたいに見えると退化チェックに便利」→ APP_VERSION 表示
「毎回デプロイ時に今回はverなんとかって報告して」→ 運用ルール化
「アイコンタップで設定できるように」→ モーダル化
「アイコンタップしても写真入れれない」→ 画像アップロード追加
「FS と PM を SCALE Lead に集約・PM 削除」→ 完了
「TERASU セクション追加して」→ 完了
「マイタスクに今セッション中のタスク出さないで」→ 06 で対応
「朝日報で追加した未完了タスクが除外されてる」→ 07 で全表示に戻す
「読書 1日 30分が日が経つと累計で超過扱い」→ 定例頻度リセット
「想定所要時間は作業時間に改名」→ 完了
「絵文字使うの禁止」→ 過去対応済（Lucide 化）

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

5/11 緊急対応: bottom_tasks（定例）が KV から消える事故 → audit_log から 81件復元（frequency 一律 daily で再設定）。ユーザー側で各タスクの frequency / estimateMinutes / link を再設定すべき
マイタスク仕様揺れ: 07 番が最終形。今後変更する時は「セッション内も表示」「重複追加は addExistingBaseTask 側で return」を守る
APP_VERSION: 必ず CHANGELOG.length に連動。デプロイ毎に1ずつ上がる → 退化時は数字が下がるので一目でわかる
TasksProvider 全ページ化: /home 等でも KV から tasks/members を取得するようになった。リソース負荷は軽微だが、レンダー数増加に注意
TERASU は SKIP_AUTH_DOMAINS: ?auth= クエリは付かない（独自認証 URL）
routine 頻度リセット: getPeriodStartForTaskName は bottomTasks を引く。base タスクと name 一致してしまうと誤判定の可能性（routine 名と base 名が同名の時は routine 優先）

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

5/11 復元の定例 81件を整える — frequency / dayOfWeek / estimateMinutes / link をユーザーと確認しながら再設定（運用タスク）
bottom_tasks の単一障害点対策 — F3 全データ JSON バックアップに routine も含める（既に含まれてる？確認）/ localStorage キャッシュ追加 / Cloudflare KV のバージョニング検討
72項目ロードマップ — _SCALE_Base_72項目ロードマップ_現状分析.md から次の1項目を抽出（候補: B1 週次レポート / F3 復元機能 / P0-2 残り4プロジェクト）
マイタスクの並び順 — 期日順だけでなく優先度・推定時間など切替機能

引き継ぎファイル

/tmp/handoff_20260513_120238.txt

2026-05-13_SCALE_CRM_v9.171-v9.195_作業ログ

2026-05-13 SCALE CRM 改修ログ（v9.171〜v9.195 / 25バージョン）

12:31 - v9.195 デプロイ（v9.194で塞ぎきれなかった削除復活バグ 削除ログ独立永続化+ゴミ箱自動修復 8経路二重三重防御）

FB（v9.194 でも再発）

v9.194 では塞ぎきれなかった理由（再分析）

修正内容（v9.194 の上に積み増し・1リリースで全部）

編集ファイル

バックアップ

退化リスクメモ（v9.195 で追加）

12:21 - v9.194 デプロイ（架電リスト 削除→リロードで復活バグ 7経路一気に根治）

FB

真因 1点確定

修正内容（1リリースで全部）

編集ファイル

バックアップ

退化リスクメモ（v9.194 で追加）

12:13 - v9.193 デプロイ（PM担当セレクト+Slack自動招待 4経路一気に根治・ラリー最小化ルール初適用）

FB

ラリー最小化バッチ対応（5/13 大串FBルール 初適用・成功例）

真因 4経路（全部同時根治）

修正内容（1リリースで全部）

既存案件への適用フロー

編集ファイル

バックアップ

退化リスクメモ（v9.193 で追加）

11:56 - /handoff 実行

対象システム

セッション背景

完了タスク（v9.171〜v9.192 / 22バージョン）

Slack 通知 大規模再設計 (v9.171-v9.174)

トレーサ追加 + 設定同期 (v9.175-v9.181)

Slack バグ修正 + UX改善 (v9.182-v9.184)

細かいFB (v9.190)

メンバー編集消失バグ追跡 8バージョン (v9.185-v9.192)

ラリー最小化ルール 恒久化 (Vault 4ファイル更新)

編集ファイル

デプロイ・バックアップ

試したこと・学び（重要）

メンバー編集消失バグの 8バージョン追跡 (ラリー反省)

ラリー最小化ルール (大串FB原文)

ユーザーFB（重要なやつ全部）

Slack 通知系

架電リスト UX

リスト依頼

メンバー編集 (長期戦)

開発スタンス FB (最重要)

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

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

引き継ぎファイル

累積効果まとめ（v9.171〜v9.192）

12:02 - /handoff 実行（SCALE Base 大規模リファクタ）

対象システム

セッション背景

完了タスク（詳細・8件）

編集ファイル

デプロイ・バックアップ

試したこと・学び

ユーザーFB（重要）

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

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

引き継ぎファイル

12:31 - v9.195 デプロイ（v9.194で塞ぎきれなかった削除復活バグ削除ログ独立永続化+ゴミ箱自動修復 8経路二重三重防御）

12:21 - v9.194 デプロイ（架電リスト削除→リロードで復活バグ 7経路一気に根治）

ラリー最小化バッチ対応（5/13 大串FBルール初適用・成功例）

Slack 通知大規模再設計 (v9.171-v9.174)

ラリー最小化ルール恒久化 (Vault 4ファイル更新)