universal-dev-standards 6.4.0 → 6.6.0

package/bundled/core/mutation-testing.md

@@ -1,7 +1,7 @@
 # Mutation Testing Standards
 
-**Version**: 1.0.0
-**Last Updated**: 2026-05-04
+**Version**: 1.1.0
+**Last Updated**: 2026-08-14
 **Applicability**: All software projects with unit/integration tests
 **Scope**: universal
 **Industry Standards**: ISTQB Foundation Syllabus (test effectiveness metrics)
@@ -30,6 +30,42 @@ A test with `expect(x).toBeDefined()` can achieve 100% line coverage but survive
 
 ---
 
+## Attribution: Kill Is Credited to the First Failing Test
+
+`Killed` means *some* test in the run failed against the mutant — most tools do not record *which* test killed it, and none records *which test level*. A 7/7 kill score therefore verifies the **whole suite that ran against the mutant**, not any single test, and not any single test level (unit vs. integration vs. property).
+
+**Consequence**: "the property suite verifies X" is not a claim an aggregate mutation run supports. To support it, re-run mutation testing with *only* the property suite active:
+
+```bash
+npx stryker run --mutate 'src/module/**' -- --project=property
+```
+
+If the isolated run kills fewer mutants than the aggregate run, the gap is exactly what the unit/integration tests were quietly covering.
+
+**Rule**: high-risk modules (the same set the 80% threshold applies to — auth/license/payment/security) must re-run mutants against the property suite in isolation before any claim of "property-verified" is made.
+
+---
+
+## One-Sided Invariants Miss Fail-Closed Defects
+
+A property like "output never exceeds the limit" is one-sided: it cannot detect a mutant that makes the code **fail closed** — reject everything, including valid input — because a fail-closed mutant never produces an over-limit output. The mutation score looks unaffected while an entire class of defect (denial of service, wrongly rejected requests) is invisible to the suite.
+
+**Fix**: pair every one-sided invariant with its opposite boundary. "Never exceeds the limit" needs a companion property — e.g. "accepts everything at or below the limit" — so that both over-permissive and over-restrictive mutants have a path to detection.
+
+---
+
+## Equivalent Mutants Are Not Survivors to Chase
+
+A surviving mutant is not automatically a test gap. Some mutants are **semantically equivalent** to the original — no input can distinguish their behavior — and no test can kill them, regardless of how it's written. Forcing a kill with an assertion that exists only to move the score (`expect(x).toBeDefined()` on an incidental value) produces a hollow test without closing any real gap.
+
+**Required classification for every reviewed survivor**:
+- **Genuine gap** → write a test that exercises the distinguishing behavior.
+- **`equivalent, because <reason>`** → recorded with the input(s) checked to reach that conclusion.
+
+An unclassified survivor is not the same as a classified-equivalent one. Only a classified-equivalent mutant may be excluded from the score's denominator.
+
+---
+
 ## Tools
 
 | Language | Tool | Command |
@@ -87,6 +123,9 @@ npm install --save-dev @stryker-mutator/core @stryker-mutator/vitest-runner
 - Adding mutation testing to CI for every PR (too slow)
 - Accepting AI-generated tests without mutation score validation
 - Killing mutations by adding `toBeDefined()` assertions
+- Claiming "the property suite verifies X" from an aggregate (not isolated) mutation run
+- Using only a one-sided invariant for a property that has a fail-closed failure mode
+- Forcing a kill on a semantically equivalent mutant instead of classifying it `equivalent, because <reason>`
 
 ---
 

package/bundled/core/spec-driven-development.md

@@ -1,7 +1,7 @@
 # Spec-Driven Development (SDD) Standards
 
-**Version**: 2.3.0
-**Last Updated**: 2026-06-08
+**Version**: 2.4.0
+**Last Updated**: 2026-08-17
 **Applicability**: All projects adopting Spec-Driven Development
 **Scope**: universal
 **Industry Standards**: None (Emerging 2025+ methodology)
@@ -50,6 +50,61 @@ UDS supports two AC notations. **GWT is the default and preferred** (Forward Der
 
 Provide **GWT or EARS** per AC (`.ac.yaml`: `given/when/then` **or** `ears`). Prefer GWT for BDD-derivable behaviour; reach for EARS when GWT feels forced. Do not require both; do not remove GWT.
 
+## An AC With No Verification Item Is Not an AC | 沒有驗證項的 AC 不是 AC
+
+Every acceptance criterion must have a **verification item that points at it** — a test, a
+check, a gate, or an explicitly recorded manual step. An AC that no verification item
+references is a **promise nobody kept**, and it does not fail loudly: it simply stops being
+true while the spec continues to assert it.
+
+每一條驗收標準都必須有一個**指向它的驗證項**——測試、檢查、閘門，或一則明確記錄的
+手動步驟。沒有任何驗證項引用的 AC 是**一張沒有人兌現的支票**，而且它不會大聲失敗：
+它只是安靜地停止成立，而規格繼續宣稱它為真。
+
+**Rule**: an AC without a verification item must be **demoted to a design intent**, not
+carried as an AC. Demotion is honest; an unverified AC is not.
+**規則**：沒有驗證項的 AC 必須**降級為設計意圖**，不得繼續掛在 AC 欄。降級是誠實的，
+未經驗證的 AC 不是。
+
+### The measured instance | 實測案例
+
+A 2026-05-14 spec carried `AC-7: the legacy system-report is fully preserved, no
+regression`. Its Test Plan had seven items and **none of them pointed at AC-7**. The
+report's timer was disabled and its deploy function was never called — **from the same day
+the AC was written**. It was found three months later, by accident, while verifying an
+unrelated install.
+
+**It was never wired to a check and later came loose. It was never wired at all.**
+
+一份 2026-05-14 的規格寫著 `AC-7：舊版系統報告完整保留（無回歸）`。它的 Test Plan
+有七項，**沒有一項指向 AC-7**。該報告的 timer 是 disabled、部署函式從未被呼叫——
+**從那條 AC 被寫下的同一天起**。三個月後在驗證另一件無關的安裝時偶然發現。
+
+**它不是後來斷線的。它從來沒有被接上過。**
+
+### Why "someone will check it" is not a verification item
+
+A verification item must be **executable or recorded**, not implied. "The reviewer will
+notice" is not one, because a reviewer reads the spec — and the spec says the AC holds.
+An AC is a claim **about the world**, and only something that touches the world can
+falsify it.
+
+「有人會檢查」不是驗證項。它必須**可執行或有紀錄**，不能是隱含的。「審查者會注意到」
+不算——因為審查者讀的是規格，而規格說那條 AC 成立。**AC 是一個關於世界的宣稱，
+只有碰得到世界的東西才能證偽它。**
+
+### Related | 關聯
+
+- [verification-evidence](verification-evidence.md) — VE-011 requires evidence to come from a
+  fresh run **after the last edit**; this standard is the upstream question of whether any
+  run was ever pointed at the claim in the first place.
+- [class-level-fix](class-level-fix.md) — the same discipline applied to *scope*: traverse the
+  set rather than enumerate it.
+
+## What's New in v2.4.0
+
+- **An AC with no verification item is not an AC** (XSPEC-380 R5). Every acceptance criterion must have a verification item pointing at it; one that has none is demoted to a design intent rather than carried as an AC. Measured instance: a spec's `AC-7` had no matching Test Plan item, and the thing it protected stopped running **on the day the AC was written** — found three months later by accident. An AC is a claim about the world, and only something that touches the world can falsify it.
+
 ## What's New in v2.3.0
 
 - **EARS notation** as an optional AC format (XSPEC-263): 5 EARS templates + `.ac.yaml` `ears` field. GWT remains default & preferred; `given/when/then` relaxed from `required` (backward compatible).

package/bundled/core/test-governance.md

@@ -2,8 +2,8 @@
 
 > **Language**: English | [繁體中文](../locales/zh-TW/core/test-governance.md)
 
-**Version**: 1.1.0
-**Last Updated**: 2026-04-20
+**Version**: 1.2.0
+**Last Updated**: 2026-08-14
 **Applicability**: All software projects
 **Scope**: universal
 
@@ -62,6 +62,23 @@ Run static analysis tools before test execution:
 - `eslint .` (TypeScript/JavaScript)
 - `mypy .` (Python type checking)
 
+### Threshold Gates Must Fail Closed
+
+A measurement layer that prints a percentage but exits `0` regardless of whether that number cleared its threshold is a report, not a gate. It stays green while the number it prints drifts downward across commits, and nothing stops the next merge.
+
+Every check with a pass/fail threshold — coverage, lint, mutation score, or any other bounded metric — must translate "below threshold" into a non-zero exit code, using the tool's own enforcement flag rather than a wrapper script that re-parses printed output after the fact:
+
+| Tool | Fail-closed flag |
+|------|-------------------|
+| pytest-cov | `--cov-fail-under=<N>` |
+| coverage.py | `coverage report --fail-under=<N>` |
+| diff-cover | `diff-cover coverage.xml --fail-under=<N>` |
+| nyc / Istanbul | `--check-coverage --lines <N>` |
+| Stryker Mutator | `thresholds.break` in `stryker.config.json` |
+| ESLint | `--max-warnings 0` |
+
+A wrapper script that computes the number, prints it, and always `exit 0` satisfies neither this rule nor `verification-evidence`'s Evidence Validity rule 1 — the tool's exit code no longer carries any information about the artefact it measured.
+
 ---
 
 ## Completion Criteria
@@ -124,6 +141,7 @@ Release completion criteria (checked before release):
 | pyramid-compliance | Planning test strategy | Follow the 70/20/7/3 pyramid ratio as a guideline. Deviation is acceptable with documented justification | Required |
 | sit-isolation | Running system tests | System tests should stub external dependencies but use real internal services. Use SIT environment for system-level validation | Recommended |
 | test-execution-continuity | Adding or completing a test case | A test case must be wired to an automated execution trigger (CI gate, build hook, or scheduled run). A test that exists but is never run provides false confidence and is worse than no test at all. Verify that execution history exists before marking test coverage as complete. | Required |
+| fail-closed-threshold-gate | Configuring or reviewing any coverage/lint/mutation/other threshold check | The check must use the tool's fail-under (or equivalent) enforcement flag so it exits non-zero when the threshold is not met. A script that only prints the number and always exits 0 is a report, not a gate, and does not satisfy this rule | Required |
 
 ---
 
@@ -139,6 +157,7 @@ Release completion criteria (checked before release):
 - [Testing Standards](testing-standards.md) — Testing pyramid and coverage ratios
 - [Test Completeness Dimensions](test-completeness-dimensions.md) — 8-dimension test coverage
 - [Check-in Standards](checkin-standards.md) — Pre-commit quality gates
+- [Verification Evidence](verification-evidence.md) — Evidence Validity governs how to *read* an exit code once produced; `fail-closed-threshold-gate` governs how the gate must be *built* so that exit code carries real information in the first place
 
 ---
 
@@ -147,3 +166,4 @@ Release completion criteria (checked before release):
 | Version | Date | Changes |
 |---------|------|---------|
 | 1.0.0 | 2026-03-11 | Initial version — test policy, completion criteria, environment management |
+| 1.2.0 | 2026-08-14 | Added `fail-closed-threshold-gate` — coverage/lint/mutation threshold checks must exit non-zero below threshold, not just print the number |

package/bundled/core/translation-lifecycle-standards.md

@@ -2,8 +2,8 @@
 
 > **Language**: English | [繁體中文](../locales/zh-TW/core/translation-lifecycle-standards.md)
 
-**Version**: 1.0.0
-**Last Updated**: 2026-04-20
+**Version**: 1.0.1
+**Last Updated**: 2026-08-12
 **Status**: Trial (expires 2026-10-20)
 **Applicability**: All projects with multi-language documentation
 **Scope**: universal
@@ -100,7 +100,7 @@ When updating a translation after a source change:
 
 When `core/*.md` files are staged, the pre-commit hook runs `check-translation-sync.sh` and shows OUTDATED warnings. The hook **never blocks** the commit (blocking at commit time is too disruptive) — it is a reminder only.
 
-Setup: `./scripts/install-hooks.sh` (one-time, after clone)
+Setup: `node scripts/install-hooks.mjs` (one-time, after clone; `./scripts/install-hooks.sh` is a POSIX wrapper around the same logic)
 
 ### Release Gate (`check-translation-sync.sh`)
 
@@ -112,9 +112,9 @@ bash scripts/check-translation-sync.sh
 # exit 0 if only MINOR/PATCH gaps (with advisory output)
 ```
 
-### Version Bump Integration (`bump-version.sh`)
+### Version Bump Integration (`bump-version.mjs`)
 
-`bump-version.sh` automatically runs `check-translation-sync.sh` after version files are updated, showing the translation health snapshot at the moment of bump — giving the author immediate feedback on what needs updating before publish.
+`bump-version.mjs` automatically runs `check-translation-sync.sh` after version files are updated, showing the translation health snapshot at the moment of bump — giving the author immediate feedback on what needs updating before publish. `scripts/bump-version.sh` is a thin POSIX wrapper that execs `bump-version.mjs` — the bump logic itself lives only in the `.mjs` file.
 
 ---
 
@@ -159,4 +159,4 @@ bash scripts/check-translation-sync.sh
 - [standard-admission-criteria.md](standard-admission-criteria.md) — How new standards are admitted (triggers TRANS-001)
 - `scripts/check-translation-sync.sh` — Implementation of this standard's automation rules
 - `.githooks/pre-commit` — Pre-commit integration
-- `scripts/install-hooks.sh` — Hook installation
+- `scripts/install-hooks.mjs` — Hook installation (`scripts/install-hooks.sh` is a POSIX wrapper)

package/bundled/core/verification-evidence.md

@@ -2,8 +2,8 @@
 
 > **Language**: English | [繁體中文](../locales/zh-TW/core/verification-evidence.md)
 
-**Version**: 1.2.0
-**Last Updated**: 2026-07-17
+**Version**: 1.3.0
+**Last Updated**: 2026-08-14
 **Applicability**: All AI-assisted development workflows
 **Scope**: universal
 **Inspired by**: [Superpowers](https://github.com/obra/superpowers) — verification-before-completion (MIT)
@@ -39,6 +39,7 @@ The first is a form of hallucination. **The second is not** — nothing was inve
 | Environment Layer | Which environment the evidence was collected from (`local` / `uat` / `prd`) |
 | Evidence Validity | Whether the evidence *itself* is trustworthy — i.e. whether the verification command actually ran and actually measured what it claims |
 | Silent Tool Failure | A verification command that fails to run, or runs without measuring anything, yet produces output indistinguishable from a genuine result |
+| Evidence Freshness | Whether evidence was produced by a run executed *after* the most recent edit to the code, prompt, or configuration under test — not carried over from a run against an earlier state |
 
 ---
 
@@ -178,7 +179,7 @@ The Iron Law stops an agent from claiming success **without** evidence. It does
 
 This is not hallucination. Hallucination is inventing what you did not check. This is the reverse: **you checked, and the checking tool lied to you.** The `anti-hallucination` standard does not cover it — every prohibition there is a form of "don't make things up", and here nothing was made up.
 
-### The four validity rules
+### The five validity rules
 
 **1. `exit_code = 0` means success only for tools that return 0 on success.**
 
@@ -196,6 +197,20 @@ Suppressing stderr (`2>/dev/null` and equivalents) silences precisely the channe
 
 With `set -o pipefail`, `producer | grep -q pattern` inherits a non-zero from `producer` regardless of whether `grep` matched. When the decision depends on content, **capture the output first, then evaluate it** — do not let a pipeline collapse two questions into one number.
 
+**5. Evidence must postdate the last edit to what it verifies.**
+
+A verification run captured *before* the most recent change to the code, prompt, or configuration under test proves something — just not the thing being claimed. The trap is silent: the full suite ran green, something was edited afterward (a prompt, a config value, a threshold), and only a narrower check (lint, a partial suite) ran after that edit — yet the earlier green run gets cited as evidence for the current state. **Evidence is a single fresh execution captured after the last edit, not the most recent execution that happened to pass.**
+
+### Stale Evidence — a failure shape
+
+Rules 1–4 assume the evidence was collected in the right place and read correctly. They say nothing about *when*. A command that ran, measured correctly, and returned a true result can still fail to support a completion claim, if something changed after it ran.
+
+**Shape of the failure**: the full test suite runs and passes. Afterward, a prompt or a configuration value is edited — no test exercises that edit directly. Before committing, only `lint` is run, and it also passes. The commit is made citing "tests pass" as evidence. CI then fails, red on a test that pins the exact content that was just changed — the suite that "passed" ran against a version of the artefact that no longer exists by the time the claim was made.
+
+規則 1–4 假設證據**在正確的地方**被蒐集且被正確解讀。它們沒有回答「**什麼時候**」這個問題。一個執行了、量測正確、也回傳真結果的指令，依然可能撐不起一個完成聲明——如果它跑完之後有東西又變了。
+
+**失效樣態**：完整測試套件跑過且通過。之後，某個提示詞或設定值被編輯——沒有任何測試直接涵蓋那次編輯。提交前只跑了 `lint`，也通過。commit 引用「測試通過」作為證據。接著 CI 紅在一個釘住剛剛被改掉那份內容的測試上——那個「通過」的套件，跑的是一個在主張被提出時已經不存在的版本。
+
 ### Evidence of the failure mode
 
 The following are real verification commands run by an AI agent on 2026-07-17, each of which produced a confident, wrong conclusion that was then reported as fact:
@@ -225,11 +240,32 @@ The following are real verification commands run by an AI agent on 2026-07-17, e
 | `verification_evidence` exists but `exit_code ≠ 0` | Mark as **verification failed** — **unless** the tool is known to exit non-zero in the state under test (Evidence Validity rule 1), in which case judge by output |
 | `exit_code = 0` but the command could not have measured the claim | Mark as **unverified** — a passing command that ran in the wrong place, or never ran at all, is not evidence |
 | Evidence asserts absence (`0`, empty, "not found") | Mark as **unverified** until the query tool is shown to have executed successfully |
+| Evidence's timestamp precedes the most recent edit to what it verifies | Mark as **stale** — re-run after the edit; do not cite the earlier pass |
 | Multiple verification steps | **All** steps must pass |
 | Agent provides evidence for wrong command | Mark as **unverified** |
 
 ---
 
+## Narrow Coverage Must Be Registered, Not Just Disclosed
+
+Evidence Validity and the Environment Stratification Matrix both allow a documented gap — an environment that cannot exercise a dimension, a check whose measurement is narrower than the claim it is cited for. A written disclosure of that gap is not, by itself, enough: prose is cheaper than closing the gap, and a disclosure that is never revisited quietly becomes a permanent excuse for evidence that no longer supports what it is used to support.
+
+**Requirement**: any such documented gap must also be registered in a dated exception inventory — external to the standard or the matrix entry itself — naming the gap, its reason, and a review or expiry date. A footnote with no corresponding inventory entry does not satisfy this rule.
+
+**Falsifiable condition**: an inventory entry left unchanged across two consecutive review cycles means the disclosure has become an escape hatch, and the rule is violated for that entry — not "partially satisfied", violated. The inventory's location, format, and cadence are left to the adopting project; this standard requires only that one exists and that entries move.
+
+This is the same requirement as [class-level-fix](class-level-fix.md)'s narrow-coverage rule, applied to verification evidence rather than to class-level checks: in both cases, a disclosure that never has to change is not a disclosure — it is a permanent exemption wearing a disclosure's clothes.
+
+Evidence Validity 與 Environment Stratification Matrix 都允許一個被記錄下來的缺口——一個無法驗證某個維度的環境層次、一項量測範圍窄於它所支撐主張的檢查。單純寫下這個缺口本身並不夠：散文比真正補上缺口便宜，而一個從未被重新檢視的揭露，會悄悄變成「這份證據其實撐不起它被用來支撐的主張」的永久藉口。
+
+**要求**：任何這一類已記錄的缺口，必須同時登記到一份**帶到期日的例外清冊**——獨立於標準本文或 matrix 條目本身之外——指名缺口、其成因、並附上覆核或到期日期。只有一則註腳而沒有對應清冊條目，不滿足本條。
+
+**可證偽條件**：一則清冊條目連續兩期審查都未變動，代表該揭露已經變成逃生口，本條對該條目失效——不是「部分滿足」，是失效。清冊放在哪裡、什麼格式、多久審一次，留給採用專案自行決定；本標準只要求「有這麼一份東西存在，且條目會動」。
+
+這與 [class-level-fix](class-level-fix.md) 的窄涵蓋規則是同一條要求，套用在驗證證據而非類別層檢查上：兩種情況下，一個永遠不必改變的揭露都不是揭露，是一份穿著揭露外衣的永久豁免。
+
+---
+
 ## Rules
 
 | ID | Trigger | Action | Priority |
@@ -244,6 +280,8 @@ The following are real verification commands run by an AI agent on 2026-07-17, e
 | VE-008 | Evidence claims absence (`0`, empty output, "not found") | Invalid until the query tool is shown to have run successfully. Re-run without stderr suppression | High |
 | VE-009 | An existence/absence check suppresses stderr (`2>/dev/null` or equivalent) | Evidence does not stand. Re-run with stderr visible | High |
 | VE-010 | Evidence's `exit_code` comes from a pipeline (esp. under `pipefail`) | The code attributes to no single stage. Capture the output and evaluate content instead | Medium |
+| VE-011 | Evidence's execution timestamp precedes the most recent edit to the artefact it claims to verify | Mark **stale** — not valid evidence for the current state; require a fresh single run captured after the edit | High |
+| VE-012 | A documented evidence/coverage gap (environment-stratification ⚠️/❌, or any check narrower than the claim it supports) has no entry in a dated exception inventory | Disclosure alone does not satisfy this rule — require a registered, dated inventory entry naming the gap and its review/expiry | Required |
 
 ---
 
@@ -323,6 +361,7 @@ verification_evidence:
 - [Testing Standards](testing-standards.md) — how the tests that produce most evidence are written
 - [Agent Dispatch](agent-dispatch.md) — delegated work returns claims that need this standard applied to them
 - [Deployment Standards](deployment-standards.md) — defines the Environment Stratification Responsibility Matrix referenced by VE-005 / VE-006
+- [Class-Level Fix](class-level-fix.md) — the same narrow-coverage-must-be-registered requirement (VE-012), applied to class-level checks rather than to verification evidence
 
 ---
 

package/bundled/locales/zh-CN/CHANGELOG.md

@@ -1,8 +1,8 @@
 ---
 source: ../../CHANGELOG.md
-source_version: 6.4.0
-translation_version: 6.4.0
-last_synced: 2026-08-10
+source_version: 6.6.0
+translation_version: 6.6.0
+last_synced: 2026-08-17
 status: current
 ---
 
@@ -17,6 +17,27 @@ status: current
 
 ## [Unreleased]
 
+## [6.6.0] - 2026-08-17
+
+### 新增
+
+- **`ai-response-navigation` 1.1.0 → 1.2.0 —— 可选规则 R7–R9，管答案本身**（XSPEC 借鉴 B-10，来源 [`ayghri/i-have-adhd`](https://github.com/ayghri/i-have-adhd)，MIT）。规则 1–6 管的是答案**之后**要附什么：导航区块、标记过的推荐、匹配响应类型的模板。**答案本身没有任何规则在管。** 于是一个响应可以把结论埋在一整面证据底下，只要结尾附上正确的导航区块，它仍然满足**本标准的每一条**——而找不到答案的读者，不会因为被告知下一步而得到帮助。
+  - **R7 —— 先讲发现，不要先讲过程。** *触发*：回答问题、汇报调查结果、或提出决策的响应。第一行写**查到了什么**或**该做什么**——不是方法、不是把问题复述一遍、不是回答的计划。证据（`file:line`、命令输出、表格、测量数字）是**佐证**，应放在它所支持的论断之后；以证据开场会迫使读者自行重建结论，而那正是他请你做的工作。本条规范的是**顺序**，**不**代表可以省略证据。
+  - **R8 —— 每一轮重述进度。** *触发*：跨 3 轮以上的对话，或含 3 个以上步骤的任务。用一行说明工作进行到哪里。不能假设读者能在消息之间记住「我们在 5 步中的第 3 步」，而重述它的成本是一个句子。与模板 4（进行中）互补：**R8 管开头，模板管结尾。**
+  - **R9 —— 不要开场白。** *触发*：任何实质性响应。本条把一项既有禁令一般化：[`anti-sycophancy-prompting`](../../core/anti-sycophancy-prompting.md) 已经禁止「以正面肯定开场批评」，但**仅限批评情境**。R9 把同一项禁令扩及每一个实质响应，理由不同——不是为了防拍马屁，而是为了消除它在读者与答案之间制造的延迟。**R9 不适用于结语**；R1 的导航区块要求依然成立。
+  - **来源十条只取三条，其余七条的淘汰理由写进标准本文**，不是只写在待办清单里。两条与 R1–R2 重复。三条与本标准或其他标准冲突：它的「不要 recap／不要结语」**与 R1 的导航区块直接矛盾**；它的「列表上限 5 项」会截断证据表格与遍历分母；它的「具体时间估计」已由 [`estimation-standards`](../../core/estimation-standards.md) 涵盖。
+  - **可选的语义同 R6**（模型级别标注）：采用者不必启用、既有 skill 不需回头补，项目**可以**在自己的配置中把任一条提升为必须。**不可选的是每一条都带有精确的触发条件**——一条松到永远不会启动的规则，与没有这条规则无从分辨，那正是 XSPEC-378 记录的失效模式。
+  - **扩充既有标准而非新建一支**：再开一支管「AI 怎么对人类写回答」的标准，会让同一条轴出现两个实现。
+
+## [6.5.0] - 2026-08-14
+
+> ⚠️ **本节简体译文待补。** 本次发布包含两批内容：XSPEC 借鉴 B-01 的五条标准补强
+> （`verification-evidence` VE-011/VE-012、`test-governance` 门槛闸须 fail-closed、
+> `mutation-testing` kill 归因、`class-level-fix` 负向控制极限声明），
+> 以及 XSPEC-362 的 `model-selection` 2.1.0 与 `agent-dispatch` 复位。
+> 完整内容见 [English](../../CHANGELOG.md) 或 [繁體中文](../zh-TW/CHANGELOG.md)。
+> **此处明示未翻译，而非以繁体内容充当简体译文。**
+
 ## [6.4.0] - 2026-08-10
 
 ### 新增

package/bundled/locales/zh-CN/README.md

@@ -15,7 +15,7 @@ status: current
 
 > **语言**: [English](../../README.md) | [繁體中文](../zh-TW/README.md) | 简体中文
 
-**版本**: 6.4.0 | **发布日期**: 2026-08-10 | **授权**: [双重授权](../../LICENSE) (CC BY 4.0 + MIT)
+**版本**: 6.6.0 | **发布日期**: 2026-08-17 | **授权**: [双重授权](../../LICENSE) (CC BY 4.0 + MIT)
 
 语言无关、框架无关的软件项目文档标准。通过 AI 原生工作流，确保不同技术栈之间的一致性、质量和可维护性。
 

package/bundled/locales/zh-CN/SECURITY.md

@@ -13,7 +13,7 @@ status: current
 <!-- UDS_SUPPORTED_VERSIONS_START -->
 | 版本 | 支持状态 |
 |------|--------|
-| 6.3.10 | ✅ 最新正式版 |
+| 6.6.0 | ✅ 最新正式版 |
 | < 6.0.0 | ❌ 已终止支持 |
 <!-- UDS_SUPPORTED_VERSIONS_END -->
 

package/bundled/locales/zh-CN/core/ai-response-navigation.md

@@ -1,8 +1,8 @@
 ---
 source: ../../../core/ai-response-navigation.md
-source_version: 1.1.0
-translation_version: 1.1.0
-last_synced: 2026-06-10
+source_version: 1.2.0
+translation_version: 1.2.0
+last_synced: 2026-08-17
 status: current
 ---
 
@@ -10,8 +10,8 @@ status: current
 
 > **语言**: [English](../../../core/ai-response-navigation.md) | [繁體中文](../../zh-TW/core/ai-response-navigation.md) | 简体中文
 
-**版本**: 1.1.0
-**最后更新**: 2026-06-10
+**版本**: 1.2.0
+**最后更新**: 2026-08-17
 **适用范围**: 所有使用 AI 辅助开发的项目
 **范围**: universal
 **行业标准**: 无（新兴 AI 工具实践）
@@ -27,6 +27,11 @@ status: current
 
 **解决方案**：在每个实质性 AI 响应结尾附加标准化的「导航区块」，包含情境模板、推荐标记和弹性选项数量。
 
+**范围注记（v1.2.0）**：规则 1–6 管的是答案**之后**要附什么。规则 7–9 于 1.2.0 新增、属**可选**，
+管的是答案本身：先讲发现、每轮重述进度、不要开场白。新增的理由是——
+一个响应可以满足规则 1–6 的每一条，同时把结论埋起来；
+**而找不到答案的读者，不会因为结尾有一个正确的导航区块被告知下一步而得到帮助。**
+
 ---
 
 ## 核心规则
@@ -103,6 +108,61 @@ status: current
 
 ---
 
+## 导航之前的那个答案（规则 7–9，可选）
+
+> **借鉴自**：[`ayghri/i-have-adhd`](https://github.com/ayghri/i-have-adhd)（MIT），十条中取三条。
+> 其余七条删去：两条已被上方规则 1–2 涵盖，五条与本标准冲突
+> （它的「不要 recap／不要结语」与规则 1 的导航区块直接矛盾；它的「列表上限 5 项」
+> 会截断证据表格与遍历分母）或与 [estimation-standards](estimation-standards.md) 重复。
+
+**这一节为何存在**：规则 1–6 管的是答案**之后**要附什么，而答案本身没有任何规则在管——
+一个响应可以把结论埋在一整面证据底下，只要结尾附上正确的导航区块，
+它仍然满足本标准的每一条。**找不到答案的读者，不会因为被告知下一步而得到帮助。**
+
+**这三条是可选的**，语义同规则 6：采用项目不必启用，既有 skill 也不需回头补。
+项目**可以**在自己的配置中把任一条提升为必须。**不可选的是它们必须有精确的触发条件**——
+一条松到永远不会启动的规则，与没有这条规则无从分辨。
+
+### 规则 7：先讲发现，不要先讲过程（可选）
+
+**触发条件**：回答问题、汇报调查结果、或提出决策的响应。
+
+第一行写**查到了什么**或**该做什么**。不是方法、不是把问题复述一遍、不是回答的计划。
+
+证据——`file:line`、命令输出、表格、测量数字——是**佐证**，应放在它所支持的论断**之后**。
+以证据开场会迫使读者自行重建结论，而那正是他请你做的工作。
+
+| 不要写 | 改写成 |
+|---|---|
+| 「我检查了 44 天、63 个域名的数据，发现……」 | 「那三组查询删掉。它返回的东西有 46% 是下载页。」 |
+| 「让我看看这是怎么配置的。」 | 「配置在 `x.yaml:12`，值是错的，因为……」 |
+
+**这不代表可以省略证据**，它规范的是顺序。
+
+### 规则 8：多轮工作中每一轮重述进度（可选）
+
+**触发条件**：跨 3 轮以上的对话，或含 3 个以上步骤的任务。
+
+每条响应用一行说明工作进行到哪里。不能假设读者能在消息之间记住
+「我们在 5 步中的第 3 步」，而重述它的成本是一个句子。
+
+本条与下方模板 4（进行中）互补：**规则 8 管开头，模板 4 管结尾。**
+
+### 规则 9：不要开场白（可选）
+
+**触发条件**：任何实质性响应。
+
+从答案开始。不要以「我接下来要做什么」的预告、对请求的确认、或对问题本身的评价开场。
+
+本条把一项既有禁令一般化：[anti-sycophancy-prompting](anti-sycophancy-prompting.md)
+已经禁止「以正面肯定开场批评」，但**仅限批评情境**。规则 9 把同一项禁令扩及每一个实质响应，
+理由不同：不是为了防拍马屁，而是为了消除它在读者与答案之间制造的延迟。
+
+**规则 9 不适用于结语。** 规则 1 要求的导航区块依然成立——
+响应的结尾正是本标准安放「读者下一步」的位置。
+
+---
+
 ## 情境模板
 
 ### 模板 1：任务完成
@@ -290,6 +350,9 @@ AI 需要用户做出选择或提供信息时使用。
 | R4 | 1–5 个选项，依情境调整 |
 | R5 | 适用时使用 `/command` 格式 |
 | R6 | *（可选）* 级别明确时附加 `〔模型：Fast｜Standard｜Capable〕` |
+| R7 | *（可选）* 先讲发现；证据放在它所支持的论断之后 |
+| R8 | *（可选）* 跨 3 轮或 3 步以上 → 用一行重述进度 |
+| R9 | *（可选）* 不要开场白。结语仍为必须——见 R1 |
 
 | 豁免 | 不豁免 |
 |------|--------|
@@ -313,6 +376,7 @@ AI 需要用户做出选择或提供信息时使用。
 
 | 版本 | 日期 | 变更 |
 |------|------|------|
+| 1.2.0 | 2026-08-17 | 新增可选规则 R7–R9，管答案本身（先讲发现、重述进度、不要开场白）。借鉴自 `ayghri/i-have-adhd`（MIT），十条取三；其余七条因已被 R1–R2 涵盖、与 R1 冲突、或与 estimation-standards 重复而删去。规则 1–6 全部可以被一个把结论埋起来的响应满足——R7–R9 补上这个缺口 |
 | 1.1.0 | 2026-06-10 | 新增规则 R6 可选模型级别标注（`〔模型：Fast｜Standard｜Capable〕`）；与厂商无关；不强制既有技能回改 |
 | 1.0.0 | 2026-03-25 | 初始版本 |