universal-dev-standards 6.0.0 → 6.1.0

package/bundled/core/self-review-protocol.md

@@ -2,8 +2,8 @@
 
 > **English** | [繁體中文](../locales/zh-TW/core/self-review-protocol.md)
 
-**Version**: 1.0.0
-**Last Updated**: 2026-05-26
+**Version**: 1.1.0
+**Last Updated**: 2026-07-09
 **Applicability**: All software projects (new, refactoring, migration, maintenance)
 **Scope**: partial
 **Industry Standards**: ISO/IEC 25010 (Documentation maintainability), IEEE 1063-2001 (Software user documentation)
@@ -26,7 +26,7 @@ This standard mandates a **self-review pass** on large markdown edits before com
 
 Across multiple Claude-assisted editing sessions (e.g., `dev-platform/.claude/skills/eval-source/SKILL.md` v1.1.0 → v1.1.1 and v1.2.0 → v1.2.1), a consistent pattern emerged: **each large markdown edit introduced 3-6 small internal inconsistencies** that were invisible to internal reasoning but surfaced immediately on full re-read.
 
-These inconsistencies fell into **6 recurring categories** and consistently triggered a follow-up patch commit. Adding a mandatory re-read step before commit eliminated this pattern (eval-source v1.3.0 was the first to pass without follow-up patch).
+These inconsistencies fell into **6 recurring categories** and consistently triggered a follow-up patch commit. A 7th category — language/terminology consistency — was added later for a different rationale (cross-conversation AI output drift, not the original patch-cycle pattern); see below. Adding a mandatory re-read step before commit eliminated this pattern (eval-source v1.3.0 was the first to pass without follow-up patch).
 
 ---
 
@@ -48,7 +48,7 @@ Applicable artefact types:
 
 ---
 
-## The 6 Categories of Internal Inconsistency
+## The 7 Categories of Internal Inconsistency
 
 ### 1. Diagram / Flow vs Step List Mismatch
 **Example**: A workflow diagram with 7 boxes but the document defines 8 steps.
@@ -74,12 +74,16 @@ Applicable artefact types:
 **Example**: A template example shows `D1/D2/D3` but the rule explicitly says D3 is not mandatory, and the present case specifically demoted its D3.
 **Check**: Every concrete value in examples must be consistent with current rules; examples should not contradict latest case experience.
 
+### 7. Language / Terminology Consistency
+**Example**: A bilingual document has a paragraph mixing English and Chinese sentences, or a Japanese/Korean character sequence contaminates a Traditional Chinese section; or the same project term (e.g. "XSPEC", "gate", "pipeline") is spelled inconsistently across the same document.
+**Check**: Scan for non-target-language scripts outside their expected sections (e.g. Japanese kana U+3040–U+30FF, Korean hangul U+AC00–U+D7A3 inside a zh-TW paragraph), same-paragraph language mixing, and inconsistent spelling of established project terms within one file.
+
 ---
 
 ## Procedure
 
 1. **After editing, before committing**, use the file-reading tool to re-read the **entire file** (not just the diff).
-2. Walk through the 6 categories above against the file.
+2. Walk through the 7 categories above against the file.
 3. **If issues found**: Edit in place and include fixes in the same commit (don't ship and patch later).
 4. **If already committed** before noticing: Create a patch commit (e.g., v1.2.1 fixing v1.2.0).
 
@@ -98,19 +102,19 @@ Append a changelog line in the format:
 ### For ADRs / DECs
 In the `## Follow-up Tracking` table, add a row:
 ```
-| Self-review pass | This DEC | ✅ YYYY-MM-DD (6 categories, no issues) |
+| Self-review pass | This DEC | ✅ YYYY-MM-DD (7 categories, no issues) |
 ```
 
 ### For XSPEC SDD Deltas
 After the "non-modification list" section (e.g., §N.6), append:
 ```
-> Self-review pass: YYYY-MM-DD (6 categories, no issues)
+> Self-review pass: YYYY-MM-DD (7 categories, no issues)
 ```
 
 ### In Commit Message Body
 Append a single line at the end:
 ```
-Self-review (protocol v1.0.0): N issues found, M applied in same commit / 0 found.
+Self-review (protocol v1.1.0): N issues found, M applied in same commit / 0 found.
 ```
 
 ---
@@ -158,3 +162,4 @@ Adoption of this standard is verified by:
 ## Self-Review Pass
 
 > Self-review pass: 2026-05-26 (6 categories, no issues found on the first draft of this standard itself)
+> Self-review pass: 2026-07-09 (7 categories, no issues found — added category 7 "Language / Terminology Consistency" per XSPEC-324)

package/bundled/core/verification-evidence.md

@@ -2,8 +2,8 @@
 
 > **Language**: English | [繁體中文](../locales/zh-TW/core/verification-evidence.md)
 
-**Version**: 1.0.0
-**Last Updated**: 2026-03-20
+**Version**: 1.2.0
+**Last Updated**: 2026-07-17
 **Applicability**: All AI-assisted development workflows
 **Scope**: universal
 **Inspired by**: [Superpowers](https://github.com/obra/superpowers) — verification-before-completion (MIT)
@@ -12,9 +12,19 @@
 
 ## Purpose
 
-Establish an "Iron Law" that no task can be claimed as complete without verification evidence. This standard prevents AI agents from hallucinating success and ensures every completion claim is backed by executable proof.
+Establish an "Iron Law" that no task can be claimed as complete without verification evidence, and ensure that the evidence itself holds up. This standard guards two distinct failures:
 
-建立「鐵律」：無驗證證據不可聲稱完成。防止 AI 代理虛構成功結果，確保每個完成聲明都有可執行的證據支持。
+1. **Claiming success without evidence** — the agent asserts what it never checked (the Iron Law).
+2. **Evidence that does not support its claim** — the agent *did* check, and the checking tool silently did not work (Evidence Validity, added in v1.2.0).
+
+The first is a form of hallucination. **The second is not** — nothing was invented; a real command produced a real output that meant something other than what it appeared to mean. Both end in the same place: a completion claim that isn't true.
+
+建立「鐵律」：無驗證證據不可聲稱完成——並確保**證據本身站得住腳**。本標準防兩種不同的失敗：
+
+1. **無證據就宣稱成功**——代理斷言它從未查過的事（Iron Law）。
+2. **證據撐不起它的主張**——代理**確實查了**，而查詢工具靜默地沒有運作（證據有效性，v1.2.0 新增）。
+
+前者是幻覺的一種，**後者不是**——沒有任何東西被捏造，是一個真實的指令產生了真實的輸出，而那個輸出的意思不是它看起來的意思。兩者殊途同歸：一個不成立的完成聲明。
 
 ---
 
@@ -25,7 +35,10 @@ Establish an "Iron Law" that no task can be claimed as complete without verifica
 | Verification Evidence | A structured record of a verification command's execution and result |
 | Iron Law | The absolute rule: no evidence = no completion claim |
 | RED-GREEN Cycle | Proving a bug fix by showing the test fails before and passes after the fix |
-| Exit Code | The numeric return value of a command (0 = success, non-zero = failure) |
+| Exit Code | The numeric return value of a command. **`0 = success` is the tool's convention, not a guarantee** — see Evidence Validity |
+| 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 |
 
 ---
 
@@ -39,6 +52,18 @@ An agent saying "it's done" is not evidence. The verification must be independen
 
 代理聲稱「已完成」不是證據。驗證必須是可獨立執行且產生可觀察輸出的。
 
+### Non-Evidence Claims
+
+None of the following constitute verification evidence:
+
+| Claim | Why it isn't evidence |
+|-------|----------------------|
+| "Done." | No observable output |
+| "It should work now." | No verification was executed |
+| "I changed the code." | A modification is not a verification |
+| "The tests should pass." | A prediction is not a fact |
+| "The command returned 0." | Only if the command could have measured the claim — see Evidence Validity |
+
 ---
 
 ## Evidence Format
@@ -50,7 +75,8 @@ Every verification must produce a structured evidence record:
   "command": "pnpm test -- --filter core",
   "exit_code": 0,
   "output": "Tests: 47 passed, 0 failed\nDuration: 3.2s",
-  "timestamp": "2026-03-20T14:30:00Z"
+  "timestamp": "2026-03-20T14:30:00Z",
+  "environment_layer": "local"
 }
 ```
 
@@ -59,9 +85,44 @@ Every verification must produce a structured evidence record:
 | Field | Type | Required | Description |
 |-------|------|----------|-------------|
 | `command` | string | Yes | The actual verification command executed |
-| `exit_code` | number | Yes | Command exit code (0 = success) |
+| `exit_code` | number | Yes | Command exit code. **Interpret via Evidence Validity — this field is a claim, not a fact** |
 | `output` | string | Yes | Command output (truncated to 2000 chars, preserving key info) |
 | `timestamp` | string | Yes | Execution time in ISO 8601 format |
+| `environment_layer` | string | Conditional | Which layer the evidence came from (`local` / `uat` / `prd`). **Required for any AC with an external service dependency** (SMS, payment, IdP); when absent, the AC's verification level is treated as local-only |
+
+---
+
+## Evidence Types
+
+| Type | Applies to | Example |
+|------|-----------|---------|
+| **Test result** | Feature work, bug fixes | `npm test` output |
+| **Type check** | Statically typed codebases | `pnpm tsc --noEmit` reporting no errors |
+| **Build success** | Compilation, packaging | `npm run build` exiting 0 |
+| **Lint clean** | Code quality | `npm run lint` reporting no errors |
+| **RED-GREEN** | Bug fixes | Failing before the fix → passing after |
+| **Health probe** | Deployed services | `curl https://<service>/health` — declare `environment_layer`; a probe against `localhost` verifies the local process, not the deployment |
+| **Manual verification** | UI changes, visual behaviour | Screenshot or screen recording |
+
+---
+
+## Environment Layers
+
+> **Iron Law (Environment)**: before acceptance, establish *which dimensions of this flow this environment layer is capable of verifying at all*.
+
+驗收前必須確認「此環境層次能驗證此流程的哪些維度」。
+
+A passing test proves nothing about a dimension the environment cannot exercise. A `local` run with a mocked payment gateway does not verify the payment integration — it verifies the mock. Evidence must therefore declare where it was collected.
+
+| Layer | Meaning |
+|-------|---------|
+| `local` | Developer machine or CI; external dependencies typically mocked or stubbed |
+| `uat` | Staging environment with real (or sandbox) external services |
+| `prd` | Production |
+
+For an AC that depends on an external service, `local`-only evidence is **insufficient**: either supply `uat`/`prd` evidence, or declare the gap explicitly. See VE-005 / VE-006.
+
+> The declaration goes in the project's **Environment Stratification Responsibility Matrix** (`docs/testing/environment-stratification-matrix.md` or the test plan) — a per-project deliverable defined by the `deployment-standards` standard, which answers "which test flows can be fully verified in which environment?". Mark the un-verifiable combinations ⚠️/❌ there rather than leaving them implied by a passing local run.
 
 ---
 
@@ -107,12 +168,63 @@ The evidence record must include both RED and GREEN phases.
 
 ---
 
+## Evidence Validity
+
+> **The evidence can lie. Verify the evidence, not just the claim.**
+
+證據本身會騙人。要驗的不只是「有沒有證據」，還有「這個證據成不成立」。
+
+The Iron Law stops an agent from claiming success **without** evidence. It does not stop the opposite failure: the agent *does* run a verification, the command *does* return, `exit_code` *is* `0` — **and the output is meaningless**, because the command never actually measured anything.
+
+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
+
+**1. `exit_code = 0` means success only for tools that return 0 on success.**
+
+The convention is near-universal, which is exactly why it goes unquestioned. When a tool fails **by design** in the situation under test, its non-zero exit code carries no information about the artefact — read the *output* instead. The inverse holds too: a non-zero exit code does not establish that the thing under test is broken.
+
+**2. "Empty output" / "not found" / `0` is not the same as "it isn't there."**
+
+Before concluding absence, establish that the query tool *ran successfully*: it was not `command not found`, it was not denied permission, its arguments were not consumed by an intervening shell. **Verify the query tool works before trusting the query's silence.**
+
+**3. Commands that test for existence must not discard stderr.**
+
+Suppressing stderr (`2>/dev/null` and equivalents) silences precisely the channel that would have reported "this tool is broken". The failure then wears the same clothes as a true negative.
+
+**4. A pipeline's exit code does not belong to any single stage in it.**
+
+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.
+
+### 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:
+
+| Verification command | `exit_code` | Output | Ground truth |
+|---|:---:|---|---|
+| `sudo -n find /backup/immich -type f 2>/dev/null \| wc -l` | **0** | `0` | `sudo` failed for lack of a tty, `2>/dev/null` ate the error, empty input made `wc -l` print `0`. **31 files existed.** Reported as "the backups are empty" |
+| `gpg --list-packets <valid-file.gpg>` | **≠ 0** | Well-formed packet listing | The host holds no private key **by design**; gpg always exits non-zero here. **The file was valid.** Acted on by deleting a good encrypted backup |
+| `gpg … \| grep -q "tag=1"` under `pipefail` | **≠ 0** | grep *did* match | The pipeline inherited gpg's non-zero; the match was irrelevant. **Deleted a good backup a second time** |
+| `grep -c "${VAR}/path" file` over SSH in double quotes | **0** | `0` | `${VAR}` was expanded by the *local* shell to an empty string; the remote grep searched for the wrong text |
+| `gpg --import key.asc 2>/dev/null` | — | (empty) | gpg **was not installed**; `command not found` went to the suppressed stderr |
+| `until ! ssh host 'systemctl is-active svc'; do …` | — | loop exited | **A failed SSH connection and a finished service produce the same exit code.** The "result" read afterwards was a stale value from a previous run |
+| `du -sh /data/*` as an unprivileged user | **0** | `4.0K` | Unreadable directories were reported as near-empty rather than as errors |
+| `case "$tag" in *M*)` searching for monthly snapshots | **0** | (no match) | The tag's actual value was `monthly` — no capital `M`. Nearly became "there are no monthly snapshots" |
+
+**Four of these had `exit_code = 0` and were false; two had `exit_code ≠ 0` and were true.** The field was unreliable in both directions — and in both of the non-zero cases, following VE-002 ("mark verification failed, trigger fix loop") destroyed a healthy artefact.
+
+> **Provenance**: all instances come from a single day's work by a single agent (Claude Opus 4.8), recorded in AsiaOstrich XSPEC-340. The sample is dense but narrow. It is offered as evidence rather than proof — though note that every failure above originates in the *semantics of the tools* (sudo, gpg, pipefail, POSIX exit codes), not in any property of the model, so any agent driving the same tools is exposed to the same traps.
+
+---
+
 ## Trust Rules
 
 | Rule | Description |
 |------|-------------|
 | Agent says "done" but no `verification_evidence` | Mark as **unverified** |
-| `verification_evidence` exists but `exit_code ≠ 0` | Mark as **verification failed** |
+| `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 |
 | Multiple verification steps | **All** steps must pass |
 | Agent provides evidence for wrong command | Mark as **unverified** |
 
@@ -123,9 +235,15 @@ The evidence record must include both RED and GREEN phases.
 | ID | Trigger | Action | Priority |
 |----|---------|--------|----------|
 | VE-001 | Agent reports success without verification_evidence | Downgrade to `done_with_concerns` | Critical |
-| VE-002 | `exit_code ≠ 0` in evidence | Mark verification failed, trigger fix loop | High |
+| VE-002 | `exit_code ≠ 0` in evidence | Mark verification failed, trigger fix loop — **after** confirming the tool returns 0 on success in this state (see VE-007) | High |
 | VE-003 | Bug fix without RED-GREEN cycle | Request both RED and GREEN evidence | High |
 | VE-004 | Output exceeds 2000 chars | Truncate but preserve error messages and summary lines | Medium |
+| VE-005 | AC has an external service dependency (SMS, payment, IdP) | Evidence must declare `environment_layer`; local-only evidence is insufficient | Required |
+| VE-006 | AC with external dependency marked done, no `environment_layer` | Downgrade to `done_with_concerns`; require the layer declaration or a ⚠️/❌ entry in the environment-stratification-matrix | High |
+| VE-007 | The verification tool exits non-zero in the state under test **by design** | VE-002 does not apply. Judge by output content; **do not trigger a fix loop against a healthy artefact** | Critical |
+| 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 |
 
 ---
 
@@ -163,10 +281,52 @@ message: "I've completed the task and everything should work now."
 # ❌ No verification_evidence — violates Iron Law
 ```
 
+### Bad: Evidence That Cannot Support Its Claim
+
+```yaml
+claim: "The backup directory is empty — backups are not running."
+verification_evidence:
+  - command: "sudo -n find /backup/immich -type f 2>/dev/null | wc -l"
+    exit_code: 0
+    output: "0"
+    timestamp: "2026-07-17T13:05:00Z"
+# ❌ Passes the Iron Law: evidence exists, exit_code is 0, output is concrete.
+# ❌ Violates VE-008, VE-009, VE-010:
+#      - claims absence without showing the query tool ran (VE-008)
+#      - suppresses the stderr that said "sudo: a terminal is required" (VE-009)
+#      - the exit code is the pipeline's, i.e. `wc -l`'s — `find` never ran (VE-010)
+#    31 files were present. Directory listed as empty because nothing looked.
+```
+
+### Good: The Same Check, Made Valid
+
+```yaml
+claim: "The backup directory holds 31 files."
+verification_evidence:
+  - command: "ssh host 'sudo find /backup/immich -type f | wc -l'"   # stderr not suppressed
+    exit_code: 0
+    output: "31"
+    timestamp: "2026-07-17T13:07:00Z"
+    environment_layer: "prd"
+# ✅ stderr would have surfaced a sudo/permission failure instead of printing 0
+# ✅ single-quoted so ${...} is not expanded by the local shell before transit
+```
+
+---
+
+## Related Standards
+
+- [Anti-Hallucination](anti-hallucination.md) — the complementary standard. It prevents *fabricated* claims (asserting what was never checked); Evidence Validity covers the opposite failure — claims that **were** checked, by a tool that silently did not work.
+- [Systematic Debugging](systematic-debugging.md) — how to investigate once evidence shows a real failure
+- [Checkin Standards](checkin-standards.md) — where completion claims are gated
+- [Test Governance](test-governance.md) — which tests are required, and therefore which evidence must exist
+- [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
+
 ---
 
 ## References
 
 - **Superpowers**: [verification-before-completion](https://github.com/obra/superpowers) (MIT)
 - **Test-Driven Development**: RED-GREEN-REFACTOR cycle
-- **Anti-Hallucination**: Complementary standard for preventing fabricated claims

package/bundled/locales/COVERAGE.md

@@ -1,9 +1,9 @@
 # UDS Locale Coverage
 
-> Auto-generated by `scripts/generate-locale-coverage.mjs` on 2026-06-18.
+> Auto-generated by `scripts/generate-locale-coverage.mjs` on 2026-07-16.
 > Do not edit manually — re-run the script.
 
-> **Canonical**: `skills/` (55) + `core/` (145). **Locales tracked**: `zh-CN`, `zh-TW`.
+> **Canonical**: `skills/` (55) + `core/` (149). **Locales tracked**: `zh-CN`, `zh-TW`.
 
 ## Skills (55 canonical)
 
@@ -18,7 +18,7 @@
 | atdd-assistant | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | audit-assistant | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | bdd-assistant | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
-| brainstorm-assistant | :white_check_mark: 3.0.0 | :white_check_mark: 3.0.0 |
+| brainstorm-assistant | :white_check_mark: 4.1.0 | :white_check_mark: 4.1.0 |
 | changelog-guide | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | checkin-assistant | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | ci-cd-assistant | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
@@ -38,7 +38,7 @@
 | incident-response-assistant | :white_check_mark: 1.1.0 | :white_check_mark: 1.1.0 |
 | journey-test-assistant | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | knowledge-graph | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
-| logging-guide | :white_check_mark: 1.1.0 | :white_check_mark: 1.1.0 |
+| logging-guide | :white_check_mark: 1.4.0 | :white_check_mark: 1.4.0 |
 | metrics-dashboard-assistant | :white_check_mark: 1.1.0 | :white_check_mark: 1.1.0 |
 | migration-assistant | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | observability-assistant | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
@@ -68,7 +68,7 @@
 **zh-CN skills coverage**: 55/55 (100%)
 **zh-TW skills coverage**: 55/55 (100%)
 
-## Standards (`core/` — 145 canonical)
+## Standards (`core/` — 149 canonical)
 
 | Standard | zh-CN | zh-TW |
 | :-- | :-: | :-: |
@@ -88,12 +88,12 @@
 | alerting-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | anti-hallucination.md | :white_check_mark: 1.5.1 | :white_check_mark: 1.5.1 |
 | anti-sycophancy-prompting.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
-| api-design-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
+| api-design-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.1.0 |
 | audit-trail.md | :x: | :white_check_mark: 1.0.0 |
 | behavior-driven-development.md | :white_check_mark: 1.1.0 | :white_check_mark: 1.1.0 |
-| behavior-snapshot.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
+| behavior-snapshot.md | :white_check_mark: 1.1.0 | :white_check_mark: 1.1.0 |
 | branch-completion.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
-| browser-compatibility-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
+| browser-compatibility-standards.md | :white_check_mark: 1.0.2 | :white_check_mark: 1.0.0 |
 | capability-declaration.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | cd-deployment-strategies.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | change-batching-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
@@ -110,13 +110,13 @@
 | context-aware-loading.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | contract-testing-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | cost-budget-test.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
-| cross-flow-regression.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
+| cross-flow-regression.md | :white_check_mark: 1.0.1 | :white_check_mark: 1.0.0 |
 | data-contract.md | :x: | :white_check_mark: 1.0.0 |
 | data-migration-testing.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | data-pipeline.md | :x: | :white_check_mark: 1.0.0 |
 | database-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | deployment-standards.md | :white_check_mark: 1.1.0 | :white_check_mark: 1.1.0 |
-| deprecation-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
+| deprecation-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.1.0 |
 | design-document-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | developer-memory.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | disaster-recovery-drill.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
@@ -129,10 +129,11 @@
 | estimation-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | execution-history.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | failure-source-taxonomy.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
+| feature-discovery-standards.md | :x: | :x: |
 | feature-flag-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | feature-manifest-standard.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | flaky-test-management.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
-| flow-based-testing.md | :white_check_mark: 1.3.0 | :white_check_mark: 1.3.0 |
+| flow-based-testing.md | :white_check_mark: 1.3.1 | :white_check_mark: 1.3.1 |
 | forward-derivation-standards.md | :white_check_mark: 1.2.0 | :white_check_mark: 1.2.0 |
 | frontend-design-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | full-coverage-testing.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.1.0 |
@@ -147,10 +148,11 @@
 | knowledge-transfer-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | license-compliance.md | :white_check_mark: 2.1.0 | :white_check_mark: 2.1.0 |
 | llm-output-validation.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
-| logging-standards.md | :white_check_mark: 1.3.0 | :white_check_mark: 1.4.0 |
-| mock-boundary.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
+| logging-standards.md | :white_check_mark: 1.4.0 | :white_check_mark: 1.4.0 |
+| mock-boundary.md | :white_check_mark: 1.1.0 | :white_check_mark: 1.1.0 |
 | model-provenance.md | :x: | :white_check_mark: 1.0.0 |
 | model-selection.md | :white_check_mark: 1.0.1 | :white_check_mark: 1.0.1 |
+| multi-environment-e2e-testing.md | :x: | :x: |
 | mutation-testing.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | no-cicd-deployment.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | observability-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
@@ -168,8 +170,9 @@
 | project-structure.md | :white_check_mark: 1.2.0 | :white_check_mark: 1.2.0 |
 | prompt-regression.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | property-based-testing.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
+| push-standards.md | :x: | :x: |
 | recovery-recipe-registry.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
-| refactoring-standards.md | :white_check_mark: 2.1.0 | :white_check_mark: 2.1.0 |
+| refactoring-standards.md | :white_check_mark: 2.1.0 | :white_check_mark: 2.2.0 |
 | release-quality-manifest.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | release-readiness-gate.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | replay-test.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
@@ -177,7 +180,7 @@
 | resource-cost-boundary.md | :x: | :white_check_mark: 1.0.0 |
 | retrospective-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | retry-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
-| reverse-engineering-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
+| reverse-engineering-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.2.0 |
 | rollback-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | runbook-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | runbook.md | :x: | :white_check_mark: 1.0.0 |
@@ -187,8 +190,8 @@
 | secure-op.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | security-decision.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | security-standards.md | :white_check_mark: 1.1.0 | :white_check_mark: 1.1.0 |
-| security-testing.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
-| self-review-protocol.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
+| security-testing.md | :white_check_mark: 1.1.0 | :white_check_mark: 1.1.0 |
+| self-review-protocol.md | :white_check_mark: 1.1.0 | :white_check_mark: 1.1.0 |
 | server-ops-security.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | skill-standard-alignment-check.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | slo-sli.md | :x: | :white_check_mark: 1.0.0 |
@@ -210,22 +213,25 @@
 | timeout-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | token-budget.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | translation-lifecycle-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
+| user-journey-testing.md | :x: | :white_check_mark: 1.0.0 |
 | user-story-mapping.md | :x: | :white_check_mark: 1.0.0 |
 | verification-evidence.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | verification-oracle.md | :x: | :white_check_mark: 1.0.0 |
-| versioning.md | :white_check_mark: 1.2.0 | :white_check_mark: 1.2.0 |
+| versioning.md | :warning: 1.2.0 (drift 3m) | :white_check_mark: 1.5.0 |
 | virtual-organization-standards.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | workflow-enforcement.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 | workflow-state-protocol.md | :white_check_mark: 1.0.0 | :white_check_mark: 1.0.0 |
 
-**zh-CN core coverage**: 128/145 (88%)
-**zh-TW core coverage**: 145/145 (100%)
+**zh-CN core coverage**: 128/149 (86%)
+**zh-TW core coverage**: 146/149 (98%)
 
 ## Drift Warnings
 
 Locale variants whose `translation_version` lags `source_version` by more than 2 minor versions, or by any major version. (Per XSPEC-239 Chimera Prevention — `translation-drift-warn`.)
 
-_None — all locale variants are within 2 minor versions of source._
+### zh-CN
+
+- **core/versioning.md**: translation `1.2.0` vs source `1.5.0` (3 minor versions behind)
 
 ## Legend
 

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

@@ -1,8 +1,8 @@
 ---
 source: ../../CHANGELOG.md
-source_version: 6.0.0
-translation_version: 6.0.0
-last_synced: 2026-07-06
+source_version: 6.1.0
+translation_version: 6.1.0
+last_synced: 2026-07-17
 status: current
 ---
 
@@ -17,6 +17,29 @@ status: current
 
 ## [Unreleased]
 
+## [6.1.0] - 2026-07-17
+
+> **同一种形状的两个失败，一个在标准里、一个在 CLI 里**：一道检查跑了、返回了、报告成功，却什么都没测到。`verification-evidence` 补上了为它命名的那一层；`uds init` 则不再是它的一个实例。
+
+### 修复
+
+- **`uds init` 不再覆盖既有的 `prepare` script**（XSPEC-341）。自 2026-02-04 起，`uds init` 会对任何没有 `.husky/` 目录的 Node 项目执行 `npx husky init`。该命令是为**全新**项目设计的一次性 bootstrap：它会无条件把 `"prepare"` 设成 `"husky"`。若你的项目原本就有 `prepare`——而对一个要发布的包而言，`prepare` 通常就是 build 步骤——**它会被静默取代**，而 CLI 报告成功。`uds init` 现在改为串接而非覆写（`"tsup"` → `"tsup && husky"`），会打印出它所修改的每一个 `package.json` 字段，也不再丢弃 husky 的 stderr。
+
+  > **⚠️ 若你曾在原本就有 `prepare` script 的项目上跑过 `uds init`，请立即检查。** 这次修复保护的是往后的执行；它无法还原一个已经被改写的 `package.json`。症状是：你预期看到自己的 build 命令，实际看到的却是 `"prepare": "husky"`——而如果你的包会发布构建产物（`files: ["dist"]`、`main` 指向 `dist/`）且没有 `prepack`／`prepublishOnly`，那么你下一次 `npm publish` 送出去的将是一个未构建或过期的目录。请以串接方式恢复：`"prepare": "<你原本的命令> && husky"`。
+
+- **`uds init` 不再把 `npm test` 塞进 `.husky/pre-commit`**（XSPEC-341）。那一行来自 husky 的 init 模板，不是来自 UDS——它等于在每一次 commit 上架了一道采用者从未选择加入的完整测试套件闸门。UDS 现在只追加自己的 `npx uds check`，而且是追加到既有 hook 之后，而不是改写它们。
+
+- **新建的 husky hook 改以 v9 格式写入**（XSPEC-341）。fallback 的 hook 模板仍在输出 v8 的 `#!/usr/bin/env sh` + `. "$(dirname -- "$0")/_/husky.sh"` 前导段，该写法在 husky v9 已弃用、v10 已移除——而 `uds init` 安装的正是 husky `^9`。这原本是潜伏问题（过去 hook 是由 husky init 写出的）；移除 `husky init` 后，fallback 升为主要路径，因此一并修复。
+
+### 变更
+
+- **`verification-evidence` 1.1.0 → 1.2.0 —— 证据有效性**（XSPEC-340）。本标准原本把 `exit_code` 当成事实真相：`trust_rules` 写着"`exit_code ≠ 0` → 验证失败"、`physical_spec.checks` 问的是"`exit_code` 是否为 0（成功）？"、VE-002 只要非零就触发修复循环。**这三处现已全数加上限定条件**，因为一道验证命令可以跑完、可以返回，却什么意义都没有：
+  - **新增 `evidence_validity` 层次与规则 VE-007 – VE-010**：只有在"成功时返回 0"的工具上，`exit_code = 0` 才代表成功（VE-007）；在证明查询工具确实执行过之前，"空／未找到／0"不等于不存在（VE-008）；存在性检查不得丢弃 stderr（VE-009）；pipeline 的退出码不属于其中任何单一阶段（VE-010）。
+  - **新增 `non_evidence_claims`**："已完成"／"应该可以了"／"我改了代码"／"测试应该会通过"／"命令返回 0"。
+  - 有别于 `anti-hallucination`——后者的禁令全都是"不要断言你没查过的事"的变形。这里是相反的失败：**确实查了，而查询工具静默地没有运作**。`core/verification-evidence.md` 收录了十笔真实案例作为证据。
+- **`verification-evidence` 的人类文档补上了 v1.1.0 的落差。** v1.1.0 的 `environment_layer` 工作（XSPEC-204）已落地于全部三份 `.ai.yaml`，却**一份 `.md` 都没有更新**（共四份）——人类文档自 2026-05-13 起就一直在错误地描述这个标准。`core/*.md` 现已载明 `environment_layer`、Environment Layers 章节，以及 VE-005 / VE-006。
+- **`verification-evidence` 新增三个先前只存在于 zh-TW 译文的章节**：非证据的声明（Non-Evidence Claims）、证据类型（Evidence Types）、相关标准（Related Standards）。译文比它的来源更完整；这些章节现已上溯至英文来源，并同时存在于两个语系。
+
 ## [6.0.0] - 2026-07-06
 
 > ⚠️ **重大版本（Major release）。** 包含一项 breaking 更名，并移除 8 个已弃用的机器可读标准与 4 个已弃用的 CLI 命令（皆自 5.4.0 起带有「将于 6.0.0 移除」告示）。**请参阅 [v6 迁移指南](docs/MIGRATION-v6.md)**（[English](../../docs/MIGRATION-v6.md) | [繁体中文](../zh-TW/docs/MIGRATION-v6.md)）。

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

@@ -14,7 +14,7 @@ status: current
 
 Universal Development Standards 是一个语言无关、框架无关的文件化标准框架。它提供：
 
-- **核心规范** (`core/`)：145 个基础开发标准
+- **核心规范** (`core/`)：149 个基础开发标准
 - **AI 技能** (`skills/`)：用于 AI 辅助开发的 Claude Code 技能
 - **CLI 工具** (`cli/`)：用于采用标准的 Node.js CLI
 - **整合** (`integrations/`)：各种 AI 工具的配置