LESSON-23｜定義運動器材電商需求、資料模型與驗收矩陣

先理解：這堂課解決什麼問題？

第 23–28 章共用同一個 project/e-commerce；本堂先固定頁面、使用者任務、商品／訂單／聯絡資料欄位與逐章驗收證據，只做規劃，不寫 fetch、不連 GAS／Sheet、不部署。

本堂要完成：完成運動器材電商 brief、六頁 sitemap、三組完整資料模型與 L23–L28 驗收矩陣；Products 私有六欄、商品 GET 公開五欄，訂單與聯絡資料覆蓋需求的全部欄位。

學習邊界：先完成「定義運動器材電商需求、資料模型與驗收矩陣」，不提前引入尚未教過的框架或建置工具。

先備知識與操作環境

延續上一章的鐵刻運動電商成果。本章只增加定義運動器材電商需求、資料模型與驗收矩陣的責任；先開啟 examples/minimal.html，再依 Starter → Checkpoint → Solution 留下檔案、操作、預期與實際證據。

檔案位置：先找到 project/e-commerce/project-brief.md、project/e-commerce/data-contract.md、project/e-commerce/acceptance-matrix.md、project/e-commerce/evidence.md，再從本頁的最小實驗開始。
瀏覽器：開啟最小實驗與階段頁；每次修改後儲存並重新整理。
DevTools：依本堂內容使用 Elements、Styles、Computed、Console 或 Network，記下第一個可觀察證據。
操作習慣：每次只修改一個檔案或一個責任，先預測、再操作、最後驗收。

先做最小實驗：先看見結果

這不是期末網站，而是一個可以直接看到本堂核心結果的最小實驗。先完成一次操作，再回到檔案和名詞卡對照。

開啟本堂最小實驗

入口：開啟 examples/minimal.html。
操作：開啟本章最小實驗，按下執行按鈕，再比對畫面、Elements、Console 與 390px；不得把 local mock 當成真實 Sheet 成功。
預期：只呈現 L23 在鐵刻運動連續專案新增的責任，且能指出上一章輸入與下一章交付。
重設：重新整理 examples/minimal.html；本章最小實驗不送正式資料、不部署。

學生練習流程

依序完成每一張卡；目前只聚焦一個步驟，先操作，再用可觀察證據確認結果。

1
最小實驗

先閱讀本頁的問題、檔案地圖、名詞卡與最小例子。
2
Step 2

自己回答互動問答 4 題，再展開解析。
3
最小實驗 2

開啟最小實驗，實際操作一次並記下證據。
4
Starter

把 Starter 複製到自己的工作資料夾，照 4 張微步驟卡逐一完成；每一步都要看到結果再繼續。
5
Checkpoint

前往 Checkpoint，只處理 1 個本堂核心缺口；先預測，再用指定證據驗收。
6
Solution

前往 Solution，先看逐檔差異與修改原因，再決定要不要把完整內容帶回自己的檔案。
7
變體驗收

完成情境變體與獨立挑戰，留下檔案位置、操作、結果與驗收證據，並閱讀下一堂銜接：品牌 shell：下一堂依 brief 建立黃色與鐵灰的共用外框、首頁與商品入口。

檔案地圖：每個位置負責什麼？

先不要急著背檔名；請把檔案位置和責任連起來。你在階段頁會看到同一份檔案的可執行版本。

project-brief.md專案規劃契約：定義電商角色、頁面、資料模型、資料流與驗收邊界。
evidence.md逐章驗收紀錄：保存操作、預期、實際結果與未完成邊界。
index.html鐵刻運動電商頁面或發佈檔案。

先學會這些詞

先從名詞、英文與白話意思開始；每次只展開一張名詞卡，再對照正式定義、範例與驗收證據。專業術語、語法、檔案路徑會使用不同樣式。第一次遇到術語時，先回到這裡，不要靠猜。

本堂 10 個詞先選一組，再展開需要的名詞卡；每次只保留目前的學習焦點。

project briefproject brief 白話意思：用來理解「project brief」的實務概念。展開查看正式定義、範例與驗收證據

正式定義: 本章將 project brief 定義為可在檔案、畫面或 DevTools 中驗證的技術責任。
什麼時候用: 實作 project brief 或排查相關問題時。
最小範例: project brief
可觀察證據: 能在專章範例指出 project brief 的操作結果。
容易混淆: 只記名稱卻沒有實際操作或驗收證據。

六頁 sitemap六頁 sitemap 白話意思：用來理解「六頁 sitemap」的實務概念。展開查看正式定義、範例與驗收證據

正式定義: 本章將六頁 sitemap 定義為可在檔案、畫面或 DevTools 中驗證的技術責任。
什麼時候用: 實作六頁 sitemap 或排查相關問題時。
最小範例: 六頁 sitemap
可觀察證據: 能在專章範例指出六頁 sitemap 的操作結果。
容易混淆: 只記名稱卻沒有實際操作或驗收證據。

user taskuser task 白話意思：用來理解「user task」的實務概念。展開查看正式定義、範例與驗收證據

正式定義: 本章將 user task 定義為可在檔案、畫面或 DevTools 中驗證的技術責任。
什麼時候用: 實作 user task 或排查相關問題時。
最小範例: user task
可觀察證據: 能在專章範例指出 user task 的操作結果。
容易混淆: 只記名稱卻沒有實際操作或驗收證據。

L23–L28 scope boundaryL23–L28 scope boundary 白話意思：用來理解「L23–L28 scope boundary」的實務概念。展開查看正式定義、範例與驗收證據

正式定義: 本章將 L23–L28 scope boundary 定義為可在檔案、畫面或 DevTools 中驗證的技術責任。
什麼時候用: 實作 L23–L28 scope boundary 或排查相關問題時。
最小範例: L23–L28 scope boundary
可觀察證據: 能在專章範例指出 L23–L28 scope boundary 的操作結果。
容易混淆: 只記名稱卻沒有實際操作或驗收證據。

Product／Order／Contact modelProduct／Order／Contact model 白話意思：用來理解「Product／Order／Contact model」的實務概念。展開查看正式定義、範例與驗收證據

正式定義: 本章將 Product／Order／Contact model 定義為可在檔案、畫面或 DevTools 中驗證的技術責任。
什麼時候用: 實作 Product／Order／Contact model 或排查相關問題時。
最小範例: Product／Order／Contact model
可觀察證據: 能在專章範例指出 Product／Order／Contact model 的操作結果。
容易混淆: 只記名稱卻沒有實際操作或驗收證據。

Products 私有六欄／公開五欄Products 私有六欄／公開五欄 白話意思：用來理解「Products 私有六欄／公開五欄」的實務概念。展開查看正式定義、範例與驗收證據

正式定義: 本章將 Products 私有六欄／公開五欄定義為可在檔案、畫面或 DevTools 中驗證的技術責任。
什麼時候用: 實作 Products 私有六欄／公開五欄或排查相關問題時。
最小範例: Products 私有六欄／公開五欄
可觀察證據: 能在專章範例指出 Products 私有六欄／公開五欄的操作結果。
容易混淆: 只記名稱卻沒有實際操作或驗收證據。

productId／submissionId／orderNoproductId／submissionId／orderNo 白話意思：用來理解「productId／submissionId／orderNo」的實務概念。展開查看正式定義、範例與驗收證據

正式定義: 本章將 productId／submissionId／orderNo 定義為可在檔案、畫面或 DevTools 中驗證的技術責任。
什麼時候用: 實作 productId／submissionId／orderNo 或排查相關問題時。
最小範例: productId／submissionId／orderNo
可觀察證據: 能在專章範例指出 productId／submissionId／orderNo 的操作結果。
容易混淆: 只記名稱卻沒有實際操作或驗收證據。

requirement IDrequirement ID 白話意思：用來理解「requirement ID」的實務概念。展開查看正式定義、範例與驗收證據

正式定義: 本章將 requirement ID 定義為可在檔案、畫面或 DevTools 中驗證的技術責任。
什麼時候用: 實作 requirement ID 或排查相關問題時。
最小範例: requirement ID
可觀察證據: 能在專章範例指出 requirement ID 的操作結果。
容易混淆: 只記名稱卻沒有實際操作或驗收證據。

acceptance matrixacceptance matrix 白話意思：用來理解「acceptance matrix」的實務概念。展開查看正式定義、範例與驗收證據

正式定義: 本章將 acceptance matrix 定義為可在檔案、畫面或 DevTools 中驗證的技術責任。
什麼時候用: 實作 acceptance matrix 或排查相關問題時。
最小範例: acceptance matrix
可觀察證據: 能在專章範例指出 acceptance matrix 的操作結果。
容易混淆: 只記名稱卻沒有實際操作或驗收證據。

expected／evidenceexpected／evidence 白話意思：用來理解「expected／evidence」的實務概念。展開查看正式定義、範例與驗收證據

正式定義: 本章將 expected／evidence 定義為可在檔案、畫面或 DevTools 中驗證的技術責任。
什麼時候用: 實作 expected／evidence 或排查相關問題時。
最小範例: expected／evidence
可觀察證據: 能在專章範例指出 expected／evidence 的操作結果。
容易混淆: 只記名稱卻沒有實際操作或驗收證據。

最小例子：先看懂，再複製

這段只保留本堂第一個微成果。先預測結果，再逐行讀；完整檔案請開啟下方最小實驗。

| 頁面 | 檔名 | 責任 |
| 首頁 | index.html | 建立品牌與商品入口 |
| 商品 | products.html | 比較商品與特價 |
| 購物車 | cart.html | 調整品項與數量 |
| 結帳 | checkout.html | 收集購買人資料 |
| 完成 | order-success.html | 顯示訂單編號與狀態 |
| 聯絡 | contact.html | 收集聯絡內容 |

Live Lab：逐段讀碼與驗證

每一步只回答五件事：為什麼做、改哪裡、會看到什麼、用什麼證據確認、卡住先查什麼。

Step 1
定義首頁、商品、購物車、結帳、訂單完成與聯絡六頁責任，並列出 L23–L28 各章唯一交付

目的
先固定連續專案範圍，避免後續章節重做或提前串接。

修改位置
project-brief.md
定義首頁、商品、購物車、結帳、訂單完成與聯絡六頁責任，並列出 L23–L28 各章唯一交付

預期結果
六頁各有檔名、責任與主要行動；L25 明示零 fetch/GAS/Sheet，L28 明示不部署。

驗收證據
project-brief.md 的六列 sitemap 與六章 scope 表。

卡住先查
先逐列確認六個檔名，再檢查 L25 與 L28 的禁止事項。
Step 2
定義私有 Product 的 productId、name、image、price、salePrice、active，並另列商品 GET 公開五欄

目的
Products Sheet 與本地 mock 使用私有六欄；GAS 以 active 過濾後，公開回應只輸出 productId/name/image/price/salePrice。

修改位置
data-contract.md
定義私有 Product 的 productId、name、image、price、salePrice、active，並另列商品 GET 公開五欄

預期結果
私有六欄完整；公開五欄不含 active；名稱、圖片、售價、特價皆有穩定 key。

驗收證據
data-contract.md 的 private/public 對照表與一筆運動器材範例。

卡住先查
先數 private=6、public=5，再確認 active 只用於伺服器端過濾。
Step 3
定義訂單與聯絡完整欄位，並標示前端輸入、GAS 產生或 GAS 計算

目的
欄位 ownership 不清會讓前端偽造金額、後端漏存資料或 Sheet 錯欄。

修改位置
data-contract.md
定義訂單與聯絡完整欄位，並標示前端輸入、GAS 產生或 GAS 計算

預期結果
訂單 10 個使用者必備欄為編號、購買人、性別、電話、地址、信箱、商品總額、運費、訂單總額、狀態；聯絡 5 個必備欄為姓名、性別、電話、信箱、內容；submissionId、timestamp、itemsJson 另列為技術欄位。

驗收證據
data-contract.md 三張欄位表的需求勾選、技術欄位區分與 owner 欄。

卡住先查
先逐字對照訂單 10 個使用者必備欄與聯絡 5 個必備欄，再另核對 submissionId、timestamp、itemsJson 技術欄位。
Step 4
建立需求 ID、章節、責任檔案、操作、預期與證據位置矩陣

目的
每一個需求都要能在第 28 章回查，不以『看起來完成』取代驗收。

修改位置
acceptance-matrix.md
建立需求 ID、章節、責任檔案、操作、預期與證據位置矩陣

預期結果
商品、訂單、聯絡、品牌色、GAS 與不部署邊界都至少有一列可重現證據。

驗收證據
acceptance-matrix.md 每列都有 requirement、lesson、file、expected、evidence。

卡住先查
任選 REQ-ORDER-TOTAL，確認能一路追到 L27 GAS 計價與 Sheet 證據。
Step 5
補回遺漏的 salePrice 欄位與需求映射

目的
Checkpoint 只修一個資料契約缺口，證明特價不會在實作時失去來源。

修改位置
data-contract.md
補回遺漏的 salePrice 欄位與需求映射

預期結果
Product 表同時包含 price 與 salePrice，REQ-PRODUCT-SALE 可追到此列。

驗收證據
data-contract.md 的 Product 表、acceptance-matrix.md 的 REQ-PRODUCT-SALE。

卡住先查
只看 Product 表，確認 price 與 salePrice 是兩個不同欄位。
Step 6
專章驗收：Product 資料模型

目的
將概念轉成可重現的實作證據。

修改位置
examples/minimal.html 與對應 stage files
操作 Product 資料模型並記錄結果。

預期結果
能展示 Product 資料模型的畫面、DOM、Console 或 Network 證據。

驗收證據
檔案位置、操作、預期、實際與重新驗證。

卡住先查
只重做一個最小操作並查看第一個錯誤。

操作層級Live Lab 段落導覽：切換六個實驗步驟

讀碼順序：先找入口，再找被引用的檔案，最後用畫面、DOM、Console、Network 或資料結果驗證。

互動問答

先回答目前這一題，再展開解析；完成後按下一題，讓每一次回答都回到檔案或瀏覽器完成驗證。

Q1概念理解「project brief」在本堂要解決什麼問題？本題線索：project brief；回到名詞卡與能在專章範例指出 project brief 的操作結果。展開解析收合解析

白話解析：

用來理解「project brief」的實務概念。正式來說，本章將 project brief 定義為可在檔案、畫面或 DevTools 中驗證的技術責任。

對照位置：

回到名詞卡「project brief」，再看能在專章範例指出 project brief 的操作結果。

預期觀察：

你應該能用自己的話說出：實作 project brief 或排查相關問題時。

常見錯誤：

不要只回答「它是project brief」；那是重複名詞，不是說明責任。

立即驗證：

開啟 examples/minimal.html，依序做「開啟本章最小實驗，按下執行按鈕，再比對畫面、Elements、Console 與 390px；不得把 local mock 當成真實 Sheet 成功。」並記下畫面或工具證據。

Q2程式碼閱讀修改指定規則後，你預測畫面會看到什麼？本題線索：project-brief.md；要修改：定義首頁、商品、購物車、結帳、訂單完成與聯絡六頁責任，並列出 L23–L28 各章唯一交付；觀察：project-brief.md 的六列 sitemap 與六章 scope 表。展開解析收合解析

白話解析：

先看檔案責任，再預測結果。這一步的目的：先固定連續專案範圍，避免後續章節重做或提前串接。

對照位置：

對照 Live Lab Step 1，位置是 project-brief.md；範例內容：| 頁面 | 檔名 | 責任 | | 首頁 | index.html | 建立品牌與商品入口 | | 商品 | products.html | 比較商品與特價 | | 購物車 | cart.html | 調整品項與數量 | | 結帳 | checkout.html | 收集購買人資料 | | 完成 | order-success.html | 顯示訂單編號與狀態 | | 聯絡 | contact.html | 收集聯絡內容 |

預期觀察：

六頁各有檔名、責任與主要行動；L25 明示零 fetch/GAS/Sheet，L28 明示不部署。

常見錯誤：

如果只改了檔案但沒有結果，先不要重寫全部；先逐列確認六個檔名，再檢查 L25 與 L28 的禁止事項。

立即驗證：

實際操作後檢查 project-brief.md 的六列 sitemap 與六章 scope 表。。

Q3概念比較「project brief」和「六頁 sitemap」在本堂的責任有什麼不同？本題線索：比較 project brief 與六頁 sitemap；操作位置：data-contract.md 展開解析收合解析

白話解析：

project brief：用來理解「project brief」的實務概念。；六頁 sitemap：用來理解「六頁 sitemap」的實務概念。

對照位置：

對照兩張名詞卡的正式定義：本章將 project brief 定義為可在檔案、畫面或 DevTools 中驗證的技術責任。／本章將六頁 sitemap 定義為可在檔案、畫面或 DevTools 中驗證的技術責任。

預期觀察：

你應該能指出兩者分別出現在哪個檔案或工具，以及哪一個結果會改變。

常見錯誤：

不要把「改變畫面」當成所有技術的責任；先說清楚誰負責結構、呈現、行為或驗收。

立即驗證：

在 data-contract.md 做「定義私有 Product 的 productId、name、image、price、salePrice、active，並另列商品 GET 公開五欄」，再用 data-contract.md 的 private/public 對照表與一筆運動器材範例。比較前後差異。

Q4除錯驗收如果完成操作後結果不對，你會先從哪一個證據開始查？本題線索：examples/minimal.html 與對應 stage files；第一個檢查位置：檔案位置、操作、預期、實際與重新驗證。展開解析收合解析

白話解析：

先描述症狀，再提出一個最小假設。本堂常見錯誤是：只口頭說明完成。

對照位置：

對照最後一段 Live Lab：examples/minimal.html 與對應 stage files；檢查方式：只重做一個最小操作並查看第一個錯誤。

預期觀察：

你要能指出一個具體位置，而不是一次修改很多檔案。

常見錯誤：

不要先清快取、重裝工具或複製 Solution；先查看第一個可觀察錯誤。

立即驗證：

重新操作並留下「症狀、證據、假設、單一修正、結果」五項紀錄。

常見誤解

看到畫面沒有變化，不代表程式沒執行；先確認檔案、路徑、元素與狀態證據。
能複製 Solution 不代表理解；請先說出修改哪個檔案、預期哪個結果、用什麼證據確認。
本堂只使用 Markdown、HTML、CSS、JavaScript 與瀏覽器 DevTools；不建立真正四頁、不連外部服務、不加入框架或部署工具，先完成 planning-only project brief。

本堂任務與驗收

完成運動器材電商 brief、六頁 sitemap、三組完整資料模型與 L23–L28 驗收矩陣；Products 私有六欄、商品 GET 公開五欄，訂單與聯絡資料覆蓋需求的全部欄位。

能用六頁 sitemap 留下可重現證據。
能用 Products 私有六欄／公開五欄留下可重現證據。
能用訂單／聯絡完整欄位留下可重現證據。
能用 L23–L28 scope 留下可重現證據。
能用 requirement-to-evidence matrix 留下可重現證據。
Starter、Checkpoint、Solution 的入口都能開啟並知道三者差異。
遇到問題時能先寫出症狀，再檢查一個最小假設。

官方延伸閱讀

正式延伸｜自主學習

把「運動器材電商需求、資料模型與驗收矩陣」拆成 4 個可獨立完成、可重設、可驗證的自主學習 module。

開啟自主學習入口｜4 個獨立 topic

你會怎麼做

先選一個 topic，讀懂成果、檔案與定位。
在自己的 Starter 檔案修改一小段。
重新載入，用畫面、Elements、Computed、Console 或文件留下證據。

建議第一個 topic：六頁 Sitemap 與章節邊界。

Learning map

六頁 Sitemap 與章節邊界｜content-model｜files/starter/project-brief.md｜count=6、uniqueCount=6、valid=true
Product 資料模型｜content-model｜files/starter/data-contract.md｜count=6、uniqueCount=6、valid=true；L26 公開 count=5
Order 與 Contact 資料模型｜content-model｜files/starter/data-contract.md｜count=15、uniqueCount=15、valid=true
需求到證據矩陣｜content-model｜files/starter/acceptance-matrix.md｜count=6、uniqueCount=6、valid=true

定義運動器材電商需求、資料模型與驗收矩陣

先理解：這堂課解決什麼問題？

先備知識與操作環境

先做最小實驗：先看見結果

學生練習流程

最小實驗

Step 2

最小實驗 2

Starter

Checkpoint

Solution

變體驗收

檔案地圖：每個位置負責什麼？

先學會這些詞

最小例子：先看懂，再複製

Live Lab：逐段讀碼與驗證

定義首頁、商品、購物車、結帳、訂單完成與聯絡六頁責任，並列出 L23–L28 各章唯一交付

定義私有 Product 的 productId、name、image、price、salePrice、active，並另列商品 GET 公開五欄

定義訂單與聯絡完整欄位，並標示前端輸入、GAS 產生或 GAS 計算

建立需求 ID、章節、責任檔案、操作、預期與證據位置矩陣

補回遺漏的 salePrice 欄位與需求映射

專章驗收：Product 資料模型

互動問答

白話解析：

對照位置：

預期觀察：

常見錯誤：

立即驗證：

白話解析：

對照位置：

預期觀察：

常見錯誤：

立即驗證：

白話解析：

對照位置：

預期觀察：

常見錯誤：

立即驗證：

白話解析：

對照位置：

預期觀察：

常見錯誤：

立即驗證：

常見誤解

本堂任務與驗收

官方延伸閱讀

正式延伸｜自主學習

Learning map