universal-dev-standards 6.3.7 → 6.3.9

package/bundled/ai/standards/design-document-standards.ai.yaml

@@ -1,5 +1,133 @@
 id: design-document-standards
 meta:
   version: "1.0.0"
-  updated: "2026-04-01"
+  updated: "2026-08-07"
   source: core/design-document-standards.md
+  # Extracted by hand (XSPEC-367 R2). convert-md-to-yaml.mjs was rejected: its
+  # output does not parse, truncates long values mid-sentence, and turns bold
+  # fragments into instructions.
+
+rules:
+  - id: hld-has-all-six-sections
+    trigger: writing a High-Level Design
+    instruction: >-
+      Include all six sections — overview, architecture, data flow, API surface,
+      non-functional requirements, milestones. A missing section is a decision
+      nobody recorded, not a section nobody needed.
+    priority: required
+
+  - id: lld-has-all-five-sections
+    trigger: writing a Low-Level Design
+    instruction: >-
+      Include all five sections — component design, data model, algorithm
+      details, error handling, testing strategy.
+    priority: required
+
+  - id: start-diagrams-at-l1
+    trigger: adding an architecture diagram
+    instruction: >-
+      Begin with a C4 Context diagram before going deeper. L1 and L2 suit most
+      projects; reach for L3 and L4 only when complexity warrants it.
+    priority: required
+
+  - id: diagrams-follow-the-code
+    trigger: architecture changes
+    instruction: >-
+      Update the diagrams in the same change. A diagram describing the previous
+      architecture is worse than none — it is read as current.
+    priority: required
+
+  - id: record-significant-decisions
+    trigger: making a significant design decision
+    instruction: >-
+      Record it, with the options considered and why the others were rejected.
+      A decision without its alternatives cannot be revisited, only re-argued.
+    priority: required
+
+  - id: state-transitions-are-explicit
+    trigger: moving a design document between lifecycle states
+    instruction: >-
+      Each transition has an entry condition and an owner (see lifecycle).
+      Abandoning a document requires a documented reason.
+    priority: required
+
+hld_sections:
+  - section: overview
+    purpose: define the problem, goals, and success criteria
+    covers: [problem and business context, in-scope and out-of-scope boundaries, success metrics, target audience]
+  - section: architecture
+    purpose: architecture decisions and component relationships
+    covers: [architecture style, key components and responsibilities, technology choices with rationale, C4 diagrams]
+  - section: data_flow
+    purpose: how data moves through the system
+  - section: api_surface
+    purpose: the interfaces the system exposes
+  - section: non_functional_requirements
+    purpose: performance, availability, security, scalability targets
+  - section: milestones
+    purpose: delivery sequence and checkpoints
+
+lld_sections:
+  - component_design
+  - data_model
+  - algorithm_details
+  - error_handling
+  - testing_strategy
+
+lifecycle:
+  flow: Draft → In Review → Approved → Implemented → Archived
+  states:
+    draft:
+      definition: initial creation and iteration
+      entry: author starts writing
+      exit: author submits for review
+      owner: author
+    in_review:
+      definition: under peer review and feedback
+      entry: submitted for review
+      exit: all reviewers approve or reject
+      owner: reviewers
+    approved:
+      definition: accepted for implementation
+      entry: review approved
+      exit: implementation begins
+      owner: tech lead / architect
+    implemented:
+      definition: design realised in code
+      entry: code matches design
+      exit: system is stable in production
+      owner: development team
+    archived:
+      definition: no longer active, kept for reference
+      entry: system decommissioned or design superseded
+      owner: author / tech lead
+  transitions:
+    - from_draft_to_in_review: author confirms the document is complete enough for meaningful review
+    - from_in_review_to_draft: reviewers request significant changes
+    - from_in_review_to_approved: all required reviewers approve, no blocking issues remain
+    - from_approved_to_implemented: implementation matches the approved design
+    - from_implemented_to_archived: system decommissioned, or a new design supersedes this one
+    - from_any_state_to_archived: document abandoned — the reason must be recorded
+
+c4_model:
+  l1_context:
+    scope: system and external actors
+    use_for: stakeholder communication, project kickoff
+    must_show: [system boundary, users, external systems, relationships]
+  l2_container:
+    scope: applications and data stores
+    use_for: technical overview, deployment planning
+    must_show: [applications, databases, message queues, protocols]
+  l3_component:
+    scope: internal components
+    use_for: developer onboarding, detailed design
+    must_show: [classes and modules, interfaces, dependencies]
+  l4_code:
+    scope: class and module level detail
+    use_for: documenting a complex algorithm
+    must_show: [UML class diagrams, sequence diagrams]
+
+related_standards:
+  - architecture-decision-records
+  - requirements-engineering
+  - spec-driven-development

package/bundled/ai/standards/estimation-standards.ai.yaml

@@ -1,5 +1,127 @@
 id: estimation-standards
 meta:
   version: "1.0.0"
-  updated: "2026-04-01"
+  updated: "2026-08-07"
   source: core/estimation-standards.md
+  # Extracted by hand (XSPEC-367 R2). convert-md-to-yaml.mjs was tried and
+  # rejected: its output for this very standard did not parse, truncated every
+  # long value mid-sentence, and produced `instruction: "McConnell, S"` — half
+  # an author name from the references section, presented as a rule.
+
+rules:
+  - id: estimate-carries-a-confidence-level
+    trigger: giving any estimate
+    instruction: >-
+      State the confidence level with the number. A point estimate without one
+      hides the range it came from.
+    priority: required
+
+  - id: never-hide-low-confidence
+    trigger: the estimate is low confidence
+    instruction: >-
+      Say so explicitly. Never present a low-confidence estimate as if it were
+      a firm one; suggest a spike instead.
+    priority: required
+
+  - id: estimate-is-not-commitment
+    trigger: an estimate is about to become a date
+    instruction: >-
+      Do not let an estimate be silently converted into a commitment. The
+      conversion is a negotiation — buffers, scope, and trade-offs — and the
+      commitment is recorded separately from the estimate it came from.
+    priority: required
+
+  - id: language-distinguishes-the-two
+    trigger: communicating an estimate or a commitment
+    instruction: >-
+      Estimates use "we estimate" / "our assessment is" and are ranges.
+      Commitments use "we commit to" / "we will deliver by" and are targets.
+    priority: required
+
+  - id: re-estimate-on-trigger
+    trigger: a re-estimation trigger fires (see re_estimation.triggers)
+    instruction: >-
+      Re-estimate the affected items, update the confidence level, tell
+      stakeholders, and record why plus the delta from the original.
+    priority: required
+
+  - id: calibrate-against-actuals
+    trigger: work completes
+    instruction: >-
+      Compare actual against estimate. The ratio is the feedback signal — above
+      1.0 means underestimated, below means overestimated.
+    priority: recommended
+
+confidence_levels:
+  - level: high
+    variance: "±20%"
+    describes: well-understood work with clear requirements and prior experience
+    typical: repeat tasks, well-defined stories, familiar technology
+    phrasing: "We estimate 5 days (4–6 days range)"
+  - level: medium
+    variance: "±50%"
+    describes: partially understood work with some unknowns
+    typical: new features in a known domain, moderate technical uncertainty
+    phrasing: "We estimate 5 days (2.5–7.5 days range)"
+  - level: low
+    variance: "±100%"
+    describes: highly uncertain work with significant unknowns
+    typical: new technology, unclear requirements, research spikes
+    phrasing: "We estimate 5 days (0–10 days range) — consider a spike first"
+
+methods:
+  planning_poker:
+    what: consensus estimation with independent cards, then discussion
+    use_when: sprint planning, story-level estimation
+  t_shirt_sizing:
+    what: relative sizing with abstract labels (XS, S, M, L, XL)
+    use_when: roadmap planning, epic-level estimation
+  three_point:
+    what: optimistic, most likely, pessimistic
+    formula: "E = (O + 4M + P) / 6 ; SD = (P - O) / 6"
+    use_when: critical path items, high-uncertainty tasks, project-level planning
+    trade_off: quantifies uncertainty, but needs three numbers per item
+
+re_estimation:
+  triggers:
+    - trigger: requirements change
+      when: functional or non-functional requirements added, removed, or modified
+      action: re-estimate affected items; update confidence levels
+    - trigger: technical discovery
+      when: new constraints, dependencies, or complexity uncovered
+      action: re-estimate with the new knowledge; document the discovery
+    - trigger: external dependency change
+      when: third-party APIs, libraries, or services change availability or behaviour
+      action: re-estimate integration work; assess timeline impact
+    - trigger: time threshold exceeded
+      when: elapsed time passes a significant share (e.g. >50%) of the estimate without proportional progress
+      action: checkpoint review; re-estimate the remaining work
+  process:
+    - identify that a trigger fired
+    - assess the impact on current estimates
+    - re-estimate affected items with an appropriate method
+    - communicate revised estimates and confidence levels
+    - document the reason and the delta from the original
+
+# Named so they can be recognised in progress, not only in a post-mortem.
+anti_patterns:
+  - name: anchoring bias
+    shape: the first number mentioned pulls every later estimate toward it
+    tell: estimates cluster around the first value shared; dissent goes quiet
+  - name: planning fallacy
+    shape: systematically underestimating time, cost, and risk while overestimating benefit
+    tell: projects consistently overrun; post-mortems keep citing "unforeseen" events
+  - name: scope creep blindness
+    shape: scope grows during the work and the estimate is never revisited
+    tell: original estimates go stale while nobody re-estimates
+  - name: student syndrome
+    shape: work starts as late as the buffer allows, consuming it
+    tell: work starts late despite available time; deadline pressure drives everything
+  - name: Parkinson's law
+    shape: work expands to fill the time allowed, regardless of real complexity
+    tell: tasks take exactly as long as estimated, whatever their difficulty
+
+related_standards:
+  - requirements-engineering
+  - user-story-mapping
+  - technical-debt-management

package/bundled/ai/standards/privacy-standards.ai.yaml

@@ -1,5 +1,151 @@
 id: privacy-standards
 meta:
-  version: "1.1.0"
-  updated: "2026-06-18"
+  version: "1.0.0"
+  updated: "2026-08-07"
   source: core/privacy-standards.md
+  # Extracted by hand (XSPEC-367 R2). convert-md-to-yaml.mjs was rejected: its
+  # output does not parse, truncates long values mid-sentence, and turns bold
+  # fragments into instructions.
+
+rules:
+  - id: privacy-is-the-default
+    trigger: designing any feature that touches personal data
+    instruction: >-
+      Personal data is protected without the user doing anything. A setting the
+      user must find and switch on is not a default.
+    priority: required
+
+  - id: classify-before-storing
+    trigger: introducing a new data field
+    instruction: >-
+      Assign a sensitivity level (public / internal / confidential / restricted)
+      and apply that level's handling requirements. Unclassified data gets no
+      protection by accident.
+    priority: required
+
+  - id: every-field-has-a-documented-purpose
+    trigger: adding a field to a form, event, or record
+    instruction: >-
+      Collect only what is necessary, and write down why each field exists.
+      A field nobody can justify is a field to remove.
+    priority: required
+
+  - id: every-data-type-has-a-retention-period
+    trigger: defining a new data type
+    instruction: >-
+      Set an explicit retention period and make expiry delete or anonymise the
+      data automatically. Retention without automatic deletion is a plan, not a
+      control.
+    priority: required
+
+  - id: purpose-limitation
+    trigger: reusing existing data for a new purpose
+    instruction: >-
+      Data collected for one purpose must not be used for another without
+      consent. "We already have it" is not a basis.
+    priority: required
+
+  - id: dpia-before-processing
+    trigger: any condition in dpia.triggers is met
+    instruction: >-
+      Conduct a DPIA before the processing starts, not after it ships.
+    priority: required
+
+  - id: support-the-five-user-rights
+    trigger: building account or data features
+    instruction: >-
+      Access, rectification, erasure, portability and objection each need a real
+      mechanism. See user_rights for what "real" means per right.
+    priority: required
+
+  - id: erasure-reaches-backups
+    trigger: implementing account deletion
+    instruction: >-
+      Deletion must cascade to backups within 30 days. A delete that leaves the
+      data in a backup is a delay, not an erasure.
+    priority: required
+
+data_classification:
+  public:
+    describes: freely shareable — marketing content, docs
+    handling: no restrictions
+  internal:
+    describes: internal use only — internal reports, meeting notes
+    handling: access control, no public sharing
+  confidential:
+    describes: sensitive business data — financials, strategies
+    handling: encryption at rest and in transit, audit logging, need-to-know access
+  restricted:
+    describes: highly sensitive PII, health, financial — SSN, medical records
+    handling: strongest encryption, strict access, data masking, regulatory compliance
+
+dpia:
+  triggers:
+    - processing personal data at large scale (see large_scale below)
+    - systematic monitoring of public areas
+    - automated decision-making with legal effects
+    - processing special category data (health, biometric, genetic)
+    - combining datasets from different sources
+    - processing data of vulnerable individuals (children, employees)
+  large_scale:
+    source: "GDPR Art. 35; WP29 DPIA Guidelines WP248rev.01"
+    note: >-
+      No single number defines large scale. Assess four factors and treat the
+      processing as large scale when it is significant on two or more.
+    factors:
+      - number of data subjects — absolute count, or a proportion of the relevant population
+      - volume and range of data items
+      - duration or permanence of the processing
+      - geographical extent
+    exception: >-
+      One-off processing, a single individual's data, or an individual
+      practitioner's records are not large scale and do not trigger a DPIA on
+      that ground alone. The other triggers may still apply.
+
+retention_guidelines:
+  session_data:
+    period: duration of the session
+    why: not needed after logout
+  activity_logs:
+    period: 90 days
+    why: debugging and support
+  account_data:
+    period: until account deletion, plus 30 days
+    why: grace period for recovery
+  transaction_records:
+    period: 7 years
+    why: tax and audit compliance
+  marketing_preferences:
+    period: until consent is withdrawn
+    why: consent-based
+
+user_rights:
+  access:
+    right: receive a copy of their personal data
+    implementation: export endpoint, machine-readable format (JSON/CSV)
+  rectification:
+    right: correct inaccurate personal data
+    implementation: profile editing, support channel for fields that are not self-service
+  erasure:
+    right: have their data deleted
+    implementation: account deletion flow, cascading to backups within 30 days
+  portability:
+    right: receive their data in a portable format
+    implementation: standard-format export (JSON, CSV), API for bulk export
+  objection:
+    right: object to specific processing
+    implementation: opt-out mechanisms, granular consent management
+
+privacy_by_design:
+  - proactive not reactive — anticipate and prevent, do not respond after the fact
+  - privacy as the default — protection without user action
+  - privacy embedded into design — architectural, not an add-on
+  - full functionality — positive-sum, privacy AND function, not privacy OR function
+  - end-to-end security — protected from collection through deletion
+  - visibility and transparency — practices documented, verifiable, open to scrutiny
+  - respect for user privacy — strong defaults, clear options, user interests first
+
+related_standards:
+  - security-standards
+  - logging-standards
+  - data-lifecycle-management

package/bundled/ai/standards/supply-chain-security-standards.ai.yaml

@@ -1,13 +1,161 @@
 id: supply-chain-security-standards
 meta:
   version: "1.1.0"
-  updated: "2026-08-04"
+  updated: "2026-08-07"
   source: core/supply-chain-security-standards.md
-  # NOTE: this file is a STUB. It carries no machine-readable rules, so an
-  # agent reading the ai/ layer gets nothing for this standard — the same is
-  # true of design-document-standards, estimation-standards and
-  # privacy-standards (4 of 141 as of 2026-08-04). The version above tracks
-  # the .md it points at; it does not mean the .md's rules are represented
-  # here. XSPEC-366 R4 rewrote that .md's Lock Strategy section and
-  # deliberately did not add a single rule here: one rule in an otherwise
-  # empty file would make coverage look better than it is.
+  # Rules below are extracted from that .md by hand. The repository's
+  # convert-md-to-yaml.mjs was tried first and rejected (XSPEC-367 R2): its
+  # output does not parse, truncates every long value mid-sentence, and turns
+  # bold fragments into instructions — one generated rule was `"McConnell, S"`,
+  # half an author name from the references section.
+  # MUST/SHOULD below carry the .md's own wording, not a re-grading.
+
+# ─────────────────────────────────────────────────────────────
+# Rules an agent can act on. `trigger` is when to apply the rule;
+# `priority` mirrors the RFC-2119 term used in the source.
+# ─────────────────────────────────────────────────────────────
+rules:
+  - id: sbom-on-every-release
+    trigger: cutting a release
+    instruction: >-
+      Ship an SBOM listing every direct and transitive dependency, with
+      component name, version, supplier, license, and known vulnerabilities.
+    priority: required
+
+  - id: sbom-generated-in-ci
+    trigger: setting up a release pipeline
+    instruction: Generate the SBOM automatically in CI rather than by hand.
+    priority: recommended
+
+  - id: lockfile-committed
+    trigger: adding or updating a dependency
+    instruction: Commit the lock file to version control.
+    priority: required
+
+  - id: lockfile-does-not-reach-consumers
+    trigger: publishing a package to a registry
+    instruction: >-
+      A committed lock file makes your own builds reproducible and constrains
+      nobody who installs your package — a published tarball or wheel carries
+      no lock file, so consumers resolve your declared ranges themselves.
+      Separately measure what those ranges resolve to, and run the test suite
+      against that resolution before release.
+    scope: published artifacts only
+    note: >-
+      A deployed service that ships its lock file with the artifact is not
+      affected by this rule. Applying it there adds ceremony to a project the
+      problem cannot reach.
+    priority: required
+
+  - id: security-patch-window
+    trigger: a security advisory affects a dependency
+    instruction: Apply within 48 hours for Critical, within 7 days for High.
+    priority: required
+
+  - id: patch-update-window
+    trigger: a non-security patch release is available
+    instruction: Apply within 7 days.
+    priority: recommended
+
+  - id: major-upgrade-cadence
+    trigger: planning quarterly work
+    instruction: Evaluate major version upgrades, with a migration plan and changelog review.
+    priority: recommended
+
+  - id: no-license-means-proprietary
+    trigger: introducing a new dependency
+    instruction: >-
+      Treat a dependency with no license as proprietary. Do not use it without
+      explicit permission.
+    priority: required
+
+  - id: agpl-in-saas
+    trigger: introducing a dependency into a hosted service
+    instruction: >-
+      AGPL triggers copyleft for the entire service. Evaluate before adopting,
+      not after.
+    priority: required
+
+  - id: copyleft-combination-review
+    trigger: combining two copyleft licenses
+    instruction: >-
+      Different copyleft licenses are often incompatible. Get legal review
+      rather than assuming.
+    priority: required
+
+# ─────────────────────────────────────────────────────────────
+# What to check, and what each finding means. Severity here is the
+# action, not a label: "block" stops the pipeline.
+# ─────────────────────────────────────────────────────────────
+audit_dimensions:
+  - dimension: known_vulnerabilities
+    check: CVE databases — NVD, OSV, GitHub Advisory
+    critical: block
+    high: warn
+  - dimension: license_compliance
+    check: compatibility with the project's own license
+    incompatible: block
+  - dimension: maintenance_status
+    check: last commit date, open issues, maintainer count
+    unmaintained_over_2_years: warn
+  - dimension: version_currency
+    check: how many major/minor versions behind latest
+    more_than_2_majors_behind: warn
+
+audit_frequency:
+  every_ci_build: automated vulnerability scan
+  weekly: automated full audit report
+  before_release: manual review of every warning
+  on_security_advisory: immediate assessment of affected dependencies
+
+# ─────────────────────────────────────────────────────────────
+# Update strategy by change type.
+# ─────────────────────────────────────────────────────────────
+update_strategy:
+  patch:
+    strategy: auto-merge once CI passes
+    automation: fully automated (Dependabot / Renovate)
+  minor:
+    strategy: open a PR automatically, review by hand
+    automation: semi-automated
+  major:
+    strategy: manual evaluation with a migration plan
+    automation: manual, with changelog review
+  lock_strategy:
+    strategy: >-
+      Commit lock files — and, if you publish, separately verify what consumers
+      resolve to.
+    automation: lock file committed; consumer resolution checked at release
+
+# ─────────────────────────────────────────────────────────────
+# CI gate. The thresholds are the point: a scan that reports
+# everything at the same level is a scan nobody reads.
+# ─────────────────────────────────────────────────────────────
+ci_gate:
+  required_steps:
+    - generate SBOM on every build
+    - scan for vulnerabilities against CVE databases
+    - scan licenses for compatibility
+    - report dependency freshness
+  on_finding:
+    critical: block the PR
+    high: warn and create a ticket
+    medium_or_low: log only
+
+license_compatibility:
+  permissive_with_permissive: always compatible
+  permissive_with_copyleft: compatible if the copyleft terms are followed
+  copyleft_with_different_copyleft: often incompatible — legal review required
+  agpl_in_saas: triggers copyleft for the whole service — evaluate carefully
+  no_license: treat as proprietary — do not use without explicit permission
+
+quick_reference:
+  new_dependency: license compatible? CVE-free? maintained? popular?
+  ci_build: auto-scan vulnerabilities and licenses
+  release: generate SBOM, review every warning
+  critical_cve: patch within 48 hours
+
+related_standards:
+  - supply-chain-attestation
+  - versioning
+  - release-readiness-gate

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

@@ -1,8 +1,8 @@
 ---
 source: ../../CHANGELOG.md
-source_version: 6.3.7
-translation_version: 6.3.7
-last_synced: 2026-08-07
+source_version: 6.3.9
+translation_version: 6.3.9
+last_synced: 2026-08-09
 status: current
 ---
 
@@ -17,6 +17,21 @@ status: current
 
 ## [Unreleased]
 
+## [6.3.9] - 2026-08-09
+
+### 修复
+
+- **标准索引声明的数字與 sync 检查对不上，而两者描述的是同一份 manifest。** 6.3.8 让检查改為透過 registry 解析 manifest 项目；而索引区块仍直接声明 manifest 的 `installedStandards.length`。在一個真实项目上那是 78 對 70，差额正是 `MIGRATION-v6` §2 於 6.0.0 移除的八個机器可读标准——它们在兩個主版本之后仍声明於 manifest 中，因为 `uds update` 不会修剪它们。撇开检查不谈，七十八本来就是错的数字：它就写在「權威清單為 `.standards/manifest.json` 的 `standards` 字段」正上方——把读者指向这个差異的来源、仿佛那就解決了它——并且告訴 agent 去期待八個并不存在的文件。区块现在数的是解析得到文件的项目，其余在下方指名並说明它们为何还在，于是兩個数字都会出现，都不必靠推测。
+
+## [6.3.8] - 2026-08-08
+
+### 修复
+
+- **`uds deps` 对一个它没有检查过的集合打了绿勾。** 對一個没有运行期依赖、且使用 pnpm lockfile 的專案執行時，它印出 `0 runtime dependencies checked`，接著 `no package-lock.json — nothing to compare the registry against`，接著 `✓ every dependency resolves to the version you test against`，然後 exit 0。两项事实都为真；合起来却宣称一個这个命令读不了的 repo 已被检查而且没问题，而任何接在这个 exit code 上的闸门都会同意。`clean` 的定义是三个空列表的合取，在空集合上恒真——而覆盖它的测试正是以「分母会跟着结论一起走」为由断言了这件事。分母确实跟着走了，却什么也没改变：打勾紧接其后，而 exit code 完全没有带上那个计数。**打印分母不足以阻止空集合被读成安心；拒绝给出结论才可以。** 同時修复該訊息的後半：该项目有一份完全正常的 `pnpm-lock.yaml`，而被告知「你没有 lockfile」正是读者判定工具搞错、从此不再读它的方式。命令现在会说出找到的是什么、以及自己读的是哪一种格式。
+- **registry ID 不是檔名，而有八個地方把它當成檔名用。** manifest 的 `standards` 陣列是刻意混合的：core 標準自 v3.4.0 起改為 registry ID，option 條目維持其上游來源路徑，因為 option 沒有 ID。而每個消費端都對兩者一律套 `basename()`——對路徑正確，對 ID 是 no-op。`error-code-standards` 安裝為 `error-codes.ai.yaml`、`logging-standards` 為 `logging.ai.yaml`、`ai-agreement` 為 `ai-agreement-standards.ai.yaml`；多數 ID 確實等於它的 basename，這正是它能存活的原因。同一個錯誤導出三種失效：minimal 模式印出 `.standards/<id>`，使**某採用者 AGENTS.md 的七十個路徑中有七個指不到東西**，而它們正下方那一行寫著「你必須讀取並遵循 `.standards/` 裡的標準」；索引區塊用 `.ai.yaml` 後綴過濾，而沒有任何 ID 帶這個後綴，於是**所有核心標準都被丟掉**，同一個採用者先前的區塊列了七個 option、六十三項核心標準一個也沒有；任務對應表以檔名為鍵，ID 一個也對不上，該標準就安靜地沒有對應。解析現在是一個匯出的函式，八個呼叫點共用，而解析不出的條目會列在清單下方回報，不會被印成路徑。
+- **那個專門用來抓這種漂移的檢查，帶著同一個缺陷。** `AGENTS.md Standards Sync` 對一份七十項的 manifest 回報 `7/7`：`.ai.yaml` 過濾只留下七個 option 條目，七個都在，於是打勾——升級前六十三項標準不在區塊裡時打勾，升級後區塊裡有七個死路徑時也打勾。對它所量測對象的九成視而不見，而且全程綠燈。在同一個專案上現在是 67/67，而手動弄壞一個路徑會回報 66/67 並指名該檔。它需要的那份對照，早就建在它上方一百七十行處，註解甚至指名了那個案例。
+- **產生器仍把 6.0.0 移除的路徑寫進採用者的指令檔。** `MIGRATION-v6` §2 移除了八個機器可讀標準，它們的執行期已移往採用層；三行 `Reference:` 與一筆 MUST 等級的任務對應仍指向 `.standards/workflow-enforcement.ai.yaml`。人類可讀的 `core/workflow-enforcement.md` 是刻意保留在上游的，但採用者收到的是 `.standards/` 而非 `core/`，所以它不是替代路徑——這幾行是刪除而非改指。控制該段落的判斷式比對的檔名，自 3.4.0 起沒有任何 manifest 持有，於是那段落對兩個仍宣告該標準的專案早已悄悄不再產生；現在兩種形式都比對。
+
 ## [6.3.7] - 2026-08-07
 
 ### Fixed

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

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

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

@@ -1,8 +1,8 @@
 ---
 source: ../../CHANGELOG.md
-source_version: 6.3.7
-translation_version: 6.3.7
-last_synced: 2026-08-07
+source_version: 6.3.9
+translation_version: 6.3.9
+last_synced: 2026-08-09
 status: current
 ---
 
@@ -17,6 +17,21 @@ status: current
 
 ## [Unreleased]
 
+## [6.3.9] - 2026-08-09
+
+### 修正
+
+- **標準索引宣告的數字與 sync 檢查對不上，而兩者描述的是同一份 manifest。** 6.3.8 讓檢查改為透過 registry 解析 manifest 項目；而索引區塊仍直接宣告 manifest 的 `installedStandards.length`。在一個真實專案上那是 78 對 70，差額正是 `MIGRATION-v6` §2 於 6.0.0 移除的八個機器可讀標準——它們在兩個主版本之後仍宣告於 manifest 中，因為 `uds update` 不會修剪它們。撇開檢查不談，七十八本來就是錯的數字：它就寫在「權威清單為 `.standards/manifest.json` 的 `standards` 欄位」正上方——把讀者指向這個差異的來源、彷彿那就解決了它——並且告訴 agent 去期待八個並不存在的檔案。區塊現在數的是解析得到檔案的項目，其餘在下方指名並說明它們為何還在，於是兩個數字都會出現，都不必用推的。
+
+## [6.3.8] - 2026-08-08
+
+### 修正
+
+- **`uds deps` 對一個它沒有檢查過的集合打了綠勾。** 對一個沒有執行期相依、且使用 pnpm lockfile 的專案執行時，它印出 `0 runtime dependencies checked`，接著 `no package-lock.json — nothing to compare the registry against`，接著 `✓ every dependency resolves to the version you test against`，然後 exit 0。兩項事實都為真；合起來卻宣稱一個這個指令讀不了的 repo 已被檢查而且沒問題，而任何接在這個 exit code 上的閘門都會同意。`clean` 的定義是三個空清單的合取，在空集合上恆真——而涵蓋它的測試正是以「分母會跟著結論一起走」為由斷言了這件事。分母確實跟著走了，卻什麼也沒改變：打勾緊接其後，而 exit code 完全沒有帶上那個計數。**印出分母不足以阻止空集合被讀成安心；拒絕給出結論才可以。** 同時修正該訊息的後半：該專案有一份完全正常的 `pnpm-lock.yaml`，而被告知「你沒有 lockfile」正是讀者判定工具搞錯、從此不再讀它的方式。指令現在會說出找到的是什麼、以及自己讀的是哪一種格式。
+- **registry ID 不是檔名，而有八個地方把它當成檔名用。** manifest 的 `standards` 陣列是刻意混合的：core 標準自 v3.4.0 起改為 registry ID，option 條目維持其上游來源路徑，因為 option 沒有 ID。而每個消費端都對兩者一律套 `basename()`——對路徑正確，對 ID 是 no-op。`error-code-standards` 安裝為 `error-codes.ai.yaml`、`logging-standards` 為 `logging.ai.yaml`、`ai-agreement` 為 `ai-agreement-standards.ai.yaml`；多數 ID 確實等於它的 basename，這正是它能存活的原因。同一個錯誤導出三種失效：minimal 模式印出 `.standards/<id>`，使**某採用者 AGENTS.md 的七十個路徑中有七個指不到東西**，而它們正下方那一行寫著「你必須讀取並遵循 `.standards/` 裡的標準」；索引區塊用 `.ai.yaml` 後綴過濾，而沒有任何 ID 帶這個後綴，於是**所有核心標準都被丟掉**，同一個採用者先前的區塊列了七個 option、六十三項核心標準一個也沒有；任務對應表以檔名為鍵，ID 一個也對不上，該標準就安靜地沒有對應。解析現在是一個匯出的函式，八個呼叫點共用，而解析不出的條目會列在清單下方回報，不會被印成路徑。
+- **那個專門用來抓這種漂移的檢查，帶著同一個缺陷。** `AGENTS.md Standards Sync` 對一份七十項的 manifest 回報 `7/7`：`.ai.yaml` 過濾只留下七個 option 條目，七個都在，於是打勾——升級前六十三項標準不在區塊裡時打勾，升級後區塊裡有七個死路徑時也打勾。對它所量測對象的九成視而不見，而且全程綠燈。在同一個專案上現在是 67/67，而手動弄壞一個路徑會回報 66/67 並指名該檔。它需要的那份對照，早就建在它上方一百七十行處，註解甚至指名了那個案例。
+- **產生器仍把 6.0.0 移除的路徑寫進採用者的指令檔。** `MIGRATION-v6` §2 移除了八個機器可讀標準，它們的執行期已移往採用層；三行 `Reference:` 與一筆 MUST 等級的任務對應仍指向 `.standards/workflow-enforcement.ai.yaml`。人類可讀的 `core/workflow-enforcement.md` 是刻意保留在上游的，但採用者收到的是 `.standards/` 而非 `core/`，所以它不是替代路徑——這幾行是刪除而非改指。控制該段落的判斷式比對的檔名，自 3.4.0 起沒有任何 manifest 持有，於是那段落對兩個仍宣告該標準的專案早已悄悄不再產生；現在兩種形式都比對。
+
 ## [6.3.7] - 2026-08-07
 
 ### Fixed