From 956d6744c50d2205af72206c1844ca35675d99f2 Mon Sep 17 00:00:00 2001
From: Adrian Theopold <83468052+AdrianTheopold@users.noreply.github.com>
Date: Mon, 22 Jun 2026 07:34:50 +0000
Subject: [PATCH] docs(superpowers-bridge): translate artifact-template
 guidance from zh-TW to English

The superpowers-bridge README and adopter CLAUDE.md fragment follow an
English-primary + .zh-TW.md variant convention, but six artifact templates
carried Traditional-Chinese author guidance inline with no English variant.
OpenSpec injects each template as a scaffold at artifact-generation time, so
the Chinese leaked into authored brainstorm/proposal/design/spec files (in
comments) and into rendered verify.md / retrospective.md reports (table
headers, checkbox labels).

Translate the embedded zh-TW guidance to English in all six affected
templates, preserving structure, OpenSpec validation rules, and grep-critical
tokens (PASS / PASS WITH WARNINGS / FAIL markers, checkbox forms). plan.md and
tasks.md were already clean; the intentional README.zh-TW.md and
CLAUDE.md.fragment.zh-TW.md locale variants are untouched. schema.yaml is not
modified, so the artifact graph is unchanged.
---
 superpowers-bridge/templates/brainstorm.md    |  14 +-
 superpowers-bridge/templates/design.md        | 100 +++----
 superpowers-bridge/templates/proposal.md      |  20 +-
 superpowers-bridge/templates/retrospective.md |  75 ++---
 superpowers-bridge/templates/spec.md          | 151 +++++-----
 superpowers-bridge/templates/verify.md        | 266 +++++++++---------
 6 files changed, 324 insertions(+), 302 deletions(-)

diff --git a/superpowers-bridge/templates/brainstorm.md b/superpowers-bridge/templates/brainstorm.md
index fad1c8d..515aa9e 100644
--- a/superpowers-bridge/templates/brainstorm.md
+++ b/superpowers-bridge/templates/brainstorm.md
@@ -1,12 +1,14 @@
 <!--
 Raw capture of superpowers:brainstorming output.
 
-本檔原樣捕捉 brainstorming skill 的產出，不強制結構。
-Skill 的自然產出通常是 decision log 格式（背景 → 決議鏈 Q1-Qn → 設計取捨），
-但依對話內容可能有不同組織方式。
+This file captures the brainstorming skill's output as-is, without forcing
+any structure. The skill's natural output is typically a decision-log format
+(background → decision chain Q1-Qn → design trade-offs), but the organization
+may vary with the conversation.
 
-design.md 從本檔萃取並重新整理為結構化設計文件。
+design.md is extracted and reorganized from this file into a structured
+design document.
 
-不要將本檔的內容複製到 design.md — design.md 是獨立的重組產物，
-兩者互補但不重疊。
+Do NOT copy this file's content into design.md — design.md is an independent
+reorganized artifact. The two are complementary, not overlapping.
 -->
diff --git a/superpowers-bridge/templates/design.md b/superpowers-bridge/templates/design.md
index 1ae849e..2518ef3 100644
--- a/superpowers-bridge/templates/design.md
+++ b/superpowers-bridge/templates/design.md
@@ -1,49 +1,51 @@
-## Context
-
-<!--
-Background, current state, constraints, stakeholders.
-brainstorm.md 記錄了探索過程（替代方案 + 選定方向）；
-本檔承接選定方向，展開完整技術設計。
--->
-
-## Goals / Non-Goals
-
-**Goals:**
-<!-- What this design aims to achieve -->
-
-**Non-Goals:**
-<!-- What is explicitly out of scope -->
-
-## Decisions
-
-<!--
-所有技術決策的唯一來源（single source of truth）。
-brainstorm.md 的 Agreed Approach 記錄了「選了哪條路」，
-本段記錄「那條路上的每個岔口怎麼選的」。
-
-每個決策建議結構：
-### D1：<決策標題>
-- **選擇**：<採用的做法>
-- **理由**：<為何這樣選>
-- **已考慮 alternative**：<被拒方案 + 拒絕原因>
--->
-
-## Risks / Trade-offs
-
-<!--
-Known risks and trade-offs.
-Format: [Risk] <描述> → Mitigation: <緩解措施>
-[Trade-off] <取捨描述> → 接受理由
--->
-
-## Migration Plan
-
-<!--
-部署順序、rollback 策略、驗收條件。
-若本 change 不涉及部署變更（純加套件、無 endpoint / DB 變更），
-可寫「N/A — 本 change 不涉及部署變更」。
--->
-
-## Open Questions
-
-<!-- Outstanding decisions or unknowns to resolve -->
+## Context
+
+<!--
+Background, current state, constraints, stakeholders.
+brainstorm.md records the exploration process (alternatives considered +
+chosen direction); this file picks up the chosen direction and expands it
+into the full technical design.
+-->
+
+## Goals / Non-Goals
+
+**Goals:**
+<!-- What this design aims to achieve -->
+
+**Non-Goals:**
+<!-- What is explicitly out of scope -->
+
+## Decisions
+
+<!--
+Single source of truth for all technical decisions.
+brainstorm.md's Agreed Approach records *which road was chosen*;
+this section records *how each fork along that road was decided*.
+
+Suggested structure per decision:
+### D1: <decision title>
+- **Choice**: <the approach adopted>
+- **Rationale**: <why it was chosen>
+- **Alternatives considered**: <rejected option + reason for rejection>
+-->
+
+## Risks / Trade-offs
+
+<!--
+Known risks and trade-offs.
+Format: [Risk] <description> → Mitigation: <mitigation>
+[Trade-off] <description of the trade-off> → reason for accepting it
+-->
+
+## Migration Plan
+
+<!--
+Deployment order, rollback strategy, acceptance conditions.
+If this change involves no deployment changes (pure dependency additions,
+no endpoint / DB changes), write "N/A — this change involves no deployment
+changes".
+-->
+
+## Open Questions
+
+<!-- Outstanding decisions or unknowns to resolve -->
diff --git a/superpowers-bridge/templates/proposal.md b/superpowers-bridge/templates/proposal.md
index ad72b94..240aae0 100644
--- a/superpowers-bridge/templates/proposal.md
+++ b/superpowers-bridge/templates/proposal.md
@@ -3,11 +3,12 @@
 <!--
 Explain the motivation for this change. What problem does this solve? Why now?
 
-硬限制：50 ≤ 字元數 ≤ 1000（OpenSpec zod schema 會 validate）
-- 太短：會收到 `Why section must be at least 50 characters` error
-- 太長：會收到 `Why section should not exceed 1000 characters` error
+Hard limit: 50 ≤ character count ≤ 1000 (validated by OpenSpec's zod schema)
+- Too short: you'll get a `Why section must be at least 50 characters` error
+- Too long: you'll get a `Why section should not exceed 1000 characters` error
 
-建議結構：現況痛點 → 為什麼現在處理 → 預期收益（各 1-2 句）
+Suggested structure: current pain point → why address it now → expected
+benefit (1-2 sentences each)
 -->
 
 ## What Changes
@@ -15,7 +16,8 @@ Explain the motivation for this change. What problem does this solve? Why now?
 <!--
 Describe what will change. Be specific about new capabilities, modifications, or removals.
 
-對於有明確前後對比的行為變更，使用 From/To 格式（markdown 無 inline diff）：
+For behavior changes with a clear before/after contrast, use the From/To
+format (markdown has no inline diff):
 
 **<Section or Behavior Name>**
 - From: <current state / requirement>
@@ -23,7 +25,8 @@ Describe what will change. Be specific about new capabilities, modifications, or
 - Reason: <why this change is needed>
 - Impact: <breaking / non-breaking, who's affected>
 
-多個變更可重複此 block；純新增或純刪除可用簡單列表描述。
+Repeat this block for multiple changes; pure additions or pure removals can
+be described with a simple list.
 -->
 
 ## Capabilities
@@ -31,8 +34,9 @@ Describe what will change. Be specific about new capabilities, modifications, or
 ### New Capabilities
 <!--
 Capabilities being introduced. Replace <name> with kebab-case identifier.
-命名規則見 openspec/specs/README.md：使用複合名詞（至少 2 個 word），
-例如 `user-auth`、`data-export`、`api-rate-limiting`，不用純單詞。
+Naming rule (see openspec/specs/README.md): use a compound noun (at least
+2 words), e.g. `user-auth`, `data-export`, `api-rate-limiting` — not a single
+bare word.
 Each creates specs/<name>/spec.md
 -->
 - `<name>`: <brief description of what this capability covers>
diff --git a/superpowers-bridge/templates/retrospective.md b/superpowers-bridge/templates/retrospective.md
index bd2775e..6cadabc 100644
--- a/superpowers-bridge/templates/retrospective.md
+++ b/superpowers-bridge/templates/retrospective.md
@@ -8,13 +8,15 @@
 
 ## 0. Evidence
 
-> 量化前置數據 — 後續 Wins / Misses bullets 直接引用,避免每行重複 [evidence: ...]。
-> 冷寫場景(retro 寫於 cycle 結束之後一段時間),只用 `git log` + `tasks.md` +
-> commit messages 也應能重建本節。
+> Quantitative front-matter — the Wins / Misses bullets below reference it
+> directly, avoiding a repeated [evidence: ...] on every line.
+> Cold-write scenario (retro written some time after the cycle ends): this
+> section should be reconstructable from `git log` + `tasks.md` + commit
+> messages alone.
 
 - **Commit range**: `<base-sha>..<head-sha>` (<n> commits)
 - **Diff size**: <+X / -Y lines across N files>
-- **Tasks done**: <x>/<y> (`grep -cE '^\s*- \[x\]' tasks.md` → x;regex 容許 sub-task 縮排)
+- **Tasks done**: <x>/<y> (`grep -cE '^\s*- \[x\]' tasks.md` → x; the regex allows sub-task indentation)
 - **Active hours**: <estimate>
 - **Subagent dispatches**: <count or "n/a">
 - **New external dependencies**: <list, with license + version, or "none">
@@ -22,7 +24,7 @@
 - **OpenSpec validate state at archive**: <pass / fail / not-run>
 - **Test coverage signal**: <e.g. jacoco %, pytest count, vitest count, or "n/a">
 
-Commit chain (時序):
+Commit chain (chronological):
 
 ```
 <base-sha> <one-line summary>
@@ -60,27 +62,30 @@ Commit chain (時序):
 | (transitive) superpowers:requesting-code-review  |      |
 | superpowers:finishing-a-development-branch       |      |
 
-> **Default expectation**: 全部 ✓。每個 skill 都是 schema 設計的一部分,
-> 跳過屬於異常情境。任一項 ✗ 都必須在下方
-> `### Deliberately Skipped Skills` subsection 提出原因與預防方案。
+> **Default expectation**: all ✓. Every skill is part of the schema's design;
+> skipping one is an exceptional situation. Any ✗ must be justified in the
+> `### Deliberately Skipped Skills` subsection below, with cause and prevention.
 
 ### Deliberately Skipped Skills
 
-> 跳過 skill 是設計的 escape hatch,不是常規路徑。每個 ✗ 必須回答以下三題;
-> 整節空白(全綠)是預期狀態。
+> Skipping a skill is the design's escape hatch, not the normal path. Each ✗
+> must answer the three questions below; a blank section (all green) is the
+> expected state.
 
 - **`<skill name>`**
-  - **What was skipped**: <具體跳過了整個 skill,還是某個 sub-step>
-  - **Why this cycle**: <具體 cycle 條件 — 不可寫「不需要」/「太小」/「沒時間」/「被外部 dep 擋住」/「skill 輸出看起來不對」之類含糊理由;要寫實際 trigger(具體 commit / log line / 觀察到的行為)>
-  - **How to prevent recurrence**: 下一個 cycle 在同類條件下怎麼不再跳?選一:
-    - `schema graph fix` — 寫具體要改 schema.yaml 的哪一段
-    - `skill description tightening` — 寫具體要改哪個 skill 的 frontmatter / instruction
-    - `CLAUDE.md trigger` — 寫具體要在 adopter CLAUDE.md.fragment 加哪段判讀規則
-    - `scope-judgment rule` — 寫具體 cycle 的 scope 應該被怎麼判讀
-    - `one-off — schema boundary case, no prevention possible` — 但需明寫為何 boundary(不接受含糊保留)
-
-> **與 §6 Promote candidates 的關係**:多個 cycle 同 skill 同 `How to prevent`
-> 答案 → 該模式應 promote 到 §6,直接觸發 schema / skill PR,不可累積成「常態」。
+  - **What was skipped**: <the specific skill, or a sub-step within it>
+  - **Why this cycle**: <the concrete cycle condition — vague reasons like "not needed" / "too small" / "no time" / "blocked by an external dep" / "the skill's output looked off" are not acceptable; name the actual trigger (a specific commit / log line / observed behavior)>
+  - **How to prevent recurrence**: how should the next cycle in the same situation avoid skipping? Pick one:
+    - `schema graph fix` — name the specific part of schema.yaml to change
+    - `skill description tightening` — name which skill's frontmatter / instruction to tighten
+    - `CLAUDE.md trigger` — name the interpretation rule to add to the adopter's CLAUDE.md.fragment
+    - `scope-judgment rule` — state how this cycle's scope should have been judged
+    - `one-off — schema boundary case, no prevention possible` — but state explicitly why it's a boundary case (vague reservations not accepted)
+
+> **Relationship to §6 Promote candidates**: if multiple cycles skip the same
+> skill with the same `How to prevent` answer, that pattern should be promoted
+> to §6 and trigger a schema / skill PR directly — it must not accumulate into
+> a "norm".
 
 ## 5. Surprises
 
@@ -88,31 +93,33 @@ Commit chain (時序):
 
 ## 6. Promote candidates → long-term learning
 
-每條 candidate 用 `- [ ]` checklist:
+Each candidate uses a `- [ ]` checklist:
 
-- 標題:嚴重程度 emoji(🔴/🟡/📌)+ 一句話 learning
-- `→ **Promote to** <destination>`(memory / CLAUDE.md / schema / skill / one-off)
-- 兩行 body(對應 superpowers feedback memory body schema):
+- Title: severity emoji (🔴/🟡/📌) + a one-sentence learning
+- `→ **Promote to** <destination>` (memory / CLAUDE.md / schema / skill / one-off)
+- Two body lines (matching the superpowers feedback memory body schema):
   - `> **Why**: <reason; often a past incident or strong preference>`
   - `> **How to apply**: <when/where this guidance kicks in>`
 
-未勾選的 `- [ ]` 表示 candidate 尚未 promote — 可帶到下一個 cycle 的 retro 重評估,
-或保留作為跨 cycle 的觀察點。
+An unchecked `- [ ]` means the candidate hasn't been promoted yet — it can be
+carried to the next cycle's retro for re-evaluation, or kept as a cross-cycle
+observation point.
 
-> **Carry-forward 機制**:下個 cycle 寫 retro 時,可
-> `grep -A 5 '^- \[ \]' openspec/changes/archive/*/retrospective.md` 取出
-> 既往 unchecked candidates,逐筆判斷要 carry-forward 到本 cycle §6、就地
-> promote、或標 stale 不再追蹤。
+> **Carry-forward mechanism**: when writing the next cycle's retro, run
+> `grep -A 5 '^- \[ \]' openspec/changes/archive/*/retrospective.md` to pull
+> prior unchecked candidates, and decide per item whether to carry it forward
+> into this cycle's §6, promote it on the spot, or mark it stale and stop
+> tracking it.
 
-範例:
+Example:
 
 - [ ] 🔴 **<short rule>** → **Promote to memory** (type: feedback)
   > **Why**: <past incident or strong preference that motivated this rule>
   > **How to apply**: <which file / cycle phase / decision moment this kicks in>
 
-- [ ] 🟡 **<another candidate>** → **Promote to project CLAUDE.md** (`<path/to/CLAUDE.md>` 段)
+- [ ] 🟡 **<another candidate>** → **Promote to project CLAUDE.md** (`<path/to/CLAUDE.md>` section)
   > **Why**: ...
   > **How to apply**: ...
 
-- [ ] 📌 **<third candidate>** → **One-off** (記錄即可,不 promote)
+- [ ] 📌 **<third candidate>** → **One-off** (record only, do not promote)
   > **Why**: <why it doesn't generalize>
diff --git a/superpowers-bridge/templates/spec.md b/superpowers-bridge/templates/spec.md
index d9c042a..6d96b01 100644
--- a/superpowers-bridge/templates/spec.md
+++ b/superpowers-bridge/templates/spec.md
@@ -1,74 +1,77 @@
-<!--
-Delta spec template for a change.
-
-此模板示範 4 種 delta section，按實際需要取用：
-- ADDED / MODIFIED / REMOVED / RENAMED
-檔名與位置：openspec/changes/<change-name>/specs/<capability>/spec.md
-（`<capability>` 對齊 openspec/specs/<capability>/ 目錄名）
-
-格式硬規則（OpenSpec 會 validate）：
-- Requirement 句子 MUST 含 `SHALL` 或 `MUST`
-- 每個 Requirement MUST 至少有一個 `#### Scenario:`
-- Scenario MUST 用 level-4 (`####`)，level-3 或 bullet 會 silent fail
--->
-
-## ADDED Requirements
-
-<!-- 新增行為。列出本 change 要加到 capability 的新 Requirement。 -->
-
-### Requirement: <!-- requirement name -->
-<!-- requirement text — 須含 SHALL 或 MUST -->
-
-#### Scenario: <!-- scenario name -->
-- **WHEN** <!-- condition -->
-- **THEN** <!-- expected outcome -->
-
----
-
-## MODIFIED Requirements
-
-<!--
-修改既有 Requirement。**MUST 使用與 openspec/specs/<capability>/spec.md
-完全相同的 normalized header**（trim 後 case-sensitive 比對），否則 archive
-時的 delta apply 會因找不到對應 requirement 而失敗。
-
-**MUST 貼出修改後的完整內容**（不是只寫 diff），因為 OpenSpec archive
-是用全文替換的方式 apply MODIFIED。
--->
-
-### Requirement: <!-- 與既有 spec 中相同的 header -->
-<!-- 修改後的完整 requirement text — 含 SHALL 或 MUST -->
-
-#### Scenario: <!-- scenario name（可新增、可修改） -->
-- **WHEN** <!-- condition -->
-- **THEN** <!-- expected outcome -->
-
----
-
-## REMOVED Requirements
-
-<!--
-刪除既有 Requirement。MUST 包含 Reason 與 Migration 說明，讓 reviewer
-理解為何廢除以及既有引用方該怎麼遷移。
--->
-
-### Requirement: <!-- 要刪除的 header，與既有 spec 完全相同 -->
-
-**Reason**: <!-- 為何廢除 -->
-
-**Migration**: <!-- 既有呼叫方/依賴方應如何調整 -->
-
----
-
-## RENAMED Requirements
-
-<!--
-重新命名 Requirement header。格式固定：FROM / TO 用 code-fence header。
-若名稱變更 + 內容變更，**同時**在 RENAMED 列出名字變更，並在 MODIFIED
-用**新的** header 再寫一份完整內容。
-
-archive 時 apply 順序：RENAMED → REMOVED → MODIFIED → ADDED
--->
-
-- FROM: `### Requirement: <Old Name>`
-- TO: `### Requirement: <New Name>`
+<!--
+Delta spec template for a change.
+
+This template demonstrates the 4 delta section types; use whichever you
+actually need:
+- ADDED / MODIFIED / REMOVED / RENAMED
+Filename & location: openspec/changes/<change-name>/specs/<capability>/spec.md
+(`<capability>` matches the openspec/specs/<capability>/ directory name)
+
+Hard format rules (validated by OpenSpec):
+- A Requirement sentence MUST contain `SHALL` or `MUST`
+- Every Requirement MUST have at least one `#### Scenario:`
+- Scenarios MUST use level-4 headings (`####`); level-3 or bullets fail silently
+-->
+
+## ADDED Requirements
+
+<!-- New behavior. List the new Requirements this change adds to the capability. -->
+
+### Requirement: <!-- requirement name -->
+<!-- requirement text — must contain SHALL or MUST -->
+
+#### Scenario: <!-- scenario name -->
+- **WHEN** <!-- condition -->
+- **THEN** <!-- expected outcome -->
+
+---
+
+## MODIFIED Requirements
+
+<!--
+Modify an existing Requirement. **MUST use the exact same normalized header
+as in openspec/specs/<capability>/spec.md** (compared case-sensitively after
+trimming), otherwise the delta apply at archive time will fail because it
+can't find the matching requirement.
+
+**MUST paste the full modified content** (not just a diff), because OpenSpec
+archive applies MODIFIED by full-text replacement.
+-->
+
+### Requirement: <!-- the same header as in the existing spec -->
+<!-- the full modified requirement text — contains SHALL or MUST -->
+
+#### Scenario: <!-- scenario name (may be added or modified) -->
+- **WHEN** <!-- condition -->
+- **THEN** <!-- expected outcome -->
+
+---
+
+## REMOVED Requirements
+
+<!--
+Remove an existing Requirement. MUST include Reason and Migration notes so the
+reviewer understands why it's being retired and how existing references should
+migrate.
+-->
+
+### Requirement: <!-- the header to remove, identical to the existing spec -->
+
+**Reason**: <!-- why it's being retired -->
+
+**Migration**: <!-- how existing callers / dependents should adapt -->
+
+---
+
+## RENAMED Requirements
+
+<!--
+Rename a Requirement header. Fixed format: FROM / TO using code-fenced headers.
+If both the name and the content change, list the name change under RENAMED
+**and** write the full content under MODIFIED using the **new** header.
+
+Apply order at archive time: RENAMED → REMOVED → MODIFIED → ADDED
+-->
+
+- FROM: `### Requirement: <Old Name>`
+- TO: `### Requirement: <New Name>`
diff --git a/superpowers-bridge/templates/verify.md b/superpowers-bridge/templates/verify.md
index fef1cfa..d359988 100644
--- a/superpowers-bridge/templates/verify.md
+++ b/superpowers-bridge/templates/verify.md
@@ -1,131 +1,135 @@
-# Verification Report
-
-> 此檔案由 `openspec-verify-change` skill 在 apply 完成後產生，用以確認實作
-> 與 specs / design / tasks 的一致性。失敗的檢查須返回對應 artifact 修正後
-> 再重跑 verify。
-
-**Change**: `<change-name>`
-**Verified at**: `YYYY-MM-DD HH:mm`
-**Verifier**: `<who / which agent>`
-
----
-
-## 1. Structural Validation (`openspec validate --all --json`)
-
-- [ ] 全數 items `"valid": true`
-
-**結果**：
-
-```text
-<貼上 openspec validate --all 的輸出摘要>
-```
-
-若有失敗項目，列出 id + issues：
-
-| Item | Type | Issues |
-|---|---|---|
-| — | — | — |
-
----
-
-## 2. Task Completion (`tasks.md`)
-
-- [ ] 所有 `- [ ]` 已變為 `- [x]`
-
-**未完成任務**（若有）：
-
-| Task | 未完成原因 | 是否阻塞 archive |
-|---|---|---|
-| — | — | — |
-
----
-
-## 3. Delta Spec Sync State
-
-對每個 `openspec/changes/<name>/specs/` 下的 capability 目錄，與
-`openspec/specs/<capability>/spec.md` 比對：
-
-| Capability | Sync 狀態 | 備註 |
-|---|---|---|
-| — | ✓ 已 sync / ✗ 待 sync / N/A | — |
-
----
-
-## 4. Design / Specs Coherence Spot Check
-
-抽樣比對 `design.md` 的決策是否反映在 `specs/*.md` 的 Requirements 與
-Scenarios 中：
-
-| 抽樣項 | design 描述 | specs 對應 | 差距 |
-|---|---|---|---|
-| — | — | — | — |
-
-**漂移警告**（非阻塞）：
-
-- <若有，列出；無則填「無」>
-
----
-
-## 5. Implementation Signal
-
-- [ ] Worktree 內無未 staged 的檔案
-- [ ] 所有相關 commit 已推送
-
-**Commit 範圍**（若知道）：`<from-sha>..<to-sha>`
-
----
-
-## 6. Front-Door Routing Leak Detector（warning,非阻塞）
-
-設計產出不應落在 `docs/superpowers/specs/`(brainstorm artifact 的
-output redirection 會把它導到 `openspec/changes/<name>/brainstorm.md`)。
-
-偵測:
-
-```bash
-ls docs/superpowers/specs/*.md 2>/dev/null
-```
-
-- [ ] 無檔案,或存在的檔案是 schema 安裝前的合法存留
-
-**洩漏清單**（若有）：
-
-| 檔案 | 內容是否已 captured 進 change | 建議動作 |
-|---|---|---|
-| — | — | — |
-
-> 不會擋住 archive。新的 schema-installed cycle 產生的洩漏,應搬進
-> `openspec/changes/<name>/brainstorm.md` 或 `design.md` 後刪原檔。
-
----
-
-## 7. Deferred Manual Dogfood vs Automated Test Equivalence
-
-對 plan.md 中標 `[~]` deferred 的手動 dogfood / smoke task,逐項列出
-等價的自動化測試覆蓋。若沒有等價自動化測試,該項應視為**真正的 gap**
-而非合理 deferral,建議在 retrospective Misses 中記錄。
-
-| Deferred dogfood (plan §) | Equivalent automated test | Coverage assessment | 真正 gap? |
-|---|---|---|---|
-| 例:§11.3 `compose up + curl /actuator/health` | `LinebcIntegrationApplicationTests` (Testcontainers,24s) | Spring context boot + Flyway 跑完 + 主要 bean 注入 | ❌ 已等價覆蓋 |
-| — | — | — | — |
-
-> **判讀規則**:
-> - 「等價」= 自動化測試的 assertion 集合是手動 dogfood 預期 assertion 的超集
-> - 「Coverage assessment」= 列出實際被觸及的 layer (context / DB schema / wiring / HTTP path / etc.)
-> - 任何「真正 gap = ✅」的列,Overall Decision 仍可 PASS,但須在 retrospective 留 follow-up 條目
-
-> **何時可以整節空白**:plan.md 完全沒有 `[~]` 標記的 row 時,本節不需要填(空白即 PASS)。
-> 只要 plan.md 出現任何 `[~]`,本節必須逐項列出,否則 Overall Decision 應降為 FAIL。
-
----
-
-## Overall Decision
-
-- [ ] ✅ PASS — 可進入 finishing-a-development-branch 與 archive
-- [ ] ⚠️ PASS WITH WARNINGS — 可進入後續步驟但需注意：`<說明>`
-- [ ] ❌ FAIL — 返回失敗的 artifact 修正後重跑 verify
-
-**下一步**：
-
-<說明下一個動作>
+# Verification Report
+
+> This file is produced by the `openspec-verify-change` skill after apply
+> completes, to confirm the implementation is consistent with specs / design /
+> tasks. Failed checks must return to the corresponding artifact for fixing,
+> then re-run verify.
+
+**Change**: `<change-name>`
+**Verified at**: `YYYY-MM-DD HH:mm`
+**Verifier**: `<who / which agent>`
+
+---
+
+## 1. Structural Validation (`openspec validate --all --json`)
+
+- [ ] All items report `"valid": true`
+
+**Result**:
+
+```text
+<paste a summary of the openspec validate --all output>
+```
+
+If any items fail, list id + issues:
+
+| Item | Type | Issues |
+|---|---|---|
+| — | — | — |
+
+---
+
+## 2. Task Completion (`tasks.md`)
+
+- [ ] All `- [ ]` have become `- [x]`
+
+**Incomplete tasks** (if any):
+
+| Task | Reason incomplete | Blocks archive? |
+|---|---|---|
+| — | — | — |
+
+---
+
+## 3. Delta Spec Sync State
+
+For each capability directory under `openspec/changes/<name>/specs/`, compare
+against `openspec/specs/<capability>/spec.md`:
+
+| Capability | Sync status | Notes |
+|---|---|---|
+| — | ✓ synced / ✗ needs sync / N/A | — |
+
+---
+
+## 4. Design / Specs Coherence Spot Check
+
+Spot-check whether `design.md`'s decisions are reflected in the Requirements
+and Scenarios of `specs/*.md`:
+
+| Sample | design description | specs counterpart | Gap |
+|---|---|---|---|
+| — | — | — | — |
+
+**Drift warnings** (non-blocking):
+
+- <list if any; otherwise write "none">
+
+---
+
+## 5. Implementation Signal
+
+- [ ] No unstaged files in the worktree
+- [ ] All relevant commits pushed
+
+**Commit range** (if known): `<from-sha>..<to-sha>`
+
+---
+
+## 6. Front-Door Routing Leak Detector (warning, non-blocking)
+
+Design output should not land in `docs/superpowers/specs/` (the brainstorm
+artifact's output redirection routes it to
+`openspec/changes/<name>/brainstorm.md`).
+
+Detection:
+
+```bash
+ls docs/superpowers/specs/*.md 2>/dev/null
+```
+
+- [ ] No files, or any present are legitimate pre-schema-install holdovers
+
+**Leak list** (if any):
+
+| File | Content captured into change? | Suggested action |
+|---|---|---|
+| — | — | — |
+
+> Does not block archive. Leaks produced by a new schema-installed cycle
+> should be moved into `openspec/changes/<name>/brainstorm.md` or `design.md`,
+> then the originals deleted.
+
+---
+
+## 7. Deferred Manual Dogfood vs Automated Test Equivalence
+
+For each manual dogfood / smoke task marked `[~]` deferred in plan.md, list the
+equivalent automated-test coverage. If no equivalent automated test exists,
+treat that item as a **real gap** rather than a legitimate deferral, and record
+it in the retrospective's Misses.
+
+| Deferred dogfood (plan §) | Equivalent automated test | Coverage assessment | Real gap? |
+|---|---|---|---|
+| e.g. §11.3 `compose up + curl /actuator/health` | `LinebcIntegrationApplicationTests` (Testcontainers, 24s) | Spring context boot + Flyway migrations complete + key beans injected | ❌ already equivalently covered |
+| — | — | — | — |
+
+> **Interpretation rules**:
+> - "Equivalent" = the automated test's assertion set is a superset of the manual dogfood's expected assertions
+> - "Coverage assessment" = list the layers actually exercised (context / DB schema / wiring / HTTP path / etc.)
+> - For any row where "Real gap = ✅", the Overall Decision may still be PASS, but a follow-up item must be left in the retrospective
+
+> **When this section may be left blank**: if plan.md has no `[~]`-marked rows at all, this section need not be filled (blank = PASS).
+> As soon as plan.md contains any `[~]`, this section must enumerate each one, otherwise the Overall Decision should be downgraded to FAIL.
+
+---
+
+## Overall Decision
+
+- [ ] ✅ PASS — may proceed to finishing-a-development-branch and archive
+- [ ] ⚠️ PASS WITH WARNINGS — may proceed, but note: `<explanation>`
+- [ ] ❌ FAIL — return to the failing artifact, fix it, and re-run verify
+
+**Next step**:
+
+<describe the next action>