universal-dev-standards 5.17.0 → 6.1.0

package/bundled/locales/zh-TW/core/release-quality-manifest.md

@@ -0,0 +1,207 @@
+---
+source: ../../../core/release-quality-manifest.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-10
+source_hash: 9ab9b61963df
+status: current
+---
+
+# Release Quality Manifest（發布品質清單）
+
+> **Language**: [English](../../../core/release-quality-manifest.md) | 繁體中文
+
+## 概述
+
+Release Quality Manifest（RQM）是由 CI 為每次發布自動產生的機器可讀文件。它將所有品質閘門的結果彙整為單一產物，作為發布就緒度的權威證據——既供內部 go/no-go 自動化使用，也供客戶稽核使用。
+
+## 為什麼需要 Manifest？
+
+沒有 manifest 時，品質證據會散落在 CI 日誌、覆蓋率 HTML 報告、SARIF 檔案與容器掃描摘要之中。當客戶問「這個發布是怎麼測試的？」，答案要不是「相信我們」，就是一場 45 分鐘的手動彙整作業。
+
+Release Quality Manifest 讓品質證據變得：
+- **彙整化**：一個檔案，所有閘門
+- **機器可讀**：下游工具可以解析並強制執行
+- **帶時間戳且綁定 commit**：與特定發布產物綁定
+- **可與客戶分享**：可直接附加到發布套件
+
+## Schema
+
+RQM 目前涵蓋 **16 個品質維度**，與 `release-readiness-gate.md` 對齊。自動化閘門出現在此處；人工驗證的閘門則出現在 Release Readiness Sign-off 文件中。
+
+```yaml
+release: app-commercial-1.2.0
+generated_at: "2026-05-05T04:00:00Z"
+commit: "abc1234"
+gates:
+  # ── Automated quality gates ──────────────────────────────
+  unit_coverage:
+    actual: "73%"
+    target: "80%"
+    status: warn        # within 10pp of target → warn, not fail
+  mutation_score:
+    actual: "62%"
+    target: "60%"
+    status: pass
+  sca_critical_cve:
+    actual: 0
+    target: 0
+    status: pass
+  sca_high_cve:
+    actual: 0
+    target: 0
+    status: pass
+  sast_high:
+    actual: 0
+    target: 0
+    status: pass
+  e2e_pass_rate:
+    actual: "96%"
+    target: "95%"
+    status: pass
+  container_cve_critical:
+    actual: 0
+    target: 0
+    status: pass
+  image_signed:
+    actual: true
+    target: true
+    status: pass
+  sbom_present:
+    actual: true
+    target: true
+    status: pass
+  # ── Extended dimensions (aligned with release-readiness-gate.md) ──
+  a11y_critical:             # Dimension 3: axe-core critical violations
+    actual: 0
+    target: 0
+    status: pass
+  a11y_serious:              # Dimension 3: axe-core serious violations
+    actual: 0
+    target: 0
+    status: pass
+  contract_drift:            # Dimension 4: consumer contracts failing (n/a if no consumers)
+    actual: 0
+    target: 0
+    status: pass             # or "n/a" if no API consumers
+  cross_flow_cuj_pass_rate:  # Dimension 6: critical user journey pass rate
+    actual: "100%"
+    target: "95%"
+    status: pass
+  browser_tier1_pass_rate:   # Dimension 9: Tier-1 browser matrix (n/a for non-frontend)
+    actual: "100%"
+    target: "100%"
+    status: pass             # or "n/a" for CLI/backend
+  capacity_headroom_cpu_pct: # Dimension 10: CPU headroom at projected peak (n/a for small projects)
+    actual: "42%"
+    target: "30%"
+    status: pass             # or "n/a" for small-scale projects
+  smoke_pass_rate:           # Dimension 14: post-deploy smoke (populated after staging deploy)
+    actual: "100%"
+    target: "100%"
+    status: pass
+  flow_gate_report:          # Dimension 16: Multi-Gate Flow verification
+    gate_0_complete: true    # all flows with ≥3 steps have §2.4 + §9.4 filled
+    gate_1_pr_coverage: true # all PRs touching flows include terminal-state tests
+    gate_3_ci_pass: true     # Decision Table CI all green; branch coverage ≥ 90%
+    gate_4_uat_signoff: true # UAT sign-off table signed
+    status: pass
+overall: WARN   # worst gate status across all dimensions (2 warns, no fails)
+```
+
+## 狀態語義
+
+| 狀態 | 意義 | 行動 |
+|--------|---------|--------|
+| `pass` | 達到或超過目標 | 無需任何行動 |
+| `warn` | 在可接受偏差範圍內（見各閘門政策） | 記錄原因；不阻擋發布 |
+| `fail` | 低於硬性下限 | **阻擋發布** |
+
+### 各閘門硬性下限
+
+| 閘門 | Warn 區間 | Fail 門檻 | Release Readiness 維度 |
+|------|-----------|----------------|----------------------------|
+| unit_coverage | target - 10pp 至 target | 低於 target - 10pp | （核心 RQM） |
+| mutation_score | target - 5pp 至 target | 低於 target - 5pp | （核心 RQM） |
+| sca_critical_cve | — | 任何 critical CVE = fail | Dim 2（安全） |
+| container_cve_critical | — | 任何 critical CVE = fail | Dim 2（安全） |
+| e2e_pass_rate | target - 3pp 至 target | 低於 target - 3pp | （核心 RQM） |
+| a11y_critical | — | > 0 = fail | Dim 3（a11y） |
+| a11y_serious | 專案門檻 | 專案門檻 + 1-2 | Dim 3（a11y） |
+| contract_drift | — | 任何紅燈 consumer contract = fail（若 n/a：跳過） | Dim 4（Contract） |
+| cross_flow_cuj_pass_rate | 90–95% | < 90% | Dim 6（跨流程回歸） |
+| browser_tier1_pass_rate | — | < 100%（若 n/a：跳過） | Dim 9（瀏覽器相容性） |
+| capacity_headroom_cpu_pct | 20–30% | < 20%（若 n/a：跳過） | Dim 10（容量） |
+| smoke_pass_rate | — | 任何 smoke 失敗 = fail | Dim 14（Smoke） |
+| flow_gate_report | gate_3_ci_pass=false | gate_0_complete=false 或 gate_4_uat_signoff=false | Dim 16（Multi-Gate Flow） |
+
+## 自動產生
+
+在所有閘門 job 完成後於 CI 產生 manifest：
+
+```bash
+#!/usr/bin/env bash
+# scripts/generate-quality-manifest.sh
+set -euo pipefail
+
+COVERAGE=$(node -e "
+  const r = JSON.parse(require('fs').readFileSync('coverage/coverage-summary.json'));
+  console.log(r.total.lines.pct.toFixed(1) + '%')
+")
+
+MUTATION=$(node -e "
+  const r = JSON.parse(require('fs').readFileSync('reports/mutation/mutation-testing-report.json'));
+  console.log(r.metrics.mutationScore.toFixed(1) + '%')
+")
+
+CRITICAL_CVE=$(jq '[.Results[]?.Vulnerabilities[]? | select(.Severity == "CRITICAL")] | length' trivy-report.json)
+
+cat > quality-manifest.yaml <<YAML
+release: ${RELEASE_TAG}
+generated_at: "$(date -u +%Y-%m-%dT%H:%M:%SZ)"
+commit: "${GITHUB_SHA:-$(git rev-parse HEAD)}"
+gates:
+  unit_coverage:
+    actual: "${COVERAGE}"
+    target: "80%"
+    status: $([ $(echo "$COVERAGE" | tr -d '%') -ge 80 ] && echo pass || echo warn)
+  sca_critical_cve:
+    actual: ${CRITICAL_CVE}
+    target: 0
+    status: $([ "$CRITICAL_CVE" -eq 0 ] && echo pass || echo fail)
+overall: $(grep -q "fail" quality-manifest.yaml && echo FAIL || grep -q "warn" quality-manifest.yaml && echo WARN || echo PASS)
+YAML
+```
+
+## 面向客戶的摘要
+
+在 YAML 之外同時產生 Markdown 表格，以便納入 release notes：
+
+```markdown
+## Release Quality Gates — app-commercial-1.2.0
+
+| Gate | Actual | Target | Status |
+|------|--------|--------|--------|
+| Unit Test Coverage | 73% | 80% | ⚠️ WARN |
+| Mutation Score | 62% | 60% | ✅ PASS |
+| Critical CVEs | 0 | 0 | ✅ PASS |
+...
+| **Overall** | | | ⚠️ WARN |
+```
+
+## 反模式
+
+- **手動撰寫 manifest** —— 違背初衷；必須由工具輸出產生
+- **對關鍵安全閘門使用 warn** —— `sca_critical_cve` 與 `container_cve_critical` 是二元判定
+- **在所有閘門跑完之前產生 manifest** —— 數值必須反映實際結果，而非估計值
+- **未將 manifest 附加到發布產物** —— 只存在於 git 歷史中的 manifest 客戶無法取得
+
+## 另請參閱
+
+- `verification-evidence.ai.yaml` — 稽核證據原則
+- `supply-chain-attestation.ai.yaml` — SBOM 與 provenance
+- `testing.ai.yaml` — 整體測試策略
+- `deployment-standards.ai.yaml` — 發布閘門整合
+
+
+**Scope**: universal

package/bundled/locales/zh-TW/core/replay-test.md

@@ -0,0 +1,102 @@
+---
+source: ../../../core/replay-test.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-10
+source_hash: 3ae2d3277b2d
+status: current
+---
+
+# Replay 測試標準
+
+> **語言**: [English](../../../core/replay-test.md) | 繁體中文
+
+---
+
+## 概述
+
+AI 代理系統透過複雜的多步驟管線與使用者互動。當客戶回報非預期行為時，重現確切的失敗情境往往相當困難——模型輸出可能是非確定性的、環境可能已發生變化，或確切的輸入內容可能不明確。黃金 fixture replay 透過在發現問題時序列化確切的輸入與預期輸出，解決了這個問題，從而實現確定性的回歸測試。
+
+## Fixture 格式
+
+```json
+{
+  "meta": {
+    "recorded": "2026-05-05",
+    "source": "customer-report | ci-regression | red-team | incident",
+    "description": "Human-readable description of what this tests"
+  },
+  "input": { /* exact component input */ },
+  "expected": { /* expected output fields to assert */ }
+}
+```
+
+## Fixture 命名規則
+
+`<component>-<outcome>-<description>.json`
+
+| 好的命名 | 不好的命名 |
+|---------|----------|
+| `guardian-deny-prod-drop-table.json` | `test1.json` |
+| `guardian-allow-dev-npm-test.json` | `fixture.json` |
+| `guardian-hitl-prod-irreversible.json` | `scenario_3.json` |
+
+## Replay 測試實作（Vitest）
+
+```typescript
+// SPDX-License-Identifier: AGPL-3.0-only
+import { readdirSync, readFileSync } from "fs"
+import { join } from "path"
+import { describe, it, expect } from "vitest"
+import { scoreReviewable } from "../scoring/risk-engine.js"
+
+const FIXTURES_DIR = join(__dirname, "..", "__fixtures__")
+
+interface ReplayFixture {
+  meta: { recorded: string; source: string; description: string }
+  input: Parameters<typeof scoreReviewable>[0]
+  expected: { decision: string }
+}
+
+function deriveDecision(score: number): string {
+  if (score >= 76) return "DENY"
+  if (score >= 51) return "REQUIRE_HITL"
+  return "ALLOW"
+}
+
+describe("Guardian replay fixtures", () => {
+  const fixtures = readdirSync(FIXTURES_DIR)
+    .filter(f => f.endsWith(".json"))
+    .map(f => ({
+      name: f,
+      fixture: JSON.parse(readFileSync(join(FIXTURES_DIR, f), "utf-8")) as ReplayFixture,
+    }))
+
+  for (const { name, fixture } of fixtures) {
+    it(`[${fixture.meta.source}] ${fixture.meta.description}`, () => {
+      const result = scoreReviewable(fixture.input)
+      const decision = deriveDecision(result.score)
+      expect(decision).toBe(fixture.expected.decision)
+    })
+  }
+})
+```
+
+## 錯誤回歸工作流程
+
+1. 客戶回報非預期的 Guardian 判定
+2. 擷取確切的 `Reviewable` 輸入（來自稽核日誌）
+3. 建立 fixture 檔案：`guardian-<outcome>-<description>.json`
+4. 在本地重現失敗（測試應當失敗）
+5. 修復錯誤
+6. 確認測試通過
+7. 此 fixture 現在永久防止回歸
+
+## 相關標準
+
+- [對抗性測試標準](../../../core/adversarial-test.md) — 紅隊語料庫
+- [驗證證據標準](../../../core/verification-evidence.md) — AC 可追溯性
+- [測試標準](../../../core/testing-standards.md) — 整體測試金字塔
+
+
+**Scope**: universal

package/bundled/locales/zh-TW/core/requirement-engineering.md

@@ -3,7 +3,7 @@ source: ../../../core/requirement-engineering.md
 source_version: 1.0.0
 translation_version: 1.0.0
 last_synced: 2026-03-24
-status: current
+status: stale
 ---
 
 # 需求工程標準

package/bundled/locales/zh-TW/core/resource-cost-boundary.md

@@ -0,0 +1,175 @@
+---
+source: ../../../core/resource-cost-boundary.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-17
+source_hash: a9be6a420041
+status: current
+---
+
+# 資源／成本邊界宣告標準
+
+> **Language**: [English](../../../core/resource-cost-boundary.md) | 繁體中文
+
+> **版本**: 1.0.0 | **狀態**: Active | **更新日期**: 2026-06-17
+> **AI 最佳化版本**: `ai/standards/resource-cost-boundary.ai.yaml`
+> **規格**: XSPEC-277 (cross-project/specs/XSPEC-277-resource-cost-boundary-standard.md)
+
+## 概述
+
+agentic / LLM 執行單元（pipeline run、agent、role）的資源消耗 **往往是隱性的**：token 用量、
+迴圈/迭代次數、重試次數、單次成本上限、wall-clock、呼叫頻率。當這些邊界未被 **顯式宣告與
+強制** 時，失控迴圈與 token 燒錢就是已知的 LLM-native 失敗模式——**cost burn**。
+
+本標準把 **資源/成本邊界做成顯式、機器可讀、fail-closed 的宣告**。任何 LLM 執行單元 MUST
+宣告其資源 budget；執行期 breach MUST 依宣告 fail-closed。它是邊界物質化（XSPEC-276）的
+**成本維度**：UDS 唯一沒有對應標準、又夠具體可做成 AI-executable 的那一維——故抽出為窄標準，
+而非塞進更廣（且重疊）的邊界框架。
+
+> **範圍**：本標準定義 *宣告機制*（budget 分類法、機器可讀的 `resource_budget:` 區塊、
+> fail-closed 閘門）。**budget 數值歸採用者/客戶**——那是專案決策。它規範的是「邊界*有沒有*
+> 被宣告與強制」，而非「該設*多少*數字」。執行引擎接線（如 VibeOps 主動成本治理執行器）屬
+> 下游採用議題；本標準是「宣告要哪些邊界」那一半，XSPEC-285 是「強制／治理」那一半。
+
+## 為何要做成標準（而非逐單元設定）
+
+VibeOps 已有成本機制，但 **分散且未標準化**——各自是點狀機制，沒有一份標準說「每個 LLM
+執行單元都 MUST 宣告其資源邊界、且 breach MUST fail-closed」。新單元（新 agent/role）很容易
+漏掉某個 budget → 無上限。本標準把這些點狀機制收斂到一份宣告。
+
+| 既有機制（成為參考實作）| budget 類別 |
+|---|---|
+| orchestrator quality profile `max_retries` / `max_retry_budget_usd`（per-task fix-loop）| retry / cost_usd |
+| BudgetGuard / PoC abort `max_cost_per_session_usd` / `min_cache_hit_ratio`（XSPEC-191）| cost_usd / rate |
+| Pareto Evolution Gate token-cost 維度（DEC-024）| token / cost_usd |
+| agent-loop `maxToolRounds` / `maxTotalTokens` | iteration / token |
+
+## 資源 Budget 分類法
+
+| 類別 | 邊界 | 典型 breach |
+|------|------|-------------|
+| `token` | input / output / total token 上限 | prompt/輸出爆量 |
+| `iteration` | 迴圈 / 迭代 / tool-round 上限 | 失控迴圈 |
+| `retry` | 重試上限 | 無上限重試 |
+| `cost_usd` | 單次 / 單 run / 單 session 成本天花板 | 靜默燒預算 |
+| `wallclock` | 逾時 | 卡死的 run |
+| `rate` | 呼叫頻率 | 呼叫風暴 |
+
+## 需求
+
+| ID | 規則 | 等級 |
+|----|------|------|
+| REQ-001 | 資源 budget 分類法——從一組標準類別宣告邊界 | MUST |
+| REQ-002 | 機器可讀的 `resource_budget:` 宣告（類別 + 上限 + breach 行為）| MUST |
+| REQ-003 | fail-closed 強制閘門（未宣告→warn/block；執行期 breach→abort）| MUST |
+| REQ-004 | 既有機制收斂為參考實作（不重造）| SHOULD |
+| REQ-005 | budget 數值主權——機制標準化、數值歸採用者 | SHOULD |
+
+### REQ-001 — 資源 Budget 分類法
+
+每個 LLM 執行單元的資源邊界 MUST 能從一組標準類別表達：`token`（input/output/total）、
+`iteration`（迴圈/迭代/tool-round 上限）、`retry`（重試上限）、`cost_usd`（單次 / 單 run /
+單 session 天花板）、`wallclock`（逾時）、`rate`（呼叫頻率）。單元不必宣告每個類別，但它**為
+安全而依賴**的類別 MUST 被宣告（被依賴卻無上限的類別＝違規）。
+
+### REQ-002 — 機器可讀宣告
+
+`resource_budget:` 區塊 MUST 可被宣告（內嵌於 plan / agent / role config），每筆含 **類別 +
+上限值 + breach 行為**（`warn` / `abort`）。它是生成器/runtime 可讀的一級工件——非散落設定、
+非事後 review 註記。
+
+```yaml
+resource_budget:
+  - kind: cost_usd        # 單 run 成本天花板
+    scope: per_run
+    limit: 3.00
+    on_breach: abort
+  - kind: iteration       # tool-round / 迴圈上限
+    limit: 60
+    on_breach: abort
+  - kind: retry
+    limit: 3
+    on_breach: warn
+  - kind: token
+    scope: total
+    limit: 400000
+    on_breach: abort
+```
+
+### REQ-003 — Fail-Closed 強制閘門
+
+quality gate `check-resource-budget` MUST：(a) 標出任何 **未宣告** budget 的 LLM 執行單元——
+預設 `warn`、嚴格模式 `block`；(b) 執行期 **breach** 時依宣告的 `on_breach` fail-closed
+（`abort` 中止該單元、`warn` 記錄並續行）。比照 `capability-declaration`（XSPEC-037）與治理
+閘門家族的 fail-closed 姿態——絕不靜默放行無上限。
+
+### REQ-004 — 收斂既有機制
+
+既有點狀機制（orchestrator `max_retries` / `max_retry_budget_usd`、XSPEC-191 BudgetGuard、
+DEC-024 Pareto token gate、XSPEC-270 right-sizing router）SHOULD **對映為本標準的參考實作**——
+統一、不重造。新單元繼承「宣告」習慣，而非重新發明 budget 旋鈕。
+
+### REQ-005 — Budget 數值主權
+
+宣告 *機制* 已標準化；*budget 數值*（實際天花板）歸採用者/客戶（專案/經濟決策）。標準規範的
+是「邊界*有沒有*被宣告與強制」，而非「該設*多少*數字」。
+
+## 原則
+
+| ID | 原則 |
+|----|------|
+| P-1 | 邊界顯式——資源 budget 被宣告，而非藏在某人腦中 |
+| P-2 | 機器可讀——生成器/runtime 可一級讀取 `resource_budget:` 區塊 |
+| P-3 | Fail-Closed——被依賴卻未宣告、或執行期 breach，則 block/abort；絕不靜默 |
+| P-4 | 不重造——既有點狀機制收斂為參考實作 |
+| P-5 | 數值主權——機制標準化，天花板數值歸採用者 |
+
+## 閘門時機
+
+```
+plan / agent / role config（resource_budget: 區塊）
+        │
+        ├─→ [check-resource-budget — 宣告檢查]  ← REQ-003(a)、run 前
+        │         被依賴卻未宣告 ──→ warn（嚴格：block）
+        ↓
+   run（token / iteration / retry / cost / wallclock / rate 量測）
+        │
+        └─→ 執行期 breach ──→ 依 on_breach fail-closed  ← REQ-003(b)（abort / warn）
+                                        │
+                                  記錄 breach 供稽核 / 成本治理執行器（XSPEC-285）
+```
+
+## 與鄰近標準的邊界（admission 條件 3）
+
+本標準 **只收成本/資源維度**，以避開讓更廣的邊界框架（XSPEC-276）無法進標準庫的重疊問題。
+
+| 鄰近標準 | 它的角度 | 為何不同（<30% 重疊）|
+|---|---|---|
+| `performance-standards` | 延遲 / 吞吐 *目標* | 目標，非 fail-closed 成本天花板 |
+| `model-selection` | 選模型 *tier* | tier 選擇，非 budget 強制 |
+| `capability-declaration`（XSPEC-037）| 顯式能力 + fail-closed | 能力面，非資源 budget |
+
+## 與既有標準的整合
+
+- **`performance-standards`** — performance 設延遲/吞吐目標；本標準設 fail-closed 資源天花板。
+  鄰接、互補、不同。
+- **`model-selection`** — right-sizing 選模型 tier；`cost_usd` breach 可 *驅動* 降級
+  （XSPEC-270 router），但 budget 宣告是本標準的職責。
+- **`test-governance`** — `check-resource-budget` 是受治理閘門；budget 宣告是受治理政策。
+- **`verification-evidence`** — breach/no-breach 的 run 報告是一種驗證證據（budget 守住 + 軌跡）。
+
+## 相關規格
+
+- XSPEC-277 — Resource / Cost Boundary 宣告標準完整規格（本標準來源）
+- XSPEC-276 — LLM-native 邊界物質化（母透鏡；成本為抽出的維度）
+- XSPEC-285 — VibeOps 主動成本治理（本標準的強制/執行器面）
+- XSPEC-191 — Unit-economics PoC / BudgetGuard（參考實作）
+- XSPEC-270 — 模型 right-sizing router（成本驅動降級）
+- XSPEC-037 — Capability declaration（本標準比照的 fail-closed 姿態）
+- DEC-024 — Pareto evolution token-cost gate（參考實作）
+
+## 變更紀錄
+
+| 版本 | 日期 | 變更 |
+|------|------|------|
+| v1.0.0 | 2026-06-17 | 初版——REQ-001~005：資源 budget 分類法、機器可讀的 `resource_budget:` 宣告、fail-closed `check-resource-budget` 閘門、既有機制收斂為參考實作、budget 數值主權（XSPEC-277） |

package/bundled/locales/zh-TW/core/reverse-engineering-standards.md

@@ -1,15 +1,15 @@
 ---
 source: ../../../core/reverse-engineering-standards.md
-source_version: 1.0.0
-translation_version: 1.0.0
-last_synced: 2026-01-19
+source_version: 1.2.0
+translation_version: 1.2.0
+last_synced: 2026-06-27
 status: current
 ---
 
 # 反向工程標準
 
-**版本**: 1.0.0
-**最後更新**: 2026-01-19
+**版本**: 1.2.0
+**最後更新**: 2026-06-27
 **適用範圍**: 所有需要將程式碼轉換為規格文件的專案
 
 > **語言**: [English](../../../core/reverse-engineering-standards.md) | [繁體中文](reverse-engineering-standards.md)
@@ -57,10 +57,52 @@ status: current
 |------|------|--------|-----------|
 | **程式碼掃描** | 分析程式碼結構、API、資料模型 | 技術清單 | [已確認] |
 | **測試分析** | 解析現有測試以取得驗收條件 | 草擬驗收條件 | [已確認]/[推論] |
+| **隱含規則掃描** | 掃描非 HTTP 持久化寫入路徑中未文件化的規則 | 隱含規則清單 + 三問解答 | [已確認]/[推論]/[未知] |
 | **缺口識別** | 列出需要人類輸入的未知項目 | 缺口分析文件 | [未知] 項目 |
 | **規格生成** | 生成草擬規格 | 草擬 SPEC-XXX.md | 混合確定性 |
 | **人類審查** | 利害關係人驗證與填補缺口 | 已驗證的規格 | [已確認] |
 
+> **註（v1.2.0）**：在程式碼掃描／測試分析之後、缺口識別之前，插入一個 **隱含規則掃描** 階段——詳見下方[隱含規則掃描（非 HTTP 持久化規則）](#隱含規則掃描非-http-持久化規則)。標準程式碼掃描只提取 HTTP 入口點與資料模型，但持久化欄位的值經常由**非 HTTP 路徑**（cron、佇列、計算欄、trigger、ORM hook）寫入，其業務規則從未被文件化——這是跨語言重寫或跨 DB 遷移時遺漏邏輯的最高發來源。
+
+---
+
+## 隱含規則掃描（非 HTTP 持久化規則）
+
+> **工作流程位置**：在程式碼掃描／測試分析之後、缺口識別之前。
+
+程式碼掃描提取的是透過 HTTP 可達的部分——路由、控制器、請求處理器。但一個持久化欄位的值經常在**請求路徑之外**被決定：夜間 cron 翻轉某個 status、佇列重試重新蓋上某個 timestamp、資料庫 trigger 推導出某個總額、ORM 生命週期 hook 把某個計數器歸零。這些規則鮮少被寫下來，因此只鏡像 HTTP 表面的重寫會悄悄遺漏它們。本階段機械化地推導出每一條非 HTTP 寫入路徑，並把每條隱含規則鎖為可驗證物。
+
+### 清單來源（derive，機械化）
+
+對舊系統掃描每一條**非 HTTP 持久化寫入路徑**，涵蓋四類：
+
+1. **排程**——crontab 項目、scheduler 設定、`@Scheduled` 類註解、批次作業
+2. **佇列**——queue consumer、job handler、背景 worker、message listener
+3. **DB 層**——trigger、computed/generated column、`DEFAULT` 運算式、check constraint
+4. **ORM 生命週期**——`beforeSave`/`afterSave`/observer/model-event hook、會變更持久狀態的 middleware
+
+### Oracle（detect）——每欄三問
+
+對每個由非 HTTP 路徑寫入的持久化欄位，回答並鎖定**三個問題**：
+
+| 問題 | 要擷取的內容 |
+|------|-------------|
+| **何時設值（SET）？** | 首次賦值的條件／觸發點 |
+| **何時被覆寫（OVERWRITE）？** | 之後每一次寫入——**含非同步覆寫**（連回 post-cutover 聚合對帳） |
+| **何時歸零／重置（RESET）？** | 清除或回復為預設值的條件 |
+
+- 把 **Devil's Advocate（魔鬼代言人）** 質疑從 HTTP 層擴展到**涵蓋非 HTTP 路徑**：對 cron 條件、佇列重試、計算欄、trigger 邏輯，套用同樣的五類對抗式質疑（邊界、順序、並發、失敗/重試、null/預設）。
+- 為每條擷取的規則標註確定性層級：`[已確認]`（附 `file:line` 引用）／`[推論]`／`[未知]`。每個 `[未知]` 都交給缺口識別由人類處理——絕不臆測。
+- **輸出**：把每條隱含規則鎖為 **behavior-snapshot 場景** 或 **對帳不變量**（例如 `SUM(cost) GROUP BY status` 須跨 cutover 維持），讓規則成為可重跑的 oracle 而非散文。
+
+### Gate 時機
+
+pre-flight（規劃期）。任何三問未獲解答的非 HTTP 寫入欄位會被標為 `not_implemented` 並 **block cutover**——未宣告的隱含規則視為已知遺漏風險，而非可接受的缺口。
+
+### PHP 專屬補述：鬆散比較／type juggling
+
+掃描 PHP 寫入路徑時，須額外標記**鬆散比較／type juggling** 依賴點：`==` 比較、`"0"` / `""` / `null` / `0` 的 truthy/falsy 行為、字串自動轉數字。這些在強型別目標（如 C#/.NET）下沒有直接對應，因此它們所編碼的隱含規則是跨語言重寫時被悄悄丟失邏輯的高發來源。對每個此類位置標 `[已確認]` 並附 `file:line`，並把預期語義鎖為一條明確規則。
+
 ---
 
 ## 核心原則
@@ -306,6 +348,21 @@ Feature: 購物車
 
 ---
 
+## 失敗處理與升級
+
+反向工程從現有程式碼推論意圖；某些輸入無法被安全分析。本節定義失敗 → 升級 → 重新驗證的路徑，使低信心或無法解析的輸入永遠不會產出一份看似權威的規格。
+
+| 條件 | 觸發 | 行動 | 重新驗證 |
+|------|------|------|---------|
+| **解析失敗** | 來源無法解析（不支援的語言、損壞的語法樹） | 將該單元標為 `[未知]` 並回報語言/檔案；升級至人類領域專家。不為其產出任何推論行為。 | 經工具/修正後可解析 |
+| **高未知比例** | `[未知]` 項目超過信心門檻（預設 > 50% 的行為） | 暫停規格定稿；要求領域專家訪談先填補 `[未知]` 項目。不交付多數靠猜測的規格。 | 未知比例低於門檻 |
+| **被推翻的推論** | 程式碼與先前推論的行為相矛盾 | 將該項降級為 `[假設]` 並升級至程式碼負責人；絕不把被推翻的推論記為 `[已確認]`。 | 負責人確認或更正 |
+| **測試分析失敗** | 現有測試無法執行/解析以提取行為 | 退回僅做靜態分析；將受影響行為標為 `[推論]`（較低確定性），絕不標 `[已確認]`。 | — |
+
+**規則 RE-FAIL-001（必要）**：解析失敗或超過門檻的 `[未知]` 比例，**必須** block 規格定稿並升級至人類——絕不把低於信心門檻的規格呈現為權威。
+
+---
+
 ## 應避免的反模式
 
 ### 程式碼分析反模式
@@ -389,6 +446,8 @@ Feature: 購物車
 
 | 版本 | 日期 | 變更內容 |
 |------|------|----------|
+| 1.2.0 | 2026-06-27 | 新增：隱含規則掃描階段（非 HTTP 持久化寫入路徑擷取）——4 類 derive 清單 + 三問 oracle + 非 HTTP Devil's Advocate + PHP type-juggling 補述 + 確定性/`file:line`（XSPEC-284 R4/AC-8） |
+| 1.1.0 | 2026-06-18 | 新增：失敗處理與升級章節——解析失敗／高未知比例／被推翻推論的升級 + 規則 RE-FAIL-001（XSPEC-292 T7） |
 | 1.0.0 | 2026-01-19 | 初始發布 |
 
 ---