官網轉換 + ERP 串接 · 規格寫作進度總覽

Handoff dashboard · 更新：2026-07-01（下午 · ④ Layer 2 完成後）· 給新 thread 接手用
給接手的 Taco
這份是翠翠（U06UJ7RN7B9）交接用文件。她要開新 thread 繼續寫規格，看完這份即可無縫接續。詳細寫作原則、規格 template、Notion 操作習慣見接手 brief v2：spec_handoff_brief_v2.md。

進度儀表板

36
Sheet 上規格總數
4
已完成
目錄 1. 專案背景 2. Layer 1 / Layer 2 分層思維 3. 已完成規格（4 份） 4. 待寫規格清單（31 項） 5. 關鍵決策記錄 6. 待確認事項 7. 寫作原則 8. 相關資源與連結

1. 專案背景

Check2Check 官網從現行廠商 莫筆克 轉換到新廠商 康德，並串接 鼎新 ERP。 翠翠 2025-12-20 加入專案，負責寫規格給康德工程師做開發依據。目標里程碑：

Vendor lock：康德 7/15 前、鼎新 9/1 前。

廠商角色

2. Layer 1 / Layer 2 分層思維

翠翠這次進度中頓悟的核心分層概念（見接手 brief v2 §3）：

2026-06-30 進一步釐清：Layer 2 spec 不寫「值是怎麼來的」，只寫「怎麼用這些值做判斷」。值的定義回到 Layer 1 spec。這樣未來規則異動只改一份。

重要邊界
規格只寫業務需求，不寫廠商實作（DB schema、程式變數名、UI 框架都不寫）。翠翠 2026-06-30 這天 internalize 了這條原則，且反過來影響 3 份已完成 spec 都做了「越界清理」。

3. 已完成規格（4 份）

① 空運違禁品 Layer 1 · 已完成
Sheet row 17 · 平台：官網 · 分類：訂單 · 必要性：G
某些商品（鋰電池、噴霧罐、易燃品）依航空法規不能空運。上架時勾選「空運違禁品 = 是」→ 排除物流欄位自動加勾 2 項（超取 7-11 / 超取全家）。
2026-06-30 修正：自動連動從 3 項改成 2 項（海外配送不勾，因為海外配送 = 假物流）
Notion 頁面
② 排除物流 Layer 1 · 已完成（Layer 2 拆離後瘦身版）
Sheet row 14 · 平台：官網 · 分類：訂單 · 必要性：G
人員於商品上架頁勾選「排除物流」（可複選，預設全不勾，不可 4 項全勾）。4 個選項：超取 7-11 / 超取全家 / 宅配 / 海外配送。
2026-06-30 瘦身：把「結帳時判斷」相關內容從此份移出，搬到 Layer 2「結帳物流選擇規則」。這份現在只講上架欄位定義 + 上架行為。
Notion 頁面
③ 拆分購物車（結帳設定） Layer 1 · 已完成
Sheet row 16 · 平台：官網 · 分類：訂單 · 必要性：R · 康德報價：7 天 / NT$112,000
購物車拆分結帳邏輯。商品有「結帳設定」欄位（3 選 1）：
  • 不指定（預設）：合併同結帳區塊
  • 單獨配送：強制獨立（兩個單獨配送也不合併）
  • 指定配送群組編號（01-20）：相同編號合併、不同編號拆分
拆完每張結帳區塊獨立算：金額、免運、促銷、發票、物流、優惠／折扣、付款。優惠不可跨區塊。
2026-07-01 完稿：UI 段加入 tooltip 補充說明（單獨配送 / 指定配送群組編號 兩選項旁的 ? 圖示）；踩線清乾淨（DB/商品主檔/= syntax/輸入框全改用業務語言）。
Notion 頁面
④ 結帳物流選擇規則（Layer 2） Layer 2 · 已完成
Sheet 上待新增 row · 平台：官網 · 分類：訂單 · 時數：0 天（邏輯說明用，不單獨開發）
「結帳時能選哪些物流」的判斷邏輯總綱。整合兩個輸入：商品的排除物流設定、收件地址類別，產出可選物流清單。空運違禁品透過 ① 自動連動 + Layer 2 扣除排除物流聯集自動達成，不用另外判斷。

判斷對照表（3 列，純業務層）

收件地址 消費者可選物流
本島宅配、超取 7-11、超取全家
外島宅配、超取 7-11、超取全家
海外海外配送

再套用「排除物流聯集」扣除。若結果為空 → 顯示提示，請消費者拆單／移除商品／換地址。

地址類別定義

2026-07-01 完稿：判斷表從 6 列（陸/海/空 x 地址）簡化為 3 列（只看地址）— 因為黑貓從不走空運（本島陸運、外島海運），空運議題全部歸屬「排除物流」自動連動。「收件地址定義」spec 決定不開，定義直接內嵌本份判讀說明。「郵局 vs 順豐」「海運提醒貼紙」均走 SOP，不進 spec。
Notion 頁面

4. 待寫規格清單（30 項）

依 brief v2 §7 建議寫作順序，Cluster 分組如下。下一組建議寫的：物流（黑貓相關）4 項。

C. 物流（黑貓相關）· 4 項 · ← 建議下一組
  • 物流增加黑貓（此份 2026-06-29 起草到一半，因發現需引入「收件地址」維度而擱下）row 3
  • 物流設定（黑貓）綁多個廠商客代row 2
  • 訂單綁大宗單後黑貓客代判斷（含黑貓海運／空運分流邏輯）row 4
  • 訂單貨態查詢物流商連結row 15
D. 訂單管理 · 5 項
  • 交易拆單row 10
  • 訂單管理頁面增加篩選row 12
  • 訂單自定義標籤row 11
  • 每日出貨明細報表row 48
  • 海外配送，配送編號的更新row 13
E. 金流 · 3 項
  • 未付款訂單，重新付款 20 分鐘row 7
  • 新增金流：街口支付row 8
  • 線上刷卡換中信銀行row 9
F. 退貨／發票 · 2 項
  • 退貨流程「會計執行退款」改自動row 23
  • 開立發票時點修改row 51
G. 通知 · 4 項
  • Mail 工具串接row 28
  • 官網特定情境通知信／簡訊（3 個情境）row 43-45
H. 會員／註冊 · 3 項
  • 黑名單 有範例row 54
  • Google 快速登入row 52
  • 驗證碼簡訊按鈕視覺強化 有範例row 53

有範例的 2 項可放在「零碎時間」寫，難度低。範例見 spec_template.md 中的範例 A（黑名單，中等複雜度）與範例 B（驗證碼按鈕，5 格極簡）。

I. 商品／UI · 8 項
  • 商品列表頁文字呈現調整row 25
  • 商品下架倒數計時器row 26
  • 置頂 (Pin) 功能row 55
  • 購物車滿額升等提醒row 19
  • 加入購物車按鈕滾動固定row 27
  • DPA 圖片抓取邏輯row 57
  • 獨立 SEO 設定欄位row 56
  • 全域訂單最低 100 元row 18
J. 跨平台（快電商） · 2 項
  • 超電串接 (API)row 5, 58, 59
  • 超電串接 (物流)row 6
K. 門市（Q2 上線，不急） · 1 項
  • 門市間在途調撥（庫存）row 20-22

5. 關鍵決策記錄

Review 過程中拍板的業務規則，避免重寫時忘記脈絡。

Q：排除物流選項有幾個？
A：4 個（超取 7-11 / 超取全家 / 宅配 / 海外配送），不可全部勾選
Why：翠翠 2026-06-29 貼畫面確認實際 4 選項，糾正我原本以為的 3 選項
Q：空運違禁品自動連動勾選幾項？
A：2 項（超取 7-11 / 超取全家），海外配送不勾、宅配不勾
Why：海外配送 = 假物流（人工處理），跟空運禁品是 disjoint 邏輯；宅配走陸運不會有空運問題（2026-06-30 修正）
Q：拆分結帳的群組編號範圍？
A：01-20（兩位數字串）
Why：翠翠 2026-06-29 拍板
Q：拆分後的多個結帳區塊，付款方式？
A：必須分別結算，不可合併付一次
Why：翠翠 2026-06-29「5 個購物車是必須拆分結帳的」；優惠／折扣只能套用單一區塊，不可跨區共用
Q：宅配 vs 黑貓的關係？
A：系統的「宅配」就是「黑貓」（1:1）。未來新增新竹物流等，另開獨立項目「宅配-新竹物流」，不動原黑貓項目
Why：翠翠 2026-06-29 拍板不做「物流類別」抽象層，走扁平擴充
Q：消費者看到的物流名稱？
A：消費者端 = 「宅配」；內部端（後台、出貨單）= 「黑貓」
Why：翠翠 2026-06-29「消費者只會看到宅配的文字，不會看到貓」
Q：海外配送實際走什麼 carrier？
A：港澳走順豐、其他海外走郵局。消費者端只看到「海外配送」單一選項；倉庫端依收件地址決定 carrier。系統不做 API 對接，人工處理
Why：翠翠 2026-07-01 更新（先前記為「假物流」不完全準確）
Q：本島／外島／海外的判斷規則？
A：本島 = 台灣本島；外島 = 澎湖、金門、馬祖、蘭嶼、綠島、小琉球；海外 = 上述以外。定義內嵌 Layer 2 判讀說明段（不開獨立 spec）
Why：翠翠 2026-07-01 拍板；外島含蘭嶼綠島小琉球（不只澎金馬），確保空運違禁品的邏輯 cover 所有離島空運超取路徑
Q：Layer 2 spec 要不要進 Sheet？
A：要（不然康德看不到 = 不會做），但時數 = 0，Note 標「邏輯說明用，不單獨開發」
Why：翠翠 2026-06-30 反問「不放入 sheet，康德不會照著作」讓我修正原本的立場
Q：黑貓走陸/海/空要不要進 spec？
A：不用。黑貓從不走空運（本島陸運、外島海運），系統/API 呼叫一樣，差別只在倉庫端貼紙作業
Why：翠翠 2026-07-01 從倉庫端得知實務；系統 spec 不需分流，Layer 2 對照表從 6 列簡化為 3 列
Q：海運提醒貼紙 SOP or spec？
A：SOP。倉庫看訂單收件地址（外島 + 選宅配）自己判斷要貼海運貼紙。不開發、不花錢
Why：翠翠 2026-07-01 拍板；外島訂單量倉庫熟手能處理，不值得花康德工時
Q：郵局 vs 順豐分流 SOP or spec？
A：SOP。倉庫依收件地址：港澳 → 順豐、其他 → 郵局
Why：翠翠 2026-07-01 拍板；同上，倉庫作業處理即可
Q：收件地址定義要不要開獨立 spec？
A：不開。定義只有 3 條（本島/外島/海外），內嵌 Layer 2 判讀說明段即可
Why：翠翠 2026-07-01 拍板；避免文件太碎，讀者要跳頁
Q：拆分結帳 tooltip 要不要進 spec？
A：要。UI 段列出「單獨配送」與「指定配送群組編號」旁的 (?) 圖示 + 對應說明文字
Why：翠翠 2026-07-01 看 UI mockup 有 tooltip 圖示；不寫進 spec 康德不會做
Q：規格衝突時以誰為準？
A：Notion。本地 md / R2 都是次要工作副本
Why：翠翠 2026-07-01 拍板；避免多份 source 造成不一致
Q：Website 內容同步時機？
A：晚上批次（Taipei 18:00 後）。白天寫作階段不即時 deploy，避免打斷 flow
Why：翠翠 2026-07-01 拍板；每次同步佔用回覆 turn，累積起來干擾寫作

6. 待確認事項

要跟內部確認
Canva 畫面連結

7. 寫作原則（翠翠已內化）

  1. 一個項目一份規格，不合併
  2. 卡住先標 [待確認]，不中斷思路
  3. 規格只寫自己的範圍，相關邏輯用「關聯規格」串連
  4. 不寫實作細節（DB schema、UI 框架、程式變數名、Y/N 這種格式），改用中文業務語言
  5. 規格邊界判斷：寫完問自己「廠商沒問就能照做嗎？」→ 不行就補
  6. 每份規格長短按複雜度決定：簡單 UI 微調 5 格就夠、複雜邏輯填滿 8 格
  7. 翠翠用零碎時間寫規格，一份 review 完再開下一份，不推太多
  8. 翠翠 Notion 用 bullet outline，markdown 直接貼不會自動對齊，我要給「以條為單位」的 diff 指引，不整片替換
  9. 寫規格時避免 jargon：「邊界條件／例外／異常」→「其他情況」；不用「出包」
給接手 Taco 的操作提醒

8. 相關資源與連結

核心文件

Spec 內容（canonical = Notion）

2026-07-01 翠翠拍板：規格內容以 Notion 為主（canonical）。本地 md 為工作副本，比對衝突時以 Notion 為準。

康德相關參考

相關 memory（auto-load）

寫這份 dashboard 的緣由：翠翠 2026-07-01 說「你先把專案規格作進度整理並產出 html，內容愈完整愈好，我要開一個新的 thread」。這是給下一個 thread 的接手參考。

2026-07-01 下午更新：③ ④ 全部完稿；黑貓陸/海/空、郵局/順豐、海運提醒貼紙全部走 SOP；「收件地址定義」spec 不開。詳見 §5 決策記錄。

Generated by Taco · 2026-07-01