RCF-088 — P-type 對外名稱 Phase 2 客戶可見層 rollout
類型：SKILL（修改診斷起草核心步驟）+ 系統架構（跨 4 系統/檔案傳播） 日期：2026-06-16 觸發條件：條件 4（修改 SKILL 核心執行步驟）+ 條件 5（影響 2+ 技術系統：官網 + KM 模板 + SKILL） 相關文件：
knowledge/methodology/career-problem-patterns.md（對外名稱 SoT，Phase 1 建立）職涯停看聽_網站/index.html（官網案例卡）knowledge/product/d1-report-template.md（D1 客戶報告模板）.claude/skills/診斷起草.md/諮詢前分析.md/諮詢完成.mdknowledge/operations/line-bot-phase4-prompt-spec.md（評估後排除）
問題背景
Phase 1（2026-06-16 同日稍早）已在 career-problem-patterns.md 建立 P-type 六型對外名稱 SoT（P1 石沉型 / P2 未定向型 / P3 未譯型 / P4 未定價型 / P5 內耗型 / P6 未啟動型，中性精準命名哲學）。但對外名稱當時僅存在於 SoT 文件，客戶實際接觸的觸點（官網、診斷報告、SKILL 輸出）仍只用內部代號或舊描述，造成「品牌符號已定義但客戶看不到」。
Phase 2 將對外名稱 rollout 到客戶可見層。評估階段經 Tim 4 輪「足夠嚴謹完整嗎」追問，逐步揭露 14 項缺口（含 ③ LINE Bot 誤分類、案例卡實為 9 張非 4 張、SKILL 描述詞與 SoT 不一致、諮詢前分析殘留非 SoT 舊名「迷航型/觀望型」等），最終收斂為「①②④⑤ + Gap E/L 執行，③ 排除」。
信念變更紀錄
| 欄位 | 內容 |
|---|---|
| from（舊認知） | tasks.md Phase 2 清單把 ③ LINE Bot buildPtypeGuidance 歸入「客戶可見層」，假設其輸出是客戶看得到的標籤 |
| to（新認知） | buildPtypeGuidance 輸出是 Layer 2 動態注入「給 Gemini 的系統提示」，屬內部 AI scaffolding，客戶永遠看不到；依 SoT「內部用代號」規則，③ 不應 rollout 對外名稱，改之反而違反 SoT |
| trigger（觸發事件） | 執行前讀 spec §4.2-4.3 原文，發現 §4.3 PTYPE_GUIDANCE 在個人化注入模板內、且 L71 已明文「pain_pattern（P-type 代號）」 |
| 信心変化 | +（「執行前必讀實際程式碼/spec 而非依任務清單分類」的信念加嚴；任務清單的分類是假設，不是事實） |
考慮過的方案
| 方案 | 描述 | 優點 | 缺點 | 採用？ |
|---|---|---|---|---|
| 方案 A | 五觸點全 rollout（含 ③ 改為【石沉型】） | 表面「完整」執行任務清單 | 違反 SoT 內部命名；對客戶零效果；製造內部不一致 | ❌ 未採用 |
| 方案 B | 只改官網 ①，其餘延後 | 風險最小 | 客戶報告/SKILL 仍不一致；未解決品牌符號落地 | ❌ 未採用 |
| 方案 C（最終採用） | ①②④⑤ + Gap E/L 執行，③ 排除並記錄理由 | 客戶可見層全對齊 SoT；③ 守住內部命名規則；傳播點清單化便於未來三步協議 | 官網需部署驗證 | ✅ 採用 |
最終決策
採方案 C。核心理由：對外名稱只應出現在客戶真正看得到的觸點（官網案例卡、D1 報告正文、診斷起草對外輸出指引）；buildPtypeGuidance 是內部 AI 系統提示，依 SoT「內部一律用代號 P1-P6」必須排除——強行 rollout 不只無效，更違反我們自己的命名規則。同時補上 SoT 傳播點清單（Gap E），讓未來任一對外名稱變更時，Source-of-Truth 三步協議有明確掃描範圍。
① 官網採「小角標」設計（非取代既有 outcome-framing case-tag），框架為「解決的問題類型」，避免把問題標籤直接貼在成功案例上（Gap G 品牌風險）。
① 部署喊停→裁定後完成（2026-06-16）：執行三步協議 Step 3 grep 時發現 case-update-sop.md L31-38 早有 9 卡權威 P-type 指派，與本次「憑卡片文字重推」結果衝突 7/9；且 SOP 自身映射亦有可疑處（Card 03/09 標薪資型但內容為方向/可見度）。喊停 → 提報 Tim「裁定 A」→ Tim 採我重新校準的映射 → 更新 9 角標 + case-update-sop 映射表 → push + npx vercel --prod → 部署驗證（dev/deploy-verify/SYS-01-2026-06-16.md ✅）。執行教訓：① 應先讀既有映射記錄（case-update-sop.md + cases/）再對應，不可憑文字重推 → 收尾登錄 IMP-177 家族第 9 領域（命名/品牌化）執行續：「命名/映射類執行前未讀既有權威映射就重推」。
Gap O（裁定 B「最嚴謹最正確」→ 分層處置，2026-06-16）：發現兩代對外名稱並存——舊 Layer-1（2026-05-08：紙上英雄型/迷航型/說不到位型/身價不清型/職場悶局型/起跑焦慮型）。新舊 1:1 對應（紙上英雄→石沉/迷航→未定向/說不到位→未譯/身價不清→未定價/職場悶局→內耗/起跑焦慮→未啟動）。處置：
- 已遷移（內部記錄，allowlist 腳本 59 處）：
knowledge/cases/×13 + README +client-patterns.md+crm/intake-questionnaire.md+crm/questionnaires/×1 +crm/sessions/×2 + case-update-sop 映射表。 - 已遷移（課程教材，2026-06-16 結案，方案 A）：C2/C3 curriculum-design +
scripts/products/C3.yaml投影片講稿——原暫緩待教學審查；經 lecture-product-review 四層審查 + IMP-166 課程三件套（橫向全 scripts/products/ Grep 確認僅 C3.yaml 命中／縱向 SoT 1:1 對應確認／五關核對）後，Tim 裁定方案 A 全遷移至中性精準 SoT 名（C2×3 + C3 curriculum×16 + C3.yaml×15 = 34 處；含 P5 縮寫「悶局型」L225）。教學決策理由：課程受眾與對外品牌符號統一，杜絕兩代命名並存造成的學員/客戶認知落差；替換採「只換型名、不改解釋句」原則保留講稿教學語感。遷移後三檔 grep 舊名零殘留。 - 保留（歷史日誌）：daily-log / archives / crm·hr CLAUDE.md 修改記錄 / reflection-log——當時事實記錄不遷移。
- 根因：Phase 1 建立新 SoT 時未執行全庫三步協議遷移舊名 → 遺留遷移債。
影響範圍
| 影響類型 | 具體項目 |
|---|---|
| 新增文件 | knowledge/decisions/RCF-088-ptype-external-name-phase2-rollout.md；官網 dev/deploy-verify/SYS-01-2026-06-16.md（部署驗證） |
| 修改文件 | 官網 index.html（.case-ptype CSS + 9 卡角標）；d1-report-template.md（Section 0 對照欄 + Section 1/3/4 範例 header 對外名稱）；診斷起草.md（Step 3 對齊 SoT + Step 5 對外指引）；諮詢前分析.md（SoT 參照 + 修正非 SoT 舊名）；諮詢完成.md（SoT 參照）；career-problem-patterns.md（傳播點清單） |
| 觸發部門同步 | 無新 HARD STOP 規則文字變更 → 不觸發部門 CLAUDE.md 同步（本次為內容/範例層 rollout，非規則層） |
| 影響的 SKILL | 診斷起草、諮詢前分析、諮詢完成 |
驗證方式
- 官網：部署後瀏覽器開啟 careerssl.com，確認 9 張案例卡右上角小角標顯示正確對外名稱、桌機+手機版無重疊（deploy-verify 檔記錄）。
- D1 報告：跑真實案例測試（Tim 指定），確認診斷起草輸出的 Section 1 正文可自然帶入對外名稱、語氣中性。
- SoT 一致性：
grep -rn "迷航型\|觀望型"確認無殘留非 SoT 舊名；對外名稱變更時，傳播點清單 5 項全掃。