universal-dev-standards 5.16.0 → 6.0.0

package/bundled/core/model-provenance.md

@@ -0,0 +1,181 @@
+# Model Provenance Policy Standards
+
+> **Version**: 1.0.0 | **Status**: Active | **Updated**: 2026-06-17
+> **AI-optimized version**: `ai/standards/model-provenance.ai.yaml`
+> **Spec**: XSPEC-255 (cross-project/specs/XSPEC-255-model-provenance-policy.md)
+
+**Scope**: universal
+
+## Overview
+
+Model selection is not only "cost × quality" — there is a **third axis: whether the
+model's *source* is acceptable to the customer** (geopolitics / data sovereignty /
+regulation). A regulated or geopolitically sensitive buyer (e.g. a Taiwanese
+finance/government customer) may be unable to use models from a given jurisdiction;
+the strictest will reject even **locally-run open weights** of that origin. This
+standard makes the **model's provenance a first-class, enforced, auditable property**:
+declare an acceptable-source policy, **block** non-compliant model choices fail-closed,
+and emit auditable evidence ("this delivery used no models of the denied origin").
+
+It is the **provenance (source)** member of the governance-gate family — alongside
+`license-compliance` (XSPEC-193, *licensing*) and `verification-oracle` (XSPEC-256,
+*correctness*) — which all share the same shape: **registry/check → fail-closed gate →
+audit evidence → human-escalation ceiling**. The three are profiles of one mechanism
+over three axes: **licensing / provenance / correctness**.
+
+> **Scope.** This standard defines the *provenance mechanism* (origin registry, policy
+> schema, fail-closed enforcement at model-selection points, audit evidence, ceiling).
+> The **policy content (the concrete allow/deny lists) belongs to the customer or a
+> compliance pack** — it is their domain decision (DEC-075 neutral mechanism / DEC-063
+> customer-owned compliance posture). Enforcement engine wiring (e.g. a VibeOps provider
+> abstraction / router gate) is a downstream adoption concern, not part of this standard.
+
+## Requirements
+
+| ID | Rule | Level |
+|----|------|-------|
+| REQ-001 | Model Origin Registry as a first-class artifact (model → vendor → jurisdiction/origin class) | MUST |
+| REQ-002 | Provenance Policy schema (allow/deny origins, local-weights distinction, mode, unknown-origin) | MUST |
+| REQ-003 | Fail-closed enforcement at every model-selection point | MUST |
+| REQ-004 | Auditable provenance evidence (model + origin per generation; compliance report) | MUST |
+| REQ-005 | Reference policy pack(s) demonstrating the mechanism (content owned by customer/pack) | SHOULD |
+| REQ-006 | Unknown-origin model → fail-closed block/escalate (no silent pass) | MUST |
+| REQ-007 | Provenance policy content sovereignty — mechanism neutral, policy owned by customer | SHOULD |
+
+### REQ-001 — Model Origin Registry
+
+Each known model MUST be classified by **vendor → jurisdiction → origin class**. Like the
+`license-compliance` license DB, the registry is maintainable and extensible by the
+ecosystem/customer. At minimum the origin classes distinguish western-frontier,
+western-open, and other-origin so a policy can be expressed against them. Example:
+
+| Model | Vendor | Jurisdiction | Origin class |
+|-------|--------|--------------|--------------|
+| Claude | Anthropic | US | western-frontier |
+| GPT / o-series | OpenAI | US | western-frontier |
+| Gemini | Google | US | western-frontier |
+| Llama | Meta | US | western-open |
+| Mistral | Mistral | EU | western-open |
+| Gemma | Google | US | western-open |
+| DeepSeek | DeepSeek | CN | china-origin |
+| MiniMax | MiniMax | CN | china-origin |
+| Qwen | Alibaba | CN | china-origin |
+
+### REQ-002 — Provenance Policy Schema
+
+A per-project/per-customer policy MUST be expressible with at least: `allow_origins` /
+`deny_origins` (by origin class), a **local-weights distinction** (a model accessed via a
+foreign API — data egress — vs the same model's open weights run locally — data stays
+local but the weights are foreign), an enforcement `mode` (`block` / `warn` /
+`require_human`), and an `unknown_origin` behaviour that is **fail-closed** by default.
+
+```jsonc
+{
+  "allow_origins": ["western-frontier", "western-open"],
+  "deny_origins": ["china-origin"],
+  "china_local_weights": "deny",   // deny | allow_local_only — strict buyers deny even local foreign weights
+  "mode": "block",                 // block | warn | require_human
+  "unknown_origin": "block"        // fail-closed
+}
+```
+
+### REQ-003 — Fail-Closed Enforcement
+
+At **every model-selection point** (per-agent config / routing decision / BYOK), the chosen
+model's origin MUST be checked against the active policy. A violation MUST **block (or
+escalate)** fail-closed — never silently pass (mirrors the `license-compliance` blocklist
+and the `verification-oracle` non-reproduction block). Enforcement plugs in *before* routing
+so a disallowed source is swapped for an acceptable model rather than used.
+
+### REQ-004 — Audit Evidence
+
+Each generation MUST record the **model used + its origin class**, enabling a compliance
+report such as *"this delivery used no models of the denied origin."* The evidence plugs
+into the audit logger / hash chain, the `verification-oracle` correctness evidence
+(XSPEC-256), and the telemetry allowlist (DEC-066). **This report is the outward proof of
+the provenance/governance moat** and a compliance artifact for the customer.
+
+### REQ-005 — Reference Policy Pack(s)
+
+The mechanism SHOULD ship a small number of **reference policy packs** that demonstrate it
+(for example a pack that denies a given origin including local weights). The mechanism is
+domain-neutral; the **concrete policy content is owned by the customer or a compliance
+partner** (mirrors the reference-pack positioning of compliance domain packs).
+
+### REQ-006 — Unknown-Origin Fail-Closed
+
+A model whose origin is **not in the registry** (unknown provenance) MUST NOT be silently
+allowed. The system MUST treat unknown origin as a **fail-closed block or escalation**
+(REQ-002 `unknown_origin`), consistent with the governance-gate "no silent pass" rule.
+
+### REQ-007 — Provenance Policy Content Sovereignty
+
+The provenance *mechanism* is domain-neutral (DEC-075); the *policy content* (which origins
+are acceptable) is owned by the customer (DEC-063). Adopters SHOULD keep policies
+customer-scoped and isolated (see `license-compliance` / `verification-oracle` per-customer
+patterns, DEC-064).
+
+## Principles
+
+| ID | Principle |
+|----|-----------|
+| P-1 | Provenance is a Third Axis — model choice is cost × quality × *acceptable source* |
+| P-2 | Registry First — every model carries vendor/jurisdiction/origin class before a policy can act |
+| P-3 | Fail-Closed — a denied or unknown origin blocks or escalates; never silent pass |
+| P-4 | Evidence-Based — every generation records model + origin; a compliance report is producible |
+| P-5 | Human Ceiling — ambiguous/`require_human` provenance escalates to a human (DEC-076) |
+| P-6 | Content Sovereignty — mechanism neutral, acceptable-source policy owned by the customer |
+
+## Gate Timing
+
+```
+model-selection point (per-agent config / router / BYOK)
+        │
+        ├─→ [provenance policy check]  ← REQ-003 fail-closed, pre-routing
+        │         │
+        │   denied / unknown ──→ block OR escalate to human  ← REQ-006 / P-5 ceiling
+        │         │
+        │   allowed ──→ proceed; record model + origin  ← REQ-004
+        ↓
+   provenance audit / compliance report  ← REQ-004 (outward moat proof)
+```
+
+## Relationship to the Governance-Gate Family
+
+| Profile | Standard | Axis | Registry/Check | Block trigger |
+|---------|----------|------|----------------|---------------|
+| Licensing | `license-compliance` (XSPEC-193) | legal | blocklist/allowlist/greylist | prohibited license |
+| **Provenance** | **`model-provenance` (XSPEC-255)** | **source** | **model origin registry + policy** | **denied / unknown origin** |
+| Correctness | `verification-oracle` (XSPEC-256) | correct | ground-truth registry | non-reproduction / drift |
+
+All three: fail-closed + audit evidence + customer override telemetered + human-escalation ceiling.
+
+## Integration with Existing Standards
+
+- **`license-compliance`** — sibling profile; the allowlist/denylist + fail-closed + audit +
+  override skeleton is shared (evaluate whether the two are one governance subsystem).
+- **`verification-oracle`** — sibling profile; the provenance audit evidence sits alongside
+  the correctness evidence in the same audit/report artifact.
+- **`model-selection`** — provenance is a *constraint* applied before the cost/quality
+  right-sizing of `model-selection`; an unacceptable source is removed from the candidate set.
+- **`security-standards`** — data-egress concerns (foreign-API access) align with data
+  handling/security; local-weights distinction (REQ-002) is a data-sovereignty control.
+- **`verification-evidence`** — the provenance report is a kind of verification evidence
+  (model + origin + no-denied-origin trace).
+
+## Related Specs
+
+- XSPEC-255 — Model Provenance Policy complete spec (this standard's source)
+- XSPEC-193 / XSPEC-256 — sibling governance-gate profiles (licensing / correctness)
+- DEC-075 — VibeOps domain-neutral positioning (neutral mechanism / policy belongs to ecosystem)
+- DEC-063 — Legal & compliance strategy (regulated / sovereignty-sensitive customers)
+- DEC-064 — Customer IP isolation strategy (per-customer policy scoping)
+- DEC-066 — Telemetry-driven product evolution (audit/telemetry allowlist)
+- DEC-076 — Self-serve north star (provenance = a self-serve ceiling)
+- XSPEC-254 — Positioning pre-mortem (§7 #5 cost-structure / token economics — origin axis)
+
+## Changelog
+
+| Version | Date | Changes |
+|---------|------|---------|
+| v1.0.0 | 2026-06-17 | Initial — REQ-001~007: model origin registry, provenance policy schema, fail-closed enforcement at model-selection points, audit evidence, reference policy packs, unknown-origin fail-closed, policy content sovereignty (XSPEC-255) |

package/bundled/core/model-selection.md

@@ -2,8 +2,8 @@
 
 > **Language**: English | [繁體中文](../locales/zh-TW/core/model-selection.md)
 
-**Version**: 1.0.0
-**Last Updated**: 2026-03-20
+**Version**: 1.0.1
+**Last Updated**: 2026-06-10
 **Applicability**: AI-assisted development with multiple model tiers
 **Scope**: universal
 **Inspired by**: [Superpowers](https://github.com/obra/superpowers) — subagent-driven-development (MIT)
@@ -231,3 +231,28 @@ Escalation means using a more capable model, not repeating the same action. The
 - **能力維度（XSPEC-027）** — 基於模型能力（Can this model do it?）
 
 兩者並用：先依複雜度選擇 Tier，再依能力維度確認選中的模型支援任務所需的 capability。
+
+---
+
+## Navigation Integration | 與下一步建議整合
+
+The [ai-response-navigation](ai-response-navigation.md) standard (Rule R6, optional) allows each next-step suggestion option to carry a Tier annotation. The complexity signals in this standard serve as the judgment basis.
+
+**Vendor-neutral principle**: Tier names (Fast / Standard / Capable) are tool-agnostic labels. They do not correspond to any specific vendor's model identifiers. Each platform or tool independently maintains its own Tier → concrete model mapping.
+
+Example mapping (illustrative only, not normative):
+
+| Tier | Typical capability level |
+|------|--------------------------|
+| Fast | Lightweight / instruction-following |
+| Standard | Balanced reasoning + code generation |
+| Capable | Advanced reasoning, architectural analysis |
+
+---
+
+## Version History
+
+| Version | Date | Changes |
+|---------|------|---------|
+| 1.0.1 | 2026-06-10 | Add Navigation Integration section (R6 cross-reference; vendor-neutral principle) |
+| 1.0.0 | 2026-03-20 | Initial release |

package/bundled/core/packaging-standards.md

@@ -269,6 +269,7 @@ The combination of (a) producer using auto-extension tar and (b) consumer not ve
 - [Pipeline Integration Standards](pipeline-integration-standards.md) — CI/CD pipeline configuration
 - [Checkin Standards](checkin-standards.md) — Quality gates before packaging
 - [Versioning Standards](versioning.md) — Version numbers used in package artifacts
+- [Supply Chain Attestation](supply-chain-attestation.md) — SBOM / SLSA provenance / signing of the packaged artifact (format integrity here is archive-level; attestation adds source-to-artifact provenance)
 
 ---
 

package/bundled/core/performance-standards.md

@@ -2,8 +2,8 @@
 
 > **Language**: English | [繁體中文](../locales/zh-TW/core/performance-standards.md)
 
-**Version**: 1.1.0
-**Last Updated**: 2026-01-29
+**Version**: 1.2.0
+**Last Updated**: 2026-06-17
 **Applicability**: All software projects
 **Scope**: universal
 **Industry Standards**: ISO/IEC 25010 Performance Efficiency
@@ -323,6 +323,97 @@ Analogous to the SRE Error Budget concept, a Performance Budget defines the tole
 
 ---
 
+## Migration Non-Functional Parity (XSPEC-286)
+
+> Part of the [XSPEC-284](https://github.com/AsiaOstrich/universal-dev-standards) 9-axis migration completeness matrix (**axis ⑥ — non-functional**). Covers the omission class "function is correct, data is correct, but **it runs differently**" during a legacy refactor / rewrite. This section adds **migration-specific** before/after semantics on top of the general baseline/drift machinery above; it does NOT replace the general performance framework.
+
+### Why this is a real gap
+
+The general Baseline Management above answers "did *this version* regress vs *its own* prior baseline". It does NOT answer "does the **new** system match the **legacy** system it replaces". In a rewrite (e.g. PHP single-request → .NET shared-state threads) the latency/throughput/isolation characteristics of legacy are **implicit and undocumented**, so per-request functional parity and behavior-snapshot parity both pass while the system silently runs slower, exhausts a smaller pool, or loses a lock semantic.
+
+### Differential oracle, not absolute threshold
+
+Migration parity uses **legacy as the baseline** and a **declared tolerance**, not the absolute targets in the tables above. The legacy system's measured behavior is the oracle; "no regression beyond the declared tolerance" is the pass criterion. This makes divergence self-report instead of relying on someone remembering to enumerate every hot path.
+
+### Step 1 — Mechanized non-functional baseline capture (R3)
+
+Legacy non-functional characteristics are mostly implicit. Derive the baseline **mechanically** (not from memory) from legacy artifacts:
+
+| Source | Derived baseline item |
+|--------|----------------------|
+| Key routes / controllers | p50 / p95 / p99 latency per critical path |
+| Hot queries / slow-query log | Per-query latency, rows scanned |
+| Background jobs / cron | Job duration, throughput (records/min) |
+| Connection pool config | Min/max connections, idle/connection timeout |
+| Timeout / rate-limit config | Per-endpoint timeout, requests/min, burst |
+| Transaction config | Isolation level (READ COMMITTED / REPEATABLE READ / SERIALIZABLE) |
+
+The captured set is **both** the comparison baseline for the regression gate **and** the to-verify checklist for resource/limit parity (Step 4).
+
+### Step 2 — Performance regression differential gate (R1)
+
+For each baseline path, measure the corresponding path in the new system and compare against the **legacy baseline** within a declared tolerance.
+
+| Metric | Default migration tolerance | Block when |
+|--------|----------------------------|-----------|
+| p50 latency | ≤ +10% vs legacy | > +10% |
+| p95 latency | ≤ +15% vs legacy | > +15% |
+| p99 latency | ≤ +20% vs legacy | > +20% |
+| Throughput | ≤ -10% vs legacy | > -10% decrease |
+
+Tolerances are **per-path configurable** (a batch job and an interactive endpoint differ). Start in **shadow** (measure-only, do not block) to collect samples and calibrate per-path tolerances, then promote to blocking.
+
+**Gate timing**: pre-UAT (catch regression before sign-off) **and** post-cutover (catch regression that only appears under real production load).
+
+```markdown
+## Migration Performance Parity Report — <path>
+
+| Metric | Legacy baseline | New system | Δ | Tolerance | Status |
+|--------|-----------------|------------|---|-----------|--------|
+| p50 | [X]ms | [Y]ms | +[Z]% | +10% | PASS/FAIL |
+| p95 | [X]ms | [Y]ms | +[Z]% | +15% | PASS/FAIL |
+| p99 | [X]ms | [Y]ms | +[Z]% | +20% | PASS/FAIL |
+| Throughput | [X] rps | [Y] rps | -[Z]% | -10% | PASS/FAIL |
+
+**Mode**: shadow (measure-only) / blocking
+**Overall**: PASS / FAIL
+```
+
+### Step 3 — Concurrency isolation verification (R2)
+
+The same resource (same record / same account balance / same sequence number) may be accessed by multiple concurrent operations. Legacy lock / transaction-isolation / ordering guarantees are **implicit behavior** and are routinely changed by a rewrite — and **neither functional tests nor behavior-snapshot parity catch this** (per-request parity ≠ concurrency parity, the same blind spot class as "per-request ≠ data-at-rest").
+
+**Method**: drive a race with concurrent stress, then assert **domain invariants** rather than checking outputs one-at-a-time.
+
+| Invariant class | Example assertion |
+|-----------------|-------------------|
+| Conservation | `SUM(balance)` unchanged after N concurrent transfers |
+| Uniqueness | no duplicate sequence number under concurrent allocation |
+| No lost update | last-writer-wins not silently replacing a committed write |
+| Ordering | events applied in a guaranteed order under concurrency |
+
+Detecting an **isolation downgrade** (e.g. legacy SERIALIZABLE → new READ COMMITTED, or a removed row lock) blocks. The invariants themselves are domain-defined; where a concurrency case overlaps a state-transition or temporal invariant, **the state-machine / temporal concern is owned by XSPEC-287** (axis ⑧) and concurrency race is owned here (axis ⑥) — see XSPEC-287 §boundary.
+
+**Gate timing**: pre-UAT.
+
+### Step 4 — Resource / limit parity (R4)
+
+Verify that legacy resource limits are not **unintentionally** changed by the rewrite (a timeout silently dropping from 30s to 5s fails long jobs; a smaller pool serializes traffic). Add to the non-functional reconciliation checklist:
+
+- [ ] Request / operation **timeouts** match legacy (or change is declared)
+- [ ] **Rate limits** (requests/min, burst) match legacy
+- [ ] **Connection pool** min/max and idle/connection timeout match legacy
+- [ ] **Batch sizes** match legacy
+- [ ] **Transaction isolation level** matches legacy (cross-check with Step 3)
+
+Each item is either matched or has a **declared, justified** delta. An undeclared delta is a known regression risk and blocks cutover.
+
+### Completeness declaration (matrix alignment)
+
+Axis ⑥ of the migration completeness matrix is satisfied when this section declares all three: **derive** (Step 1 mechanized baseline), **oracle** (Step 2 regression differential + Step 3 invariant assertions), and **gate timing** (pre-UAT + post-cutover). Reuse the general baseline/drift and `observability-assistant` measurement machinery — this section adds only the migration before/after and concurrency-isolation semantics, it does not rebuild a general performance framework.
+
+---
+
 ## Per-Release Capacity Sign-off
 
 This section defines the **capacity gate** that must be satisfied before production release (Dimension 10 in `release-readiness-gate.md`, Tier-3).
@@ -395,6 +486,8 @@ The capacity sign-off is `N/A` (with documented rationale) when:
 - [Code Review Checklist](code-review-checklist.md) - Performance review
 - [Deployment Standards](deployment-standards.md) - Performance validation pre-deployment
 - [Release Readiness Gate](release-readiness-gate.md) - Dimension 1 (load) and Dimension 10 (capacity)
+- [Behavior Snapshot](behavior-snapshot.md) - Functional parity oracle (complements migration non-functional parity)
+- [Full Coverage Testing](full-coverage-testing.md) - Concurrency dimension cross-reference
 
 ---
 
@@ -402,6 +495,7 @@ The capacity sign-off is `N/A` (with documented rationale) when:
 
 | Version | Date | Changes |
 |---------|------|---------|
+| 1.2.0 | 2026-06-17 | Added Migration Non-Functional Parity (XSPEC-286, axis ⑥): before/after differential regression gate, concurrency isolation verification, resource/limit parity, mechanized baseline capture |
 | 1.1.0 | 2026-01-29 | Refactored: Split into Rules + Guide, moved explanations to guide |
 | 1.0.0 | 2026-01-29 | Initial release |
 

package/bundled/core/pii-classification.md

@@ -0,0 +1,148 @@
+# PII Classification and Handling Standards
+
+> **Version**: 1.1.0 | **Status**: Active | **Updated**: 2026-06-19
+> **AI-optimized version**: `ai/standards/pii-classification.ai.yaml`
+> **Spec**: XSPEC-066 (cross-project/specs/XSPEC-066-uds-compliance-audit-pack.md)
+
+**Scope**: universal
+
+## Overview
+
+This standard defines how **Personally Identifiable Information (PII)** and
+sensitive personal data is classified, labeled, stored, transmitted, and disposed
+of. It covers a three-tier data-sensitivity classification, mandatory handling
+controls per tier, data-minimization principles, consent-management requirements,
+retention/deletion schedules, and cross-border transfer restrictions. It is
+aligned with GDPR Article 9, CCPA, and general privacy-by-design principles.
+
+It is part of the **compliance & audit pack** (XSPEC-066). The PII tiers it
+defines drive the masking rules executed by `logging-standards` and the
+mandatory data-access events recorded by `audit-trail`.
+
+> **Scope.** This standard defines the *classification tiers* and the *handling
+> controls* per tier. The concrete masking/tokenization library, the secrets
+> store for encryption keys, and the PIA workflow tool are adoption choices.
+
+## Requirements
+
+| ID | Rule | Level |
+|----|------|-------|
+| REQ-001 | PII data-sensitivity classification (TIER-1/2/3) | MUST |
+| REQ-002 | Data minimization and purpose limitation | MUST |
+| REQ-003 | PII masking and anonymization in non-production | MUST |
+| REQ-004 | Data retention and deletion schedule | MUST |
+| REQ-005 | Cross-border data-transfer controls | MUST |
+| REQ-006 | PII impact assessment (PIA) for new features | SHOULD |
+
+### REQ-001 — PII Data Sensitivity Classification
+
+All data fields containing personal information MUST be classified into one of
+three tiers before storage or processing:
+
+| Tier | Examples | Required controls |
+|------|----------|-------------------|
+| **TIER-1** (Highly sensitive) | Health data, financial account numbers, government IDs, biometrics, passwords, SSNs | Encryption at rest and in transit, access logging, no caching |
+| **TIER-2** (Sensitive) | Full name + contact-info combination, location history, behavioral profiles, IP addresses | Encryption in transit, access controls |
+| **TIER-3** (General PII) | First name only, country-level location, general demographics | Standard access controls |
+
+### REQ-002 — Data Minimization and Purpose Limitation
+
+Systems MUST collect only the minimum PII necessary for the explicitly stated
+purpose. Each PII field in the data model MUST have a documented business purpose
+and legal basis (consent, contract, legitimate interest, legal obligation).
+Collecting PII without a documented purpose is **PROHIBITED**. Purpose limitation
+MUST be enforced: data collected for purpose A MUST NOT be used for an unrelated
+purpose B without separate consent.
+
+### REQ-003 — PII Masking and Anonymization in Non-Production
+
+PII MUST NOT exist in non-production environments (development, staging, test)
+unless explicitly required and approved. Test/staging databases MUST use
+anonymized or synthetic data. Any approved exception MUST be time-limited,
+access-controlled, and documented. PII MUST be masked in application logs:
+email as `u***@domain.com`, phone as `+1-XXX-XXX-1234`, card numbers as
+`****-****-****-1234`.
+
+### REQ-004 — Data Retention and Deletion Schedule
+
+Every data category containing PII MUST have a documented retention schedule with
+a maximum retention period aligned to legal requirements and business need.
+Automated deletion MUST be implemented for data past its retention period.
+Deletion MUST be verifiable (deletion receipts or audit logs). Users exercising
+the right to erasure MUST receive deletion confirmation within 30 days (GDPR) or
+45 days (CCPA).
+
+### REQ-005 — Cross-Border Data Transfer Controls
+
+Transfers of TIER-1 or TIER-2 PII across national borders MUST comply with
+applicable transfer mechanisms. EU → non-adequate-country transfers MUST use
+Standard Contractual Clauses (SCCs) or Binding Corporate Rules. Data-residency
+requirements MUST be documented in the system design. Cross-border transfers MUST
+be logged with destination country and legal basis.
+
+### REQ-006 — PII Impact Assessment for New Features
+
+Any new feature or system change that introduces new PII collection or processing
+SHOULD undergo a Privacy Impact Assessment (PIA) before implementation. The PIA
+MUST document what PII is collected, the purpose, legal basis, retention period,
+third-party sharing, and risk mitigations. Features with TIER-1 PII require a
+mandatory PIA; TIER-2 is recommended.
+
+## Integration with Existing Standards
+
+- **`audit-trail`** — TIER-1/TIER-2 PII reads, exports, and erasure requests are
+  mandatory audit events.
+- **`logging-standards`** — executes the masking rules this standard mandates.
+- **`security-standards`** — encryption-at-rest/in-transit controls for TIER-1
+  reference the project's security baseline.
+- **`database-standards`** — data-dictionary fields carry the PII tier and the
+  documented purpose/legal basis from REQ-002.
+
+## PII Discovery & Hand-Off Contract
+
+The integrations above name the consumers, but a hand-off needs a defined
+**trigger, interface, owner, and state** — otherwise "drives the masking rules"
+is a claim, not a contract. This reuses the `data-contract` REQ-005
+consumer-registration model and the `agent-communication-protocol` §3
+structured-handoff shape.
+
+### Trigger — when classification fires
+
+| When | What happens |
+|------|--------------|
+| New feature design | REQ-006 PII Impact Assessment classifies every new PII field **before** implementation |
+| PR / scan time | A field carrying PII with no tier is a **blocking** finding (CI) |
+| Data-dictionary change | A `database-standards` field gains/loses a PII tier → consumers are re-notified |
+
+### Interface — what crosses
+
+The producer artifact is a **PII classification registry** entry per field:
+`{ field, tier (TIER-1/2/3), purpose, legal_basis, masking_rule, retention }`.
+Consumers register against it (per `data-contract` REQ-005) and are notified on change.
+
+### Owners & registered consumers
+
+| Party | Responsibility |
+|-------|----------------|
+| Data owner / feature author | **Produces** the classification (REQ-001 / REQ-006) |
+| `logging-standards` (consumer) | Applies `masking_rule` to TIER-1/2 in non-prod and logs |
+| `audit-trail` (consumer) | Records mandatory access / export / erasure events |
+| `security-standards` (consumer) | Enforces encryption-at-rest/in-transit for TIER-1 |
+| Privacy / compliance owner | **Notified** on any new TIER-1 field or classification change |
+
+### State transition
+
+`Found → Classified (tier assigned) → Handled (masked / encrypted / retention set) → Verified (consumer confirms the rule is applied)`.
+A field stuck in `Found` (PII with no tier) **blocks release** (REQ-001 + the PR-time trigger above).
+
+## Related Specs
+
+- XSPEC-066 — UDS compliance & audit pack (this standard's source)
+- DEC-041 — EU AI Act 2026 compliance (PII handling as a compliance pillar)
+
+## Changelog
+
+| Version | Date | Changes |
+|---------|------|---------|
+| v1.1.0 | 2026-06-19 | Added: PII Discovery & Hand-Off Contract (trigger / interface / owners / state) so the claimed hand-off to logging-standards / audit-trail is a defined contract, not a claim (XSPEC-292 T16) |
+| v1.0.0 | 2026-06-17 | Initial — REQ-001~006: PII tiers, data minimization, non-prod masking, retention/deletion, cross-border transfer, PIA (XSPEC-066) |

package/bundled/core/pipeline-security-gates.md

@@ -2,7 +2,7 @@
 
 ## 概述
 
-本標準定義嵌入 CI pipeline 各階段的安全檢查點，涵蓋 SAST、DAST、SCA（含 SBOM）和機密掃描，並明確規定各類發現的阻斷（Block）、警告（Warn）、記錄（Log）行為。
+本標準定義嵌入 CI pipeline 各階段的安全檢查點，涵蓋 SAST、DAST、SCA（含 SBOM）、機密掃描，以及發布前的供應鏈簽章驗證，並明確規定各類發現的阻斷（Block）、警告（Warn）、記錄（Log）行為。
 
 ---
 
@@ -11,6 +11,7 @@
 - **機密掃描在 pre-commit**：所有包含機密的提交都必須被阻擋，不得例外
 - **SAST 在建置後**：Critical 和 High 等級發現阻斷 pipeline
 - **SCA + SBOM 在封包階段**：追蹤相依套件風險並產生物料清單
+- **Attestation 驗證在發布前**：封包後、部署前 MUST 驗證 artifact 的 checksum、簽章與 SLSA provenance（消費 supply-chain-attestation 標準的產出，不得「產生 SBOM 卻不驗」）
 - **DAST 在 staging 部署後**：對運行中的應用進行動態掃描
 - **安全閘門失敗 = pipeline 失敗**：不得視為可忽略的警告
 - **任何繞過都需審計軌跡**：禁止靜默跳過安全閘門
@@ -58,7 +59,24 @@
 
 ---
 
-### 4. Post-Staging Deploy — DAST（動態應用安全測試）
+### 4. Pre-Deploy — Artifact Attestation Verification（供應鏈簽章驗證）
+
+| 項目 | 說明 |
+|------|------|
+| 驗證範圍 | 已封包的發布 artifact（檔案壓縮檔 / 容器映像）|
+| 推薦工具 | cosign（`verify-blob` / `verify`）、sha256sum、slsa-verifier |
+| 阻斷條件 | 簽章驗證失敗、checksum 不符、SLSA provenance 缺失 |
+| 警告條件 | SLSA 等級低於目標（公開發布建議 ≥ L2）|
+
+封包階段（gate 3）產生 SBOM 後，**部署/發布前 MUST 驗證** artifact 的完整性與來源證明，
+避免「產生了 SBOM/簽章卻從不驗證」的假保證：比對 `checksums.txt` 的 SHA256、以
+`cosign verify-blob` 驗 SBOM 與 provenance 簽章、確認 SLSA provenance 存在。完整的
+產生與驗證指令、Release Bundle 結構見
+[supply-chain-attestation.md](supply-chain-attestation.md)。
+
+---
+
+### 5. Post-Staging Deploy — DAST（動態應用安全測試）
 
 | 項目 | 說明 |
 |------|------|
@@ -97,6 +115,7 @@
 |---------|------|
 | 機密管理 | 整合 HashiCorp Vault 或 AWS Secrets Manager 進行機密注入 |
 | SBOM 註冊表 | 上傳 SBOM 至 dependency-track 或 grype-db 持續監控 |
+| Artifact 簽章 | 發布前以 cosign 驗證 SBOM/provenance 簽章與 checksum（見 supply-chain-attestation）|
 | 事故回應 | Critical 發現自動建立事故單 |
 
 ---
@@ -106,6 +125,7 @@
 - [security-standards.md](security-standards.md) — 應用安全基礎標準
 - [pipeline-integration-standards.md](pipeline-integration-standards.md) — CI 管線整合標準
 - [deployment-standards.md](deployment-standards.md) — 部署基礎原則
+- [supply-chain-attestation.md](supply-chain-attestation.md) — SBOM / SLSA provenance / cosign 簽章的產生與驗證（gate 4 消費）
 - AI 格式：[../ai/standards/pipeline-security-gates.ai.yaml](../ai/standards/pipeline-security-gates.ai.yaml)
 
 

package/bundled/core/postmortem-standards.md

@@ -255,6 +255,8 @@ For lower-severity or recurring incidents that don't warrant a full postmortem:
 | **Mitigate** | Reduce impact scope and duration | Implement automatic circuit breaker |
 | **Process** | Improve response procedures | Update on-call handoff checklist |
 
+> **Hand-off to tech-debt tracking**: a Prevent/Mitigate action item that is a long-lived design/architecture remediation (not a quick fix that closes with the incident) MUST be registered in the tech-debt registry per [tech-debt-standards](tech-debt-standards.md) with `Source = postmortem PM-<id>` — so it is budgeted and tracked rather than lost once the incident closes.
+
 ### Status Tracking
 
 ```

package/bundled/core/prd-standards.md

@@ -0,0 +1,91 @@
+# Product Requirements Document Standards
+
+> **Version**: 1.0.0 | **Status**: Active | **Updated**: 2026-06-17
+> **AI-optimized version**: `ai/standards/prd-standards.ai.yaml`
+> **Spec**: XSPEC-069 (cross-project/specs/XSPEC-069-uds-product-layer-pack.md)
+
+**Scope**: universal
+
+## Overview
+
+This standard defines the structure, content requirements, and lifecycle
+governance for **Product Requirements Documents (PRDs)**. It covers the five
+mandatory PRD sections, the bridge from PRD requirements to traceable user
+stories, and the revision policy for changes after kickoff. It ensures product
+intent is clearly communicable to engineering, design, and stakeholders with
+measurable success criteria.
+
+It is part of the **product-layer pack** (XSPEC-069). The PRD is the *upstream*
+of engineering requirements: PRD → user story → requirement. It bridges to
+`requirement-engineering` (the engineering view of requirements) and consumes
+`product-metrics-standards` for success metrics.
+
+> **Scope.** This standard defines the *PRD artifact* (sections, traceability,
+> revision policy). It is a product-layer edge of UDS (per XSPEC-070
+> `standard-admission-criteria`) — the engineering requirement view stays in
+> `requirement-engineering`.
+
+## Requirements
+
+| ID | Rule | Level |
+|----|------|-------|
+| REQ-001 | PRD five sections (Problem, Persona, Success Metrics, Scope, Constraints) | MUST |
+| REQ-002 | PRD → user-story bridge (INVEST, traceable to a success metric) | MUST |
+| REQ-003 | Revision policy (formal change process after kickoff) | MUST |
+
+### REQ-001 — PRD Five Sections
+
+Every PRD MUST contain five sections in order: (1) **Problem Statement** — the
+user pain/opportunity in observable terms, with quantitative data where
+available; (2) **Target User / Persona** — who is affected, referencing named
+personas (≥1 primary, ≥1 secondary) with role, context, and goals;
+(3) **Success Metrics** — 2–4 measurable outcomes, each with current baseline,
+target value, and measurement method; (4) **Scope In / Out** — explicit
+inclusions and exclusions (out-of-scope may reference future PRDs);
+(5) **Constraints** — technical, regulatory, time, budget, or dependency bounds.
+
+### REQ-002 — PRD to User Story Bridge
+
+Each PRD requirement MUST be broken into one or more user stories following the
+INVEST criteria from `requirement-engineering`. Every story derived from a PRD
+MUST be traceable to at least one PRD success metric; stories that cannot be
+linked MUST be flagged for PM review before entering the backlog. The
+traceability link (PRD section ID → user-story ID → success metric) MUST be
+maintained in the backlog tool or as a matrix in the PRD.
+
+### REQ-003 — Revision Policy
+
+PRD changes requested after the development kickoff meeting MUST follow a formal
+process: (1) the proposed change is documented with rationale and impact
+assessment; (2) stakeholder sign-off is obtained from PM, Tech Lead, and Design
+Lead; (3) scope impact is assessed — added scope must move a corresponding item
+out of scope or adjust the timeline; (4) version history is updated with date,
+author, change summary, and approver. PRDs modified after kickoff without version
+history are non-compliant. Minor editorial changes (typos, formatting) are exempt
+from sign-off.
+
+## Anti-Patterns
+
+- PRD without measurable success metrics (qualitative goals only, e.g. "improve UX").
+- Scope creep without a change log: adding requirements mid-sprint without documented approval.
+- Solution-first PRD: implementation details before the user problem is established.
+- No explicit out-of-scope section, causing boundary disputes during development.
+- Success metrics defined after development starts, making them unverifiable.
+
+## Integration with Existing Standards
+
+- **`requirement-engineering`** — PRD requirements decompose into INVEST user stories.
+- **`product-metrics-standards`** — PRD success metrics draw from the metric hierarchy.
+- **`user-story-mapping`** — PRD scope is realized as a story map and MVP slice.
+- **`acceptance-criteria-traceability`** — stories carry AC traceable back to PRD metrics.
+
+## Related Specs
+
+- XSPEC-069 — UDS product-layer pack (this standard's source)
+- XSPEC-070 — Governance meta-standards (`standard-admission-criteria` edge review)
+
+## Changelog
+
+| Version | Date | Changes |
+|---------|------|---------|
+| v1.0.0 | 2026-06-17 | Initial — REQ-001~003: five sections, PRD→story bridge, revision policy (XSPEC-069) |