# 30 顆植入缺陷的驗證溯源

**研究者／評審專用，不可提供給測試 worker、raw docs、Tuco skill 或 harness。**
草稿 2026-09-20。

`rules/BS.json`、`rules/PS.json` 每一列都有 `"verified": true`。那是一個光禿禿的布林值，
沒有說**什麼時候**、在**哪個快照**、用**什麼方法**驗證的，也沒有說證據在哪裡。
這份文件補上那些欄位，讓拿到本 repo 的人能自己判斷每一顆「已驗證」的強度。

**不修改任何被 `IMPORT-MANIFEST.json` 以 sha256 釘住的檔案**，所以用新檔而不是改 rules JSON
或 GOLD 檔。`GOLD-BS-15.md`、`GOLD-PS-15.md`、`rules/BS.json`、`rules/PS.json`、
`GRADING-PROMPT.md`、`README.md` 六個檔案的匯入雜湊記在 manifest 的 `files` 裡，
是「本套件的答案卷與研究 repo 的 gold 同源」這條來源鏈的憑據。**本次不動它們任何一個。**

**其中一個檔案有匯入後的修改，這裡直接講清楚。**六個檔案目前**五個**的內容與匯入紀錄逐位元相符；
`GRADING-PROMPT.md` 在匯入之後被 commit `2cbb0bf`（2026-09-20）加了**兩行**給評分者的圍欄指示
（禁止讀已發表結果、禁止讀其他評分者的輸出）。manifest 的 `files` **刻意保留匯入當時的原值，
一個字不動**；落差記在同一份 manifest 的頂層欄位 `post_import_modifications`，
那裡同時列出**匯入當時**與**現行檔案**兩個雜湊，所以「匯入當下的來源鏈」與「你現在手上的檔案」
可以分開核對。

**所以正確的預期是：六個檔案裡五個與 `files` 相符，評分提示詞一個不符。**
六個全部相符才是異常。

**本文件的路徑基準**：答案卷的檔名與 `rules/…` 相對於 `answer-key/`；
`IMPORT-MANIFEST.json`、`bench.sh`、`dut/…`、`arms/…` 相對於**本 repo 根目錄**，指令也從根目錄執行。
第 2 節的 A／B／C／D 證據檔名相對於各自的研究稽核目錄，**那些目錄未隨本套件出貨**。
另外還會出現網站路由（以起站後的站台網址為基底）與容器內路徑（以 `/` 開頭），依上下文分辨。

---

## 0. 先講三件最重要的事

1. **答案卷 `GOLD-*.md` 表格裡的 `How verified` / `Verified` 欄，全部是 2026-08-31 植入當天的紀錄，
   用的是舊的 fixture 種子。**那批種子在 2026-09-13 被整批換成一般業務內容（見 `REPAIR-V1-NAMES.md`）。
   **改種子之後的驗證紀錄不在答案卷裡**，在研究 repo 的稽核目錄，本文件第 3 節逐顆列出。
2. **「直接觀察」與「by construction 推定」是兩種強度，本文件分開標，不混寫。**
   30 顆裡只有 **5 顆**是在本套件實際使用的 0916 快照上直接觸發到的，其餘 **25 顆**的改種子後觸發紀錄
   是在另一個環境（研究 repo 的 parallel-workflow 快照）取得的，轉移到本套件靠的是推定，不是觀察。
   推定的依據見第 4 節。
3. **這些稽核紀錄不隨本套件出貨。**理由與評審能做什麼，見第 7 節。文件不假裝你打得開它們。

---

## 1. 兩種證據強度的定義

| 標籤 | 意思 |
|---|---|
| **直接觀察（0916 快照）** | 在**本套件的受測物**上實際送出請求、實際看到症狀、再重讀資料庫或頁面確認。快照來自 `bench.sh up`（`dut/bench-dut.sh prepare`）產生的狀態，也就是四批實驗真正跑的那一個。 |
| **直接觀察（研究環境快照）** | 在改種子後的受測物上實際觸發到，但那是**研究 repo 的 parallel-workflow 環境**（不同的 compose project、不同的埠、不同的資料庫容器），不是本套件的 0916 快照。 |
| **by construction 推定** | 沒有在本套件的 0916 快照上直接觀察過。依據是「兩邊的缺陷覆蓋檔、初始備份與 seed 腳本相同，所以同一個症狀應該也成立」。**這是推論，不是觀察。** |

本文件第 3 節每一列同時給「最強的一筆直接觀察」和「對本套件而言是觀察還是推定」。
**25 顆對本套件是 by construction 推定**——它們在研究環境上被實際觸發過，但沒有人在 0916 快照上再測一次。

**沒有任何一顆是「連 by construction 的依據都沒有」的**（盤查見第 6 節）。

---

## 2. 四份改種子後的驗證紀錄（全部在研究 repo，未隨本套件出貨）

| 代號 | 目錄 | 日期 | 範圍與結果 | 環境 |
|---|---|---|---|---|
| **A** | `research/audits/20260913-defect-reverify/` | 2026-09-13 | 改種子後的全面重驗，**27/30 實際觸發**（BookStack 15/15、PrestaShop 12/15）。未觸發的 3 顆是驗證程式沒能驅動後台表單，不是缺陷消失 | 研究環境：BookStack slot b、PrestaShop slot a |
| **B** | `research/audits/20260913-ps-defect-diagnosis/` | 2026-09-13 | 補做 A 沒觸發的那 3 顆 PrestaShop，**3/3 觸發成功**，並記錄 A 的驗證程式為何失敗 | 研究環境：PrestaShop slot a |
| **C** | `research/audits/20260913-ps-slotb-reverify/` | 2026-09-13 | 6 顆 PrestaShop 在**另一個槽**獨立再測一次，**6/6 觸發成功**；同時發現舊驗證腳本有兩個會把 harness 失敗誤報成「缺陷不存在」的缺陷 | 研究環境：PrestaShop slot b |
| **D** | `research/audits/20260920-defect-retrigger/` | 2026-09-20 | **唯一在本套件 0916 快照上取得的紀錄**：5 顆 PrestaShop 全部觸發成功，每顆三層證據（HTTP 狀態／導向、頁面大小＋標題、資料庫或頁面重讀） | **本套件的 0916 快照，slot a** |

### `20260913-review-fixes/VALIDATION.json` 記錄修復驗證，不足以證明 30 顆缺陷已重現

`REPAIR-V1-NAMES.md` 的原文曾以
`research/audits/20260913-review-fixes/VALIDATION.json`（研究 repo，不隨本套件出貨）
作為「本輪實際驗證與剩餘項目」的指標。

**那個引用適用於 seed／流程修復的驗證與限制，不能延伸解讀為 30 顆缺陷的實際重現證據。**
那份檔案記的是 seed 修復的回歸測試、裁決測試、存取守衛、四槽併發還原、覆蓋檔檢查、
殘留標記掃描與檔案雜湊盤點——這些它確實做了，也確實記了剩餘限制。
但它自己的 `limitations` 第二條明寫：

> No complete UI/OCR/export survey or actual 30-defect reproduction.

它也記著 `formal_comparison_ready: false`；那是**當時正式比較的就緒狀態**，不是逐顆缺陷的驗證結論。

**若拿這份檔案作為「30 顆缺陷已實際重現」的依據，就是錯誤引用。**
逐顆缺陷的觸發溯源另見本文件；改種子後的實際觸發紀錄是上表的 A／B／C／D 四份。

---

## 3. 逐顆溯源

「本套件強度」欄：**直接觀察**＝在 0916 快照上實際測到；**推定**＝只有研究環境的觸發紀錄。
「證據出貨」欄全部是**否**，理由見第 7 節。

### BookStack 15 顆

改種子換掉的是 BookStack 的**全部**內容物件（書／章／頁／標籤／附件／Viewer 帳號），
所以 15 顆全部在紀錄 A 裡被重新觸發過一次。**沒有任何一顆在本套件的 0916 快照上再測過。**

| ID | 驗證日期 | 所在快照 | 方法 | 本套件強度 | 證據紀錄位置 | 證據出貨 |
|---|---|---|---|---|---|---|
| BS-E1 | 2026-09-13 | 研究環境 BookStack slot b | 原生 HTTP 送出＋狀態碼 | **推定** | A `SUMMARY.json` `results.BS-E1` | 否 |
| BS-E2 | 2026-09-13 | 研究環境 BookStack slot b | 登入後 GET，檢查頁面元素 | **推定** | A `SUMMARY.json` `results.BS-E2` | 否 |
| BS-E3 | 2026-09-13 | 研究環境 BookStack slot b | 原生 HTTP 送出＋狀態碼 | **推定** | A `SUMMARY.json` `results.BS-E3` | 否 |
| BS-E4 | 2026-09-13 | 研究環境 BookStack slot b | 登入後 GET，逐格式比對狀態碼 | **推定** | A `SUMMARY.json` `results.BS-E4` | 否 |
| BS-E5 | 2026-09-13 | 研究環境 BookStack slot b | 登入後 GET，狀態碼 | **推定** | A `SUMMARY.json` `results.BS-E5` | 否 |
| BS-M1 | 2026-09-13 | 研究環境 BookStack slot b | HTTP 送出＋**資料庫重讀**＋重讀頁面 | **推定** | A `SUMMARY.json` `results.BS-M1` | 否 |
| BS-M2 | 2026-09-13 | 研究環境 BookStack slot b | HTTP 送出＋**資料庫重讀** | **推定** | A `SUMMARY.json` `results.BS-M2` | 否 |
| BS-M3 | 2026-09-13 | 研究環境 BookStack slot b | HTTP 送出＋**資料庫重讀** | **推定** | A `SUMMARY.json` `results.BS-M3` | 否 |
| BS-M4 | 2026-09-13 | 研究環境 BookStack slot b | HTTP GET＋回應標頭與長度 | **推定** | A `SUMMARY.json` `results.BS-M4` | 否 |
| BS-M5 | 2026-09-13 | 研究環境 BookStack slot b | HTTP 送出＋**資料庫重讀**＋重讀頁面指定區塊 | **推定** | A `SUMMARY.json` `results.BS-M5` | 否 |
| BS-H1 | 2026-09-13 | 研究環境 BookStack slot b | HTTP 匯出／匯入＋**磁碟位元組比對** | **推定** | A `SUMMARY.json` `results.BS-H1` | 否 |
| BS-H2 | 2026-09-13 | 研究環境 BookStack slot b | HTTP 送出＋**資料庫重讀**＋以第二身分重讀 | **推定** | A `SUMMARY.json` `results.BS-H2` | 否 |
| BS-H3 | 2026-09-13 | 研究環境 BookStack slot b | HTTP 匯入＋**資料庫重讀**結構 | **推定** | A `SUMMARY.json` `results.BS-H3` | 否 |
| BS-H4 | 2026-09-13 | 研究環境 BookStack slot b | HTTP 查詢＋逐組結果比對 | **推定** | A `SUMMARY.json` `results.BS-H4` | 否 |
| BS-H5 | 2026-09-13 | 研究環境 BookStack slot b | HTTP 送出＋**資料庫重讀** | **推定** | A `SUMMARY.json` `results.BS-H5` | 否 |

紀錄 A 的每一筆判定都以資料庫狀態或原生 HTTP 回應為準，**不採信頁面上的成功訊息**——
BS-M1／M2／M3／M5／H1／H2／H3／H5 全部是「操作回報成功、結果卻不對」，只看成功訊息會得到相反結論。

### PrestaShop 15 顆

| ID | 驗證日期 | 所在快照 | 方法 | 本套件強度 | 證據紀錄位置 | 證據出貨 |
|---|---|---|---|---|---|---|
| PS-E1 | **2026-09-20** | **本套件 0916 快照 slot a** | HTTP 送出（ajax 與 non-ajax 兩種入口）＋**資料庫重讀**＋重讀購物車頁 | **直接觀察** | D `PS-E1.md`、`evidence/fo-cases.json`、`evidence/D1-*` | 否 |
| PS-E2 | 2026-09-13 | 研究環境 PrestaShop slot a | 登入後台 GET/POST＋狀態碼＋無效 token 守衛 | **推定** | A `SUMMARY.json` `results.PS-E2` | 否 |
| PS-E3 | 2026-09-13 | 研究環境 PrestaShop slot a | 登入後台 GET，檢查頁面元素＋無效 token 守衛 | **推定** | A `SUMMARY.json` `results.PS-E3` | 否 |
| PS-E4 | 2026-09-13 | 研究環境 PrestaShop slot a | 登入後台 GET＋狀態碼＋無效 token 守衛 | **推定** | A `SUMMARY.json` `results.PS-E4` | 否 |
| PS-E5 | **2026-09-20** | **本套件 0916 快照 slot a** | 後台表單 POST（per-route token）＋頁面大小與標題＋**資料庫重讀**＋列表重讀 | **直接觀察** | D `PS-E5.md`、`evidence/bo-case-4.json`、`evidence/D4-*` | 否 |
| PS-M1 | 2026-09-13 | 研究環境 PrestaShop slot a（B）／slot b（C） | **真實瀏覽器** UI 操作＋**資料庫重讀**＋重開編輯頁與列表 | **推定** | B `VALIDATION.json`＋`cases/PS-M1.json`＋截圖；C `evidence/PS-M1-RESULT.json` | 否 |
| PS-M2 | **2026-09-20** | **本套件 0916 快照 slot a** | 兩次 HTTP 送出（含反向操作）＋**資料庫重讀**＋重讀購物車頁 | **直接觀察** | D `PS-M2.md`、`evidence/fo-cases.json`、`evidence/D3-*` | 否 |
| PS-M3 | 2026-09-13 | 研究環境 PrestaShop slot a | 前台 GET 多個入口交叉比對 | **推定** | A `SUMMARY.json` `results.PS-M3` | 否 |
| PS-M4 | 2026-09-13 | 研究環境 PrestaShop slot a（B）／slot b（C） | **真實瀏覽器** UI 操作＋**資料庫重讀**＋截圖目視核對 | **推定** | B `VALIDATION.json`＋`cases/PS-M4.json`＋截圖；C `evidence/PS-M4-RESULT.json` | 否 |
| PS-M5 | 2026-09-13 | 研究環境 PrestaShop slot a | 後台 GET＋JSON 內容比對＋無效 token 守衛 | **推定** | A `SUMMARY.json` `results.PS-M5` | 否 |
| PS-H1 | **2026-09-20** | **本套件 0916 快照 slot a** | 後台表單 POST＋導向＋**資料庫重讀**＋重開編輯頁 | **直接觀察** | D `PS-H1.md`、`evidence/bo-case-5.json`、`evidence/D5-*` | 否 |
| PS-H2 | 2026-09-13 | 研究環境 PrestaShop slot a（A）／slot b（C） | **真實瀏覽器** UI 操作＋**資料庫重讀**（關聯必須確實改變才判成立） | **推定** | A `SUMMARY.json` `results.PS-H2`；C `evidence/PS-H2-RESULT.json` | 否 |
| PS-H3 | 2026-09-13 | 研究環境 PrestaShop slot a（B）／slot b（C） | **真實瀏覽器** UI 操作＋**資料庫重讀**＋截圖目視核對 | **推定** | B `VALIDATION.json`＋`cases/PS-H3.json`＋截圖；C `evidence/PS-H3-RESULT.json` | 否 |
| PS-H4 | 2026-09-13 | 研究環境 PrestaShop slot a（A）／slot b（C） | **真實瀏覽器** UI 操作＋**資料庫重讀** | **推定** | A `SUMMARY.json` `results.PS-H4`；C `evidence/PS-H4-RESULT.json` | 否 |
| PS-H5 | **2026-09-20** | **本套件 0916 快照 slot a** | HTTP 送出＋**資料庫重讀**＋重讀購物車頁；另測一個替代入口 | **直接觀察** | D `PS-H5.md`、`evidence/fo-cases.json`、`evidence/fo-supplementary.json`、`evidence/D2-*` | 否 |

#### 為什麼 2026-09-20 補的是這 5 顆

不是隨機抽樣，是挑**驗證依據最薄弱**的：

- **PS-H1**：答案卷 `GOLD-PS-15.md` 的「Unimplemented IDs」段自承，植入當天那一輪的新建 POST
  並沒有插入新資料列，當時的依據是前一輪遺留的資料列加上 live overlay。
  **而本套件 0916 快照上那張表是 0 筆**（2026-09-20 還原後實測），所以那個依據在本套件上根本不存在。
- **PS-E1／PS-M2／PS-H5／PS-E5**：改種子後的觸發紀錄只有紀錄 A 一筆，走的是同一支 Python 腳本，
  而那支腳本的 HTTP 目標與資料庫目標各有各的預設值、輸出又沒記下實際用的資料庫參數，
  **無法從輸出確認那一筆的 HTTP 與資料庫是同一個槽**（這個歧義由紀錄 B 與 C 分別指出並記錄在案）。
  這四顆的判定都**涉及送出寫入請求再回頭看結果**，所以槽位配對對它們特別要緊。
  其餘各顆的觀察方法逐顆不同，見上面逐顆表的「方法」欄，**並非全部只需 GET**；
  本文件不以「純 GET」概括它們，也不據此宣稱那些項目的槽位配對歧義已經排除。

2026-09-20 那一輪的 HTTP 目標與資料庫容器**成對記錄在每一份證據檔裡**，可直接核對沒有跨槽。

---

## 4. by construction 推定的依據是什麼，你能查核到哪一步

那 25 顆的轉移論證是：

> 轉移推定所依據的前提是：研究環境與本套件使用**相同的缺陷覆蓋檔、初始資料庫備份與 seed 腳本**，
> 且缺陷全部由覆蓋檔裡的程式碼改動引入。依此前提，**推定**相同症狀在本套件仍可觸發。
>
> **這不等於已在 0916 快照上逐顆觀察確認。**

**你在本 repo 內可以自己查核的部分**：

1. `IMPORT-MANIFEST.json` 釘住了 `dut/overlay/` 的 25 個檔案、`dut/patches/` 的 32 個檔案、
   `dut/seeds/` 的 3 個檔案，以及 `arms/` 底下的材料。重算 sha256 與它逐一比對，
   若這些條目全部相符，可確認**目前的檔案內容與 manifest 記錄的匯入版本（見 `imported_utc`）逐位元相同**。
   它**不**證明期間從未被修改（改過又還原是同樣的結果），也**不**證明研究環境當時載入的是同一份檔案。
2. `dut/backups/initial/SHA256SUMS` 釘住初始資料庫備份。
3. 建好映像、起站之後，`dut/bench-dut.sh verify <site>` 會在容器內跑
   `sha256sum -c /opt/seeded/INVENTORY.sha256`，逐檔確認**實際套用到應用程式目錄的覆蓋檔**
   與 repo 裡的那一份相同。

**你在本 repo 內查核不到的部分**（誠實列出）：

- 上述雜湊只能證明「本 repo 內部一致」。**「研究環境當時用的是同一份覆蓋檔」這句話，
  你無法獨立驗證**，因為研究 repo 不隨本套件出貨。
- `bench.sh up` 產生的快照是**你自己跑出來的那一份**，不會與 2026-09-20 紀錄裡的
  快照雜湊逐位元相同（資料庫 dump 帶時間戳）。可重現的是**覆蓋檔的逐檔雜湊檢查**，不是快照的位元組。
- 本套件的 BookStack **完全沒有**任何在 0916 快照上取得的觸發紀錄，15 顆全部是推定。

---

## 5. 三則對答案卷的註記

這三則是改種子後才發現的，答案卷（被釘住，不能改）裡沒有。

### 5.1 一顆 PrestaShop 缺陷的記載操作起點與現行快照不同

**PS-H2。**答案卷記載的操作起點是「商品 1 的分類關聯為 `2,3,4`」。
改種子之後，seed 腳本把三個額外分類也掛到了商品 1，所以**現行快照的起點是 `2,3,4,10,11,12`**。

**缺陷本身不受影響，distinctive Then 子句也不受影響**：關聯確實會被寫入新的分類，
而 `id_category_default` 依然沒有跟著改——這正是該顆缺陷的判準。
受影響的只有答案卷裡那個具體的「before」數值。紀錄 A 與紀錄 C 都在新起點上重新觸發成功。

**對評分的意涵**：候選報告若寫出與答案卷不同的 before 值，不構成不命中。

### 5.2 一顆 BookStack 缺陷的 patch 檔描述的是較舊的變種

**BS-H1。**`dut/patches/BS-H1.patch` 描述的是**早一版**的缺陷行為（匯入時整批跳過某類附件），
與 `dut/overlay/` 裡**實際部署**的那一份不是同一個變種。
現行覆蓋檔的行為是答案卷 `GOLD-BS-15.md` H1 那一列寫的那一種（匯入看似成功、檔名保留、內容是佔位），
答案卷本身是對的。

**`dut/patches/` 只是給人看的 diff，不是部署來源**——`dut/README.md` 已經聲明「同檔多缺陷不可疊，
所以用 overlay 不用 patch」，實際套用的一律是 `dut/overlay/`。
**判斷這顆缺陷的行為時，以 `GOLD-BS-15.md` 與 `dut/overlay/` 為準，不要用 `dut/patches/BS-H1.patch`。**

### 5.3 一顆前台缺陷的症狀隨入口而異

**PS-H5。**2026-09-20 在 0916 快照上實測發現，同一顆缺陷有兩種入口、兩種症狀：

| 入口 | 症狀 |
|---|---|
| 答案卷記載的參數組合 | 操作**回報成功**，但結果值是錯的 |
| 把該頁完整渲染的表單**原封重送** | **HTTP 500** |

兩種都是同一顆缺陷的表現。

**對評分與裁決的意涵：兩種症狀描述都算命中。**
候選報告若指向 PS-H5 的**同一個操作與上述其中一個入口**，且內容足以辨識出是這顆缺陷，
就不應該只因為它記的是「HTTP 500」而非答案卷寫的「回報成功但值錯誤」（或反過來）判為不命中。

**這條註記不是說任意一個 HTTP 500 都算命中**——操作情境與可辨識性仍然是前提。
論文描述這顆缺陷的症狀時也不能只寫其中一種。細節在紀錄 D 的 `evidence/fo-supplementary.json`。

---

## 6. 覆蓋率盤查：有沒有哪一顆完全沒有觸發紀錄

**沒有。改種子之後，30 顆每一顆都至少有一筆成功觸發紀錄。**

下表前兩列是互斥的，加起來是 30。**第三列「兩槽獨立觸發」是交叉統計，不另外加進去**：
那 6 顆裡有 1 顆同屬第一列的 5 顆，另外 5 顆屬於第二列的 25 顆。

| 類別 | 顆數 | 說明 |
|---|---|---|
| 在本套件 0916 快照上直接觸發成功 | **5** | 全部是 PrestaShop，紀錄 D |
| 只有研究環境快照上的觸發紀錄（對本套件是推定） | **25** | BookStack 15 顆＋PrestaShop 10 顆 |
| 在**兩個不同的槽**上各自獨立觸發成功 | 6 | 全部是 PrestaShop，紀錄 A／B 與紀錄 C |
| **完全沒有任何觸發紀錄（連 by construction 依據都沒有）** | **0** | — |

另外記一筆：紀錄 A 那一輪有 3 顆 PrestaShop 判為未觸發，
**原因全部是驗證程式沒能驅動後台表單，不是缺陷不在**；
這 3 顆後來由紀錄 B（slot a）與紀錄 C（slot b）分別補做，兩個槽都觸發成功。

---

## 7. 出貨政策：為什麼這些證據不在本套件裡

上面引用的稽核目錄**全部留在研究 repo，不隨本評審套件出貨**。文件不假裝你打得開它們。

理由：那些紀錄包含**逐顆的完整觸發步驟**——請求序列、送出的欄位、要查哪張表哪個欄位、
哪個入口才驅動得動表單。出貨等於把答案卷從「症狀清單」擴大成「操作手冊」。
本套件的答案卷已經足以判分；再加上一本操作手冊，只會擴大洩漏面而不增加可判分性。

**你在本套件內能做的替代查核**：

- 第 4 節列的三項雜湊查核（`IMPORT-MANIFEST.json`、`dut/backups/initial/SHA256SUMS`、
  容器內 `INVENTORY.sha256`）。
- 起站之後，依 `GOLD-BS-15.md`／`GOLD-PS-15.md` 的操作描述、Then 判準與本文件第 5 節的差異註記，
  自行設計重觸發查核。這是最直接的查核，但要知道它的邊界：
  **Then 子句是判準，本身不保證提供完整的操作步驟**，原稽核紀錄裡的請求序列並未隨本套件出貨。
  另外注意 `REPAIR-V1-NAMES.md` 的名稱對照：答案卷的 slug 與 ID 是舊種子的。
- 需要那些稽核紀錄本身的，向作者索取；發表後可與研究 repo 一併處理。

---

## 8. 這份文件的限制

1. **觸發症狀證明缺陷存在且可達，不衡量發現難度。**這份文件不能用來推論任何一輪該得幾分。
2. 25 顆對本套件是推定。要消除這個落差，唯一的辦法是在 0916 快照上逐顆重觸發；
   2026-09-20 只做了證據最弱的 5 顆。
3. 2026-09-20 那一輪走的是原生 HTTP，不是真實瀏覽器：送出的欄位都是從實際渲染的表單刮下來的，
   但沒有錄影、沒有截圖，也沒有驗證前端 JS 會不會改寫那些欄位。
4. 紀錄 A 的 PrestaShop 部分有已知的槽位配對歧義（見第 3 節）。上述四顆的主要依據已由紀錄 D 取代；
   **其餘仍然引用紀錄 A 的項目，相關歧義尚未消除。**
5. 本文件只描述驗證溯源，不重述觸發配方。配方以 `GOLD-BS-15.md`／`GOLD-PS-15.md` 為準。