LESSON-26 · 自主延伸
把「Apps Script form-encoded 本地測試串接」拆成 4 個可獨立完成、可重設、可驗證的自主學習 module。
成果：完成 form-encoded、雙重驗證、部署邊界與單一 JSON contract 的本地串接設計；自學頁全程 remote write=0。
需要的檔案：files/starter/index.html（整合起點，保留跨 module 的最小缺口。）
完成後：完成 form-encoded、雙重驗證、部署邊界與單一 JSON contract 的本地串接設計；自學頁全程 remote write=0。
逐項展開；答不出來時先走補救連結，不必硬做。
自我檢查：我能否開啟 Elements、Console 或 Network 並找到本頁？
每一個目標只對應一個 module；成功狀態必須能指出證據。
依序展開；每次只改一項，操作後確認該模組自己的 DOM、progress 與 evidence。
白話：前端把三個有名字的欄位排成表單字串，後端用相同名字逐格取回。
正式說法：`URLSearchParams` 產生 `application/x-www-form-urlencoded` 形式的 name/value pairs；Apps Script web app 的 event object 會將單值參數提供於 `e.parameter`。
何時使用：原生表單以 fetch 送到 Apps Script，且 doPost 使用 e.parameter 接收時。
修改前後：Before：request body 是 JSON，但 doPost 查 e.parameter.email。After：body 與接收端都使用同一組表單欄名。
常見混淆：`e.parameters` 的值是陣列，`e.parameter` 取每個參數的第一個值；本章單值表單使用後者。
情境：前端 Network 看得到 JSON body，但 Apps Script 回覆『Email 必填』。
起始狀態：三個測試欄位只存在記憶體物件，尚未編碼。
目前主題：URLSearchParams 與 e.parameter
預期：operation=encode-form、inputCount=3、remoteRequests=0，result 同時包含 name、email、message 的百分比編碼。
證據：inputCount=3、remoteRequests=0、result 含 name=、email=、message=
第一個檢查：先比較 request Content-Type/body 與 doPost 實際讀取方式是否相同。
重設：丟棄編碼 result 並恢復本地 payload；不觸碰測試或正式 deployment。
本模組官方來源：Google Apps Script｜Web Apps
白話：瀏覽器先幫使用者抓錯，伺服端再把所有資料當成不可信重新檢查；藏起來的誘餌欄有人填就拒絕。
正式說法：Defense in depth 將 UX constraint validation 與 server-side authorization/validation 分層；honeypot 是正常使用者不應填寫、用來辨識自動化提交的欄位。
何時使用：任何公開聯絡、詢價或訂閱表單。
修改前後：Before：只依 required 屬性，直接相信 request。After：UI 與 doPost 各自驗證，honeypot 非空立即拒絕。
常見混淆：Honeypot 只能降低部分機器提交，不是 CAPTCHA、rate limit 或完整安全邊界。
情境：有人直接組 request 繞過 required，或把 API key 寫在公開 app.js。
起始狀態：四組去識別測試案例已存在 DOM，尚未執行分支盤點。
目前主題：前後端雙重驗證、honeypot 與無前端秘密
預期：count=4、uniqueCount=4、valid=true，result 分別為 required、email、honeypot、accepted。
證據：count=4、uniqueCount=4、text=required｜email｜honeypot｜accepted
第一個檢查：先查看後端是否在寫入前獨立檢查每個欄位與 honeypot。
重設：清除盤點 facts；不保留任何學生輸入。
白話：/dev 是編輯者測最新版的門；/exec 是已部署版本的門。能不能進、用誰的權限，必須在部署設定確認。
正式說法：Apps Script test deployment `/dev` 僅對具編輯權限者提供最新儲存程式；versioned web app `/exec` 依部署版本、execute-as 與 access 設定執行。
何時使用：建立測試部署、交付部署 URL、排查 401/403 或 event parameter 異常。
修改前後：Before：把兩種 URL 混用並猜測權限。After：在部署紀錄明確標示用途、版本、execute-as、access。
常見混淆：`/dev` 不是 staging 主機，也不是可以公開分享的正式 URL。
情境：講師可以用 /dev，學生打開同一網址卻看到未授權；表單又帶了保留欄名 sid。
起始狀態：本地規則表已列出三種情況，沒有真實 deployment URL。
目前主題：/dev、/exec、部署權限與保留參數
| 僅編輯者測試最新程式 |
| 已部署版本與核准 access |
| 欄位避免 c 與 sid |
預期：count=3、uniqueCount=3、valid=true，三筆 kind 為 dev、exec、reserved。
證據：count=3、uniqueCount=3、text=dev｜exec｜reserved；本 action 無 Network request
第一個檢查：先看 URL 結尾，再查部署設定的 execute-as 與 access，而不是反覆重送。
重設：清除規則 facts；不變更任何 Apps Script 部署與權限。
本模組官方來源：Google Apps Script｜Web Apps
白話：不管成功失敗都用同一個盒子回答；真正連線時記得內容可能先被轉到一次性網址。
正式說法：Response contract 定義可預期 JSON shape；Apps Script ContentService 內容會重新導向至 `script.googleusercontent.com`，HTTP client 必須跟隨 redirect。
何時使用：doPost 回傳 JSON、前端分類 success/error，以及以 Network 排查 ContentService。
修改前後：Before：成功回字串、錯誤回 HTML。After：兩者皆為 JSON，差異只在 ok 與可選 error。
常見混淆：HTTP redirect 是傳輸路徑；`ok` 是應用程式結果，不能只靠 200 判斷提交成功。
情境：Network 最終得到 200，但 JSON 的 ok=false，介面卻顯示送出成功。
起始狀態：兩筆去識別 response fixture 已存在，尚未核對 schema。
目前主題：ContentService redirect 與單一 JSON 契約
{"ok":true,"message":"已收到"}{"ok":false,"message":"請檢查欄位","error":"INVALID_EMAIL"}預期：count=2、uniqueCount=2、valid=true，兩筆 schema 為 ok-message 與 ok-message-error。
證據：count=2、uniqueCount=2、text=ok-message｜ok-message-error；沒有外部 request
第一個檢查：先分開檢查 HTTP 狀態、final URL、JSON parse、body.ok 四層。
重設：清除 schema facts；不保留 response 或呼叫正式服務。
情境：在同一份章節作品中整合 4 個 module，排除單項通過但組合失敗的問題。
交付：完成 form-encoded、雙重驗證、部署邊界與單一 JSON contract 的本地串接設計；自學頁全程 remote write=0。
檔案：files/starter/index.html 定位：#observe
操作：逐項讀取 outcomes，執行一次現況操作。
// OBSERVE：不修改程式，先記錄第一個失敗 moduleId。預期：能指出第一個未通過 module。
證據：第一個 moduleId 與缺少的 evidence。
原因：先觀察可避免未重現就直接改答案。
卡住先查：確認開啟的是 files/starter/index.html。
檔案：files/starter/index.html 定位：#modify
操作：在本地把三欄 payload 編碼，讀取 result 並確認沒有任何遠端 request。 → 讀取四個本地案例的 data-result，確認每條驗證分支都有唯一、可辨識結果。 → 讀取三筆本地部署規則的 data-kind，確認 dev、exec、reserved 各自只有一筆。 → 讀取兩筆本地 response schema，確認共用 ok/message，只有失敗案例包含 error。
// 26-01-urlsearchparams-e-parameter: 在本地把三欄 payload 編碼，讀取 result 並確認沒有任何遠端 request。
// 26-02-honeypot: 讀取四個本地案例的 data-result，確認每條驗證分支都有唯一、可辨識結果。
// 26-03-dev-exec: 讀取三筆本地部署規則的 data-kind，確認 dev、exec、reserved 各自只有一筆。
// 26-04-contentservice-redirect-json: 讀取兩筆本地 response schema，確認共用 ok/message，只有失敗案例包含 error。預期：完成 form-encoded、雙重驗證、部署邊界與單一 JSON contract 的本地串接設計；自學頁全程 remote write=0。
證據：inputCount=3、remoteRequests=0、result 含 name=、email=、message=；count=4、uniqueCount=4、text=required｜email｜honeypot｜accepted；count=3、uniqueCount=3、text=dev｜exec｜reserved；本 action 無 Network request；count=2、uniqueCount=2、text=ok-message｜ok-message-error；沒有外部 request
原因：逐項整合能把回歸定位到明確 module。
卡住先查：回到第一個未通過的 module，只修該處。
檔案：files/solution/index.html 定位：#verify
操作：重新整理並依 outcomes 順序重跑所有證據。
// VERIFY：逐項記錄 pass/fail，不以看到畫面代替 evidence。預期：4/4 module 通過。
證據：每個 moduleId 都有實際結果與重設後重現紀錄。
原因：單項通過不代表整合後沒有 selector、id 或狀態衝突。
卡住先查：若失敗，回到第一個失敗 module，不同時修多項。
檔案：files/starter/index.html 定位：#challenge
操作：替另一個商家情境重做，仍達成：完成 form-encoded、雙重驗證、部署邊界與單一 JSON contract 的本地串接設計；自學頁全程 remote write=0。
// CHALLENGE：只替換內容與資料，不新增框架或跳過 self-check。預期：完成 form-encoded、雙重驗證、部署邊界與單一 JSON contract 的本地串接設計；自學頁全程 remote write=0。
證據：轉用後的作品與全數 module self-check。
原因：能轉用才代表理解責任，而非只記住原範例。
卡住先查：先確認共同基底與 module id 未被改壞。
重設方法：重新載入 files/starter/index.html；若 localStorage 不可用，使用頁面內記憶狀態並提供重設按鈕。
挑戰：將同一組責任轉用到另一個商家情境，仍達成：完成 form-encoded、雙重驗證、部署邊界與單一 JSON contract 的本地串接設計；自學頁全程 remote write=0。
限制：不新增框架。；保留 module id 與驗收證據。
提交證據：提交可直接開啟的作品與逐項 self-check。
拆小：在「Apps Script form-encoded 本地測試串接」先完成第一個尚未通過的 module：URLSearchParams 與 e.parameter，不同時修改其他責任。
串接：依 26-01-urlsearchparams-e-parameter → 26-02-honeypot → 26-03-dev-exec → 26-04-contentservice-redirect-json 核對各自輸入與證據。
完整解答與原因：依序執行 在本地把三欄 payload 編碼，讀取 result 並確認沒有任何遠端 request。 → 讀取四個本地案例的 data-result，確認每條驗證分支都有唯一、可辨識結果。 → 讀取三筆本地部署規則的 data-kind，確認 dev、exec、reserved 各自只有一筆。 → 讀取兩筆本地 response schema，確認共用 ok/message，只有失敗案例包含 error。；這個順序能把每個結果對回單一 module，避免整合後無法定位。
完整解答預設收合；先留下自己的嘗試，再開第三層。