universal-dev-standards 5.17.0 → 6.1.0

package/bundled/core/iac-design-principles.md

@@ -0,0 +1,97 @@
+# Infrastructure as Code Design Principles
+
+> **Version**: 1.0.0 | **Status**: Active | **Updated**: 2026-06-17
+> **AI-optimized version**: `ai/standards/iac-design-principles.ai.yaml`
+> **Spec**: XSPEC-065 (cross-project/specs/XSPEC-065-uds-infrastructure-pack.md)
+
+**Scope**: universal
+
+## Overview
+
+This standard defines the four foundational principles for Infrastructure as Code
+(IaC) authoring: **reproducible, immutable, idempotent, and versioned**. It covers
+state management requirements (remote state with locking), drift detection
+categories, and CI/CD integration. It is designed to ensure infrastructure
+changes are traceable, reversible, and safe to apply repeatedly without unintended
+side effects.
+
+It is part of the **IaC pack** (XSPEC-065) and is the tool-agnostic foundation
+that `container-image-standards` and `secret-management-standards` build on
+(images and secret backends are themselves versioned, reproducible
+infrastructure).
+
+> **Scope.** This standard defines the *authoring principles*, *state-management*
+> rules, and the *drift-handling taxonomy*. The specific IaC tool (Terraform /
+> Pulumi / CloudFormation) and backend are adoption choices, not part of this
+> standard.
+
+## Requirements
+
+| ID | Rule | Level |
+|----|------|-------|
+| REQ-001 | IaC four principles (reproducible, immutable, idempotent, versioned) | MUST |
+| REQ-002 | State management (remote backend, locking, encryption, no local state in VCS) | MUST |
+| REQ-003 | Drift detection (plan on PR; three-category classification) | MUST |
+
+### REQ-001 — IaC Four Principles
+
+All infrastructure definitions MUST adhere to four foundational principles:
+(1) **Reproducible** — given the same inputs and state, applying IaC produces
+identical infrastructure; (2) **Immutable** — infrastructure changes are applied
+by replacing resources, not mutating them in-place; blue/green or rolling
+replacement patterns are preferred over in-place mutations; (3) **Idempotent** —
+applying the same IaC configuration multiple times produces the same result
+without error or unintended side effects; (4) **Versioned** — all IaC definitions
+are stored in version control with meaningful commit messages; no infrastructure
+change is made outside the VCS workflow.
+
+### REQ-002 — State Management
+
+IaC state MUST be stored in a remote backend with locking enabled to prevent
+concurrent modifications. Local state files MUST NOT be committed to version
+control or used in CI/CD pipelines. Recommended backends: Terraform Cloud /
+S3+DynamoDB (Terraform), Pulumi Service / S3 (Pulumi), CloudFormation native
+stack state. State access MUST be restricted to authorized principals via IAM or
+equivalent. State encryption at rest is REQUIRED.
+
+### REQ-003 — Drift Detection
+
+Teams MUST run `plan` (or equivalent) in CI on every pull request to detect
+configuration drift. Drift outcomes MUST be classified into one of three
+categories and handled accordingly: (1) **rollback-to-code** — actual infra
+deviates from code due to a manual change; revert actual to match code on next
+apply; (2) **update-code-from-actual** — actual reflects an intentional change not
+yet codified; update IaC to match, then apply; (3) **manual-reconcile** — drift
+requires human judgment (e.g., data volume changes); escalate to the infra owner
+with a documented decision. Drift reports SHOULD be published to a team channel on
+a scheduled cadence (e.g., daily).
+
+## Anti-Patterns
+
+- Committing local state files (`terraform.tfstate`) to version control.
+- Applying mutable in-place changes (e.g., sed-patching running VMs) instead of replacing resources.
+- Making manual console changes without updating the corresponding IaC definition.
+- Using no remote locking, allowing concurrent applies that corrupt state.
+- Pinning to `latest` provider or module versions, breaking reproducibility.
+
+## Integration with Existing Standards
+
+- **`container-image-standards`** — container images are versioned, reproducible
+  artifacts produced under the same principles.
+- **`secret-management-standards`** — secret backends (Vault/KMS) are managed as
+  access-controlled infrastructure with remote state.
+- **`deployment-standards` / `cd-deployment-strategies`** — immutable replacement
+  (REQ-001) underpins blue/green and rolling deployment patterns.
+- **`no-cicd-deployment`** — even without a CI/CD platform, the four principles and
+  state-management rules still apply to scripted infrastructure changes.
+
+## Related Specs
+
+- XSPEC-065 — UDS infrastructure (IaC) pack (this standard's source)
+- DEC-043 — UDS coverage completeness roadmap (Wave 4 scope)
+
+## Changelog
+
+| Version | Date | Changes |
+|---------|------|---------|
+| v1.0.0 | 2026-06-17 | Initial — REQ-001~003: IaC four principles, state management, drift detection (XSPEC-065) |

package/bundled/core/incident-response.md

@@ -0,0 +1,119 @@
+# Incident Response Standards
+
+> **Version**: 1.0.0 | **Status**: Active | **Updated**: 2026-06-17
+> **AI-optimized version**: `ai/standards/incident-response.ai.yaml`
+> **Spec**: XSPEC-063 (cross-project/specs/XSPEC-063-uds-sre-standards-pack.md)
+
+**Scope**: universal
+
+## Overview
+
+This standard defines the end-to-end **incident response lifecycle**: severity
+classification, response-time SLAs, roles and responsibilities, communication
+protocols, escalation paths, and blameless postmortem requirements. It is
+designed to reduce MTTR, ensure consistent stakeholder communication during
+incidents, and drive systemic reliability improvements through structured
+postmortems.
+
+It is part of the **SRE/operations pack** (XSPEC-063) and is the incident-handling
+member alongside `slo-sli` (error-budget triggers) and `runbook` (executable
+recovery steps). It composes with `virtual-organization-standards` — a SEV-1
+incident spins up the incident virtual organization (IC, Communications Lead,
+Operations Lead) — and feeds the proactive reliability ownership described in
+XSPEC-251 (Operator).
+
+> **Scope.** This standard defines *how incidents are classified, coordinated,
+> communicated, and learned from*. The paging tool (PagerDuty, Opsgenie), the
+> status-page product, and the ticketing system are adoption choices, not part of
+> this standard.
+
+## Requirements
+
+| ID | Rule | Level |
+|----|------|-------|
+| REQ-001 | Severity classification (4-level SEV scale with response SLAs) | MUST |
+| REQ-002 | Incident Commander role (assigned within 10 min for SEV-1/2) | MUST |
+| REQ-003 | Stakeholder communication protocol (defined cadence + status page) | MUST |
+| REQ-004 | Blameless postmortem requirements (5 Whys, action items tracked) | MUST |
+| REQ-005 | On-call rotation and handoff (≥2 engineers, written handoff) | MUST |
+| REQ-006 | Incident retrospective metrics (MTTD/MTTR reviewed monthly) | SHOULD |
+
+### REQ-001 — Severity Classification
+
+Every incident MUST be classified at declaration using a 4-level severity scale.
+**SEV-1** (Critical): complete service outage or data breach affecting all users,
+response within 15 minutes, C-suite notification. **SEV-2** (High): major feature
+unavailable or significant performance degradation affecting >25% of users,
+response within 30 minutes. **SEV-3** (Medium): minor feature unavailable or
+degradation affecting <25% of users, response within 4 hours. **SEV-4** (Low):
+cosmetic issue or very minor impact, response within 24 hours.
+
+### REQ-002 — Incident Commander Role
+
+Every SEV-1 and SEV-2 incident MUST have a designated Incident Commander (IC)
+assigned within 10 minutes of declaration. The IC is responsible for coordinating
+the response bridge, assigning roles (scribe, comms lead, technical leads),
+driving the timeline, making go/no-go decisions on fixes, and initiating the
+postmortem. The IC does NOT directly troubleshoot — their sole focus is
+coordination.
+
+### REQ-003 — Stakeholder Communication Protocol
+
+During SEV-1/SEV-2 incidents, stakeholder updates MUST be sent on a defined
+cadence: initial notification within 15 minutes of declaration, updates every
+30 minutes until resolution, and an immediate update on any severity change or
+major development. Updates MUST include current status, known impact, what is
+being done, and the next update time. The status page MUST be updated
+simultaneously with internal communications.
+
+### REQ-004 — Blameless Postmortem Requirements
+
+Every SEV-1 incident MUST have a blameless postmortem completed within 5 business
+days; SEV-2 incidents within 10 business days. Postmortems MUST be blameless —
+focusing on systemic causes, not individual mistakes. Required sections: timeline,
+impact, root cause (5 Whys), contributing factors, action items with owners and
+due dates, and lessons learned. Action items MUST be tracked to completion.
+
+### REQ-005 — On-Call Rotation and Handoff
+
+Every production service MUST have a documented on-call rotation with at least 2
+engineers. Rotation schedules MUST be published at least 2 weeks in advance.
+On-call handoff MUST include a written summary of active incidents, recent
+incidents still under investigation, known flaky alerts, upcoming planned
+maintenance, and any service-health concerns. Handoff MUST be acknowledged by the
+incoming on-call.
+
+### REQ-006 — Incident Retrospective Metrics
+
+Teams SHOULD track and review incident metrics monthly: MTTD (Mean Time To
+Detect), MTTR (Mean Time To Resolve), incident frequency by severity, repeat
+incidents (same root cause within 90 days), and postmortem action-item completion
+rate. These metrics SHOULD be reviewed in monthly reliability reviews with
+engineering leadership.
+
+## Integration with Existing Standards
+
+- **`runbook`** — the IC and on-call engineers execute typed runbooks during the
+  mitigate phase; SEV runbooks are drilled per the `runbook` cadence.
+- **`slo-sli`** — error-budget burn often triggers incident declaration; SLO
+  impact is summarized in the postmortem.
+- **`postmortem-standards`** — REQ-004 aligns with the blameless postmortem
+  template; this standard sets the trigger and timelines.
+- **`virtual-organization-standards`** — SEV-1 incidents instantiate the incident
+  virtual organization (IC, Communications Lead, Operations Lead).
+- **`alerting-standards`** — alerts initiate detection and severity assessment.
+- **`execution-history`** — automated mitigation actions are recorded as execution
+  history.
+
+## Related Specs
+
+- XSPEC-063 — UDS SRE/operations pack (this standard's source)
+- XSPEC-251 — Operator proactive reliability (proactive ownership upstream of incidents)
+- DEC-041 — EU AI Act 2026 compliance (auditability requires postmortems)
+- DEC-042 — Guardian / Governance Agent pattern (agent-driven runbook execution)
+
+## Changelog
+
+| Version | Date | Changes |
+|---------|------|---------|
+| v1.0.0 | 2026-06-17 | Initial — REQ-001~006: severity classification, incident commander, communication protocol, blameless postmortem, on-call rotation/handoff, retrospective metrics (XSPEC-063) |

package/bundled/core/license-compliance.md

@@ -4,6 +4,8 @@
 > **AI-optimized version**: `ai/standards/license-compliance.ai.yaml`
 > **Agent Spec**: ASPEC-001 (cross-project/aspec/ASPEC-001-license-compliance-agent.md)
 
+**Scope**: universal
+
 ## Overview
 
 Comprehensive license compliance for AI-augmented development, covering both general OSS practice (Tier 1) and AI-specific rules for AI-generated code (Tier 2).

package/bundled/core/logging-standards.md

@@ -2,8 +2,8 @@
 
 > **Language**: English | [繁體中文](../locales/zh-TW/core/logging-standards.md)
 
-**Version**: 1.3.0
-**Last Updated**: 2026-05-26
+**Version**: 1.4.0
+**Last Updated**: 2026-06-17
 **Applicability**: All software projects
 **Scope**: universal
 **Industry Standards**: RFC 5424, OpenTelemetry, W3C Trace Context
@@ -15,6 +15,81 @@
 
 This document defines logging standards for consistent, structured, and actionable application logs across all environments.
 
+## Mandatory Events
+
+> **Closes** UDS issue [#108](https://github.com/AsiaOstrich/universal-dev-standards/issues/108) (XSPEC-234). The rest of this standard defines **how** to write a log entry (level / fields / PII mask / rotation). This section defines **when you MUST write one** — excluding "compliant on paper but materially silent" logging.
+
+Logging that follows every formatting rule but **never fires at the moment that matters** is worse than useless: it gives false confidence during an incident. The events below are the canonical moments where a log entry is **mandatory**. Each declares `when` / `must_log` / `must_NOT_log` / `level` / `rationale`.
+
+### Why this exists (real incidents)
+
+A PHP→.NET migration burned 2 days diagnosing "send failed, no log", because **four layers were all silent**:
+
+1. **Load-balancer marks backend DOWN** (503) on health-probe timeout — backend logged only probe noise, zero business events.
+2. **Framework validation reject** (e.g. ModelState / DTO 501) — the rejecting framework returned before any handler ran, so the **payload was never logged**.
+3. **Auth failure** logged only "Account or password error" — **no uid, no source IP** → un-investigable.
+4. **Background worker alive but log file 0 bytes** — no mechanism detected the silence.
+
+None of these were caught by the formatting rules alone. Mandatory events close that gap.
+
+### Catalog (9 canonical events)
+
+| id | when | level | Core required fields (`must_log`) | `must_NOT_log` |
+|----|------|-------|-----------------------------------|----------------|
+| `application_startup` | After process boot, **before** accepting requests | INFO | app_name, version, git_sha, environment, hostname, pid, listening_endpoints | secrets, full connection strings |
+| `request_received` | First time HTTP middleware sees a request | INFO / DEBUG | method, path, source_ip, request_id | request body, auth headers |
+| `validation_failure` | schema / ModelState / DTO validation rejects | WARN | request_id, path, missing_fields[], payload_shape (keys only) | field **values**, PII |
+| `authentication_failure` | login / token verification fails | WARN | uid (attempted), source_ip, failure_reason | password, token value |
+| `outbound_call_start` | An outbound HTTP/RPC call is initiated | INFO | target_url (host+path), request_id propagated, timeout_ms | credentials, bearer tokens |
+| `outbound_call_complete` | An external call returns or fails | INFO / WARN / ERROR | status_code **or** failure_phase (dns/tcp/tls/http), elapsed_ms, retries | response body with PII |
+| `business_event` | A state-changing business operation completes | INFO | operation_name, actor, target ids, outcome | full record payload, PII |
+| `heartbeat` | Long-running background service, ≥ 1× / 60 s | INFO | service_name, queue_depth, items_processed_since_last_heartbeat | — |
+| `shutdown` | Process exits (graceful or fatal) | INFO / ERROR | app_name, signal/reason, uptime_seconds, pending_work_count | — |
+
+Each event's `rationale` ties back to a real failure mode: `validation_failure` ⇒ incident #2 (un-logged payload); `authentication_failure` field requirements ⇒ incident #3 (no uid/IP); `heartbeat` + silence detection ⇒ incident #4 (0-byte log); `application_startup`/`shutdown` ⇒ lifecycle blind spots; `outbound_call_*` ⇒ "send failed" with no trace of the call.
+
+### Scenarios
+
+#### Scenario: Validation failure must produce a log
+
+- **GIVEN** an API endpoint receives a payload missing a `[Required]` field
+- **WHEN** the framework auto-rejects (e.g. 400/501) before the handler runs
+- **THEN** a WARN log MUST be written with `request_id`, `path`, `missing_fields[]`, `payload_shape` (keys only)
+- **AND** a post-mortem can reconstruct the failure cause directly from the log
+
+#### Scenario: Background service must heartbeat
+
+- **GIVEN** a worker process is running
+- **WHEN** no INFO/WARN/ERROR is written within 60 s
+- **THEN** a `heartbeat` log MUST be written with current queue depth and items processed
+- **AND** if no heartbeat appears for ≥ 2× the interval (≥ 120 s), the silence detector MUST alert
+
+### Compliant startup log example
+
+```json
+{
+  "timestamp": "2026-06-17T08:00:00.000Z",
+  "level": "INFO",
+  "message": "application_startup",
+  "event": "application_startup",
+  "app_name": "payment-service",
+  "version": "2.3.1",
+  "git_sha": "a1b2c3d",
+  "environment": "production",
+  "hostname": "pod-abc123",
+  "pid": 4711,
+  "listening_endpoints": ["0.0.0.0:8080", "0.0.0.0:9090/metrics"]
+}
+```
+
+### Follow-on rules
+
+1. **Access-log separation** — health-probe / liveness traffic MUST NOT pollute the business-event log. Route probes to a separate sink/file so they cannot drown out or rotate away business events (see incident #1).
+2. **Log-silence detection SLA** — a service SHOULD alert after N minutes with no events, with N ≤ 2× the `heartbeat` interval. Absence of expected logs is itself an alertable condition (see the "Absence of Expected Logs" alert pattern below).
+3. **OPS-facing log discoverability** — error responses returned to the client SHOULD carry the `request_id`, so support can correlate a user-reported failure to backend logs without round-trips for log access.
+
+> **Cross-ref**: `heartbeat` / silence detection complement the [Log File Rotation Policy](#log-file-rotation-policy) (a 0-byte / silently-dropping log is the same blind spot from two directions) and migration-assistant's Background Job / Side-Effect Completeness (these events are the observable "has-fired" evidence).
+
 ## Log Levels
 
 ### Standard Log Levels
@@ -754,6 +829,7 @@ App cannot continue?         → FATAL
 
 | Version | Date | Changes |
 |---------|------|---------|
+| 1.4.0 | 2026-06-17 | Added: Mandatory Events catalog — 9 canonical "when you MUST log" events (when/must_log/must_NOT_log/level/rationale), validation-failure + heartbeat scenarios, compliant startup example, follow-on rules (access-log separation, silence-detection SLA, request_id discoverability) (XSPEC-234 / closes issue #108) |
 | 1.3.0 | 2026-05-26 | Added: Log File Rotation Policy — mandatory dual-trigger (time + size) rotation with hostile-default warning, recipes for .NET/Python/Java/Node, ops SOP (XSPEC-232 / closes issue #111) |
 | 1.2.0 | 2026-01-24 | Added: OpenTelemetry Semantic Conventions, Observability Three Pillars Integration, Log-based Alerting, Advanced Correlation Patterns |
 | 1.1.0 | 2026-01-05 | Added: References section with OWASP, RFC 5424, OpenTelemetry, and 12 Factor App |

package/bundled/core/mock-boundary.md

@@ -1,7 +1,7 @@
 # Mock Boundary Standards
 
-**Version**: 1.0.0
-**Last Updated**: 2026-05-04
+**Version**: 1.1.0
+**Last Updated**: 2026-07-01
 **Applicability**: All software projects with unit and integration tests
 **Scope**: universal
 **Industry Standards**: ISTQB Foundation (Test Doubles), xUnit Patterns (Gerard Meszaros)
@@ -46,6 +46,7 @@ vi.mock('node:fs/promises', ...)                  // I/O replaced
 | Environment variables | `process.env.NODE_ENV`, `process.env.LICENSE_KEY` | Enables config variation |
 | File system (unit tests only) | `fs.readFile`, `fs.writeFile` | Avoids I/O in fast unit tests |
 | Cross-module boundaries (with IT counterpart) | Other modules' public APIs | Isolates unit under test |
+| In-process background execution (via injectable runner) | `Task.Run`, unawaited promises, `setTimeout`, goroutines, thread-pool dispatch | Injecting a runner seam lets tests await deterministic completion, eliminating the race |
 
 ---
 
@@ -60,6 +61,46 @@ vi.mock('node:fs/promises', ...)                  // I/O replaced
 
 ---
 
+## Injectable Background Execution
+
+Fire-and-forget background work (a `Task.Run`, an unawaited promise, a `setTimeout`, a goroutine, a `java.util.concurrent` executor submission, or `asyncio.create_task`) is a **seam**, exactly like the system clock. Just as you inject a clock instead of reading wall-clock time, you inject the background dispatcher instead of spawning work directly. This lets a test drive the work to a **deterministic, awaited completion** and assert on its outcome (success, exception, or retry) — no polling, no sleeping, no race.
+
+Abstract the dispatch behind a small interface (e.g. `IBackgroundTaskRunner` / `BackgroundDispatcher`), then provide two implementations:
+
+- **Production**: preserves true fire-and-forget semantics — dispatch returns immediately and the work runs detached.
+- **Test**: runs the work **inline** and **tracks the underlying Task/promise**, exposing a handle the test can `await` so completion (and any failure) is observable.
+
+Language-neutral sketch (TypeScript pseudo-code):
+
+```typescript
+// Seam — injected wherever background work is dispatched
+interface BackgroundDispatcher {
+  dispatch(work: () => Promise<void>): void
+}
+
+// Production: real fire-and-forget — returns immediately, work runs detached
+class FireAndForgetDispatcher implements BackgroundDispatcher {
+  dispatch(work: () => Promise<void>): void {
+    void work() // intentionally not awaited
+  }
+}
+
+// Test: inline execution + tracked tasks so tests can await completion
+class DeterministicDispatcher implements BackgroundDispatcher {
+  private readonly tasks: Promise<void>[] = []
+  dispatch(work: () => Promise<void>): void {
+    this.tasks.push(work()) // start inline, keep the handle
+  }
+  async settle(): Promise<void> {
+    await Promise.all(this.tasks) // test awaits deterministic completion
+  }
+}
+```
+
+The test injects `DeterministicDispatcher`, exercises the code under test, then `await dispatcher.settle()` before asserting on the result — the background side effect is now fully observable and deterministic.
+
+---
+
 ## Hollow Test Detection
 
 Before submitting a test file, check:
@@ -78,6 +119,7 @@ Before submitting a test file, check:
 - **Orphan Mock**: Cross-module mock with no integration test counterpart
 - **Security Bypass Mock**: Auth/permission logic replaced with pass-through stub
 - **Database Mock Cascade**: DB returns hardcoded data, hiding real query errors
+- **Poll/Sleep for Background Result**: Sleeping or polling to wait for fire-and-forget work to finish. The race is still there — the timeout merely hides it most of the time while slowing the whole suite and, on a shared runner, leaking flakiness into other MRs' CI. Inject a deterministic runner and await the tracked task instead.
 
 ---
 
@@ -90,6 +132,7 @@ Before submitting a test file, check:
 | IT counterpart | Mocking cross-module boundary | Ensure corresponding IT exists |
 | No security mock | Test involves auth/permissions | Use real test user + real token |
 | Hollow review | Mock count ≥ import count | Add output-value assertion |
+| No poll/sleep for background work | Test asserts a fire-and-forget side effect | Inject deterministic runner; await the tracked task |
 
 ---
 
@@ -98,3 +141,12 @@ Before submitting a test file, check:
 - **testing**: Mock boundary rules apply to all test levels in the testing pyramid
 - **test-completeness-dimensions**: Dimension 8 (AI Test Quality) references these rules
 - **flow-based-testing**: Flow tests must follow mock boundary rules
+
+---
+
+## Version History
+
+| Version | Date | Change |
+|---------|------|--------|
+| 1.0.0 | 2026-05-04 | Initial standard: hollow test problem, CAN/CANNOT mock tables, detection, anti-patterns, rules summary |
+| 1.1.0 | 2026-07-01 | Added injectable background execution as a seam (parallel to clock injection): CAN-mock row, `Injectable Background Execution` section, `Poll/Sleep for Background Result` anti-pattern, and no-poll/sleep rule (issue #143) |

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 |