universal-dev-standards 5.17.0 → 6.0.0

package/bundled/core/runbook.md

@@ -0,0 +1,113 @@
+# Runbook Writing Standards
+
+> **Version**: 1.0.0 | **Status**: Active | **Updated**: 2026-06-17
+> **AI-optimized version**: `ai/standards/runbook.ai.yaml`
+> **Spec**: XSPEC-063 (cross-project/specs/XSPEC-063-uds-sre-standards-pack.md)
+
+**Scope**: universal
+
+## Overview
+
+This standard defines how operational **runbooks** are written, organized,
+maintained, and tested. It covers required sections, writing principles
+(reproducible, unambiguous steps), directory structure, review cadence, and drill
+frequency. A well-written runbook reduces Mean Time To Repair (MTTR) by ensuring
+any on-call engineer can execute recovery steps without requiring tribal
+knowledge.
+
+It is part of the **SRE/operations pack** (XSPEC-063) and is the executable
+recovery member alongside `incident-response` (runbooks are executed during the
+mitigate phase) and `slo-sli` (the error-budget policy is linked from the
+runbook). It complements the existing `runbook-standards` Skill anchor; the
+unique UDS contribution is an AI-executable runbook schema that a VibeOps
+Governance Agent (DEC-042) can run directly.
+
+> **Scope.** This standard defines *what a runbook must contain and how it is
+> organized, reviewed, and drilled*. The runbook hosting tool (wiki, Git repo,
+> PagerDuty) and the automation engine are adoption choices, not part of this
+> standard.
+
+## Requirements
+
+| ID | Rule | Level |
+|----|------|-------|
+| REQ-001 | Required runbook sections (overview → post-actions) | MUST |
+| REQ-002 | Reproducible and unambiguous steps (copy-pasteable + verification) | MUST |
+| REQ-003 | Runbook naming and directory organization (typed dirs, kebab-case) | MUST |
+| REQ-004 | Review and drill cadence (by type) | MUST |
+| REQ-005 | Rollback and fallback steps (labeled, before escalation) | MUST |
+| REQ-006 | Alert integration metadata (alert name, dashboard, query) | SHOULD |
+
+### REQ-001 — Required Runbook Sections
+
+Every runbook MUST include the following sections in order: (1) **Overview** —
+alert name, severity, affected services, owner, last updated, last drilled date;
+(2) **Symptoms** — observable indicators; (3) **Impact Assessment** — user-facing
+effect and blast radius; (4) **Diagnostic Steps** — ordered steps with
+copy-pasteable commands; (5) **Fix Steps** — ordered remediation with verification
+for each step; (6) **Escalation** — specific contacts with role and availability;
+(7) **Post-Actions** — follow-up tasks, tickets, postmortem triggers.
+
+### REQ-002 — Reproducible and Unambiguous Steps
+
+Each step in a runbook MUST be reproducible and unambiguous. Steps MUST use
+copy-pasteable commands with no placeholders left undefined. Decision points MUST
+include explicit branch conditions (if X then Y, else Z). Every fix step MUST
+include a verification command confirming the fix worked before proceeding, and
+the expected output MUST be shown.
+
+### REQ-003 — Runbook Naming and Directory Organization
+
+Runbooks MUST use kebab-case names that describe the problem, not the solution.
+Files MUST be organized into typed directories: `alerts/` for alert-response
+runbooks, `operations/` for standard ops, `emergency/` for major incident
+procedures, and `troubleshooting/` for general investigation guides. Each runbook
+file MUST declare its type in the front matter.
+
+### REQ-004 — Review and Drill Cadence
+
+Runbooks MUST be reviewed on schedule based on type: alert-response runbooks
+quarterly, emergency procedures monthly, standard operation and troubleshooting
+guides bi-annually, and change procedures after each use. Runbooks MUST be
+drilled: P1 runbooks monthly, P2 quarterly, emergency procedures quarterly. Drill
+records MUST be appended to the runbook or linked from it.
+
+### REQ-005 — Rollback and Fallback Steps
+
+Any runbook describing a change or fix MUST include a clearly labeled rollback
+section describing how to undo the change if the fix fails or causes additional
+issues. The rollback section MUST appear before the escalation section and include
+its own verification steps.
+
+### REQ-006 — Alert Integration Metadata
+
+Alert-response runbooks SHOULD include a metadata block linking the runbook to
+specific alert rules. This enables automatic runbook linking in alerting tools
+(PagerDuty, Alertmanager). Metadata MUST include the alert name, dashboard URL,
+and the Prometheus/logging query used to investigate.
+
+## Integration with Existing Standards
+
+- **`runbook-standards`** — the existing Skill-anchor standard; `runbook` provides
+  the AI-executable schema and the section/drill requirements behind it.
+- **`incident-response`** — runbooks are executed during the incident mitigate
+  phase; SEV runbooks are drilled per the cadence here.
+- **`slo-sli`** — the error-budget policy MUST be linked from the service runbook.
+- **`rollback-standards`** — REQ-005 rollback steps align with the rollback
+  standard's undo procedures.
+- **`alerting-standards`** — REQ-006 metadata links alert rules to their runbook.
+- **`execution-history`** — when a runbook is marked `automation_level: automated`,
+  the Governance Agent's execution results are recorded as execution history.
+
+## Related Specs
+
+- XSPEC-063 — UDS SRE/operations pack (this standard's source)
+- XSPEC-251 — Operator proactive reliability (runbook ownership)
+- DEC-042 — Guardian / Governance Agent pattern (agent executes `automated` runbooks)
+- DEC-041 — EU AI Act 2026 compliance (auditable recovery procedures)
+
+## Changelog
+
+| Version | Date | Changes |
+|---------|------|---------|
+| v1.0.0 | 2026-06-17 | Initial — REQ-001~006: required sections, reproducible steps, naming/organization, review/drill cadence, rollback/fallback, alert integration metadata (XSPEC-063) |

package/bundled/core/schema-evolution.md

@@ -0,0 +1,105 @@
+# Schema Evolution Standards
+
+> **Version**: 1.0.0 | **Status**: Active | **Updated**: 2026-06-17
+> **AI-optimized version**: `ai/standards/schema-evolution.ai.yaml`
+> **Spec**: XSPEC-068 (cross-project/specs/XSPEC-068-uds-data-engineering-pack.md)
+
+**Scope**: universal
+
+## Overview
+
+This standard defines how database and data-store schemas are **evolved safely**
+without breaking existing consumers. It covers backward-compatible change patterns,
+prohibited breaking changes, the expand-contract migration strategy, schema
+versioning and registry, automated compatibility checking in CI, and rollback
+procedures. It applies to relational databases, document stores, event schemas
+(Avro/Protobuf), and API request/response schemas.
+
+It is part of the **data-engineering pack** (XSPEC-068) and extends the
+static-schema definitions in `database-standards` with safe evolution rules.
+
+> **Scope.** This standard defines the *compatibility taxonomy*, the
+> *expand-contract* deployment discipline, and CI gating. The concrete migration
+> tool (Flyway/Liquibase) and schema registry (Confluent) are adoption choices.
+
+## Requirements
+
+| ID | Rule | Level |
+|----|------|-------|
+| REQ-001 | Backward-compatible change patterns | MUST |
+| REQ-002 | Prohibited breaking changes without a migration plan | MUST |
+| REQ-003 | Expand-contract migration strategy | MUST |
+| REQ-004 | Schema versioning and registry | MUST |
+| REQ-005 | Automated schema-compatibility checking in CI | MUST |
+| REQ-006 | Schema-change rollback procedures | MUST |
+
+### REQ-001 — Backward-Compatible Change Patterns
+
+All schema changes MUST be backward-compatible unless a formal breaking-change
+process is followed. Backward-compatible changes include: adding new nullable
+columns/fields with defaults, adding new tables/collections, adding new optional
+message fields, adding new enum values (with unknown handling), widening a data
+type (INT → BIGINT), and adding indexes. These changes MUST be deployable without
+coordinating consumer updates.
+
+### REQ-002 — Prohibited Breaking Changes Without Migration Plan
+
+The following are classified as **BREAKING** and MUST NOT be deployed without a
+formal expand-contract migration plan and consumer coordination: renaming or
+dropping columns/fields, changing data types incompatibly, adding NOT NULL to
+existing columns without defaults, changing primary/foreign-key definitions,
+removing enum values, and changing field semantics (repurposing a column).
+
+### REQ-003 — Expand-Contract Migration Strategy
+
+Breaking changes MUST use the **expand-contract** (parallel-change) pattern:
+**Phase 1 (Expand)** add new structure alongside old; **Phase 2 (Migrate)**
+backfill old → new and update all writers; **Phase 3 (Contract)** update all
+readers to the new structure; **Phase 4 (Cleanup)** remove old structure after all
+consumers are updated. Each phase MUST be a separate, verified deployment.
+Minimum wait between phases: one full deployment cycle.
+
+### REQ-004 — Schema Versioning and Registry
+
+Event-driven and API schemas (Avro, Protobuf, JSON Schema) MUST be registered in a
+schema registry with explicit version numbers following semantic versioning: PATCH
+for backward-compatible additions, MINOR for new optional fields, MAJOR for
+breaking changes. Every schema change MUST be reviewed and approved before
+registration. Consumers MUST specify the schema version they consume.
+
+### REQ-005 — Automated Schema Compatibility Checking in CI
+
+Every PR modifying schema definitions MUST trigger automated compatibility checks
+in CI. For relational schemas, migration scripts MUST be run against a
+production-snapshot database in CI to detect errors before merge. For event
+schemas, compatibility MUST be checked against all registered consumer versions.
+Compatibility failures MUST block the PR merge.
+
+### REQ-006 — Schema Change Rollback Procedures
+
+Every migration script MUST have a corresponding rollback (down) script. Rollback
+scripts MUST be tested in CI alongside the forward migration. For destructive
+changes (drops, type changes), a data backup MUST be taken and verified before
+execution. The rollback plan MUST be documented in the migration PR and referenced
+in the deployment runbook.
+
+## Integration with Existing Standards
+
+- **`database-standards`** — this standard adds the *evolution* discipline on top
+  of static schema definitions.
+- **`data-contract`** — MAJOR schema versions map to contract breaking-change
+  governance and consumer sign-off.
+- **`data-pipeline`** — pipelines must tolerate backward-compatible source changes
+  per REQ-001.
+- **`deployment-standards`** — expand-contract phases are separate deployments;
+  rollback plans live in the deployment runbook.
+
+## Related Specs
+
+- XSPEC-068 — UDS data-engineering pack (this standard's source)
+
+## Changelog
+
+| Version | Date | Changes |
+|---------|------|---------|
+| v1.0.0 | 2026-06-17 | Initial — REQ-001~006: backward-compatible patterns, prohibited breaking changes, expand-contract, versioning/registry, CI compatibility checks, rollback (XSPEC-068) |

package/bundled/core/secret-management-standards.md

@@ -0,0 +1,110 @@
+# Secret Management and Credential Hygiene Standards
+
+> **Version**: 1.0.0 | **Status**: Active | **Updated**: 2026-06-17
+> **AI-optimized version**: `ai/standards/secret-management-standards.ai.yaml`
+> **Spec**: XSPEC-065 (cross-project/specs/XSPEC-065-uds-infrastructure-pack.md)
+
+**Scope**: universal
+
+## Overview
+
+This standard defines how teams store, inject, rotate, and audit secrets and
+credentials across development and production environments. It covers three
+approved secret source tiers (Vault dynamic secrets, Cloud KMS, SOPS+Git),
+rotation policies by credential type, automated hardcoded-secret prevention via
+pre-commit and CI scanning, and safe secret injection patterns. It is designed to
+eliminate credentials from source code and CI logs while remaining operationally
+practical across team sizes.
+
+It is part of the **IaC pack** (XSPEC-065) and serves as the cross-cutting
+*primary owner* for secret handling: it is referenced by container image builds
+(`container-image-standards`), compliance auditing (`audit-trail`), and SRE
+runbooks that store credentials.
+
+> **Scope.** This standard defines the *approved sources*, *rotation cadence*,
+> *prevention layers*, and *injection patterns* for secrets. The choice between
+> Vault / Cloud KMS / SOPS and the specific scanning tool are adoption choices.
+
+## Requirements
+
+| ID | Rule | Level |
+|----|------|-------|
+| REQ-001 | Secret source three options (Vault / Cloud KMS / SOPS+Git) | MUST |
+| REQ-002 | Rotation policy by type | MUST |
+| REQ-003 | Hardcoded secret prevention (pre-commit + CI scan) | MUST |
+| REQ-004 | Secret injection (env vars or mounted files only) | MUST |
+
+### REQ-001 — Secret Source Three Options
+
+Teams MUST use one of three approved secret source tiers based on operational
+context: (1) **HashiCorp Vault dynamic secrets** (preferred for production and
+multi-team environments) — secrets generated on-demand with short TTLs, no static
+credentials stored anywhere; (2) **Cloud KMS with native secret managers** (AWS
+Secrets Manager / GCP Secret Manager / Azure Key Vault) — suitable for
+cloud-native deployments, secrets fetched at runtime via IAM-controlled API
+calls; (3) **SOPS + Git encryption** — suitable for small teams and GitOps
+workflows, secrets encrypted with `age` or a KMS key before committing and
+decrypted only in trusted runtime environments. Storing unencrypted secrets in
+any other location (env files, wiki, chat) is **PROHIBITED**.
+
+### REQ-002 — Rotation Policy by Type
+
+All secrets MUST have a defined rotation policy enforced by automated tooling or
+calendar reminders. Minimum rotation frequencies by type: **Database
+credentials** — every 90 days; **API keys** (third-party services) — every 180
+days; **Signing keys** (JWT, code signing) — every 365 days; **One-time tokens
+and session credentials** — revoke immediately after use, MUST NOT be reused;
+**TLS certificates** — rotate at least 30 days before expiry, automate with
+ACME/Let's Encrypt or cert-manager where possible. Rotation events MUST be logged
+in the audit trail.
+
+### REQ-003 — Hardcoded Secret Prevention
+
+Teams MUST implement automated scanning to detect and block hardcoded secrets
+before they reach the repository. Two layers are REQUIRED: (1) **Pre-commit hook**
+using `detect-secrets`, `gitleaks`, or `truffleHog` — scans staged files and
+blocks the commit if patterns are detected; (2) **CI pipeline scan** — rescans
+all changed files on every PR and blocks merge if secrets are found. Minimum
+detected patterns: AWS access key format (`AKIA[0-9A-Z]{16}`), PEM private key
+headers (`-----BEGIN .* PRIVATE KEY`), generic API token patterns
+(`api[_-]?key\s*[:=]\s*\S{16,}`), and connection strings containing passwords.
+
+### REQ-004 — Secret Injection
+
+Secrets MUST be injected into application processes via environment variables or
+mounted files only. Passing secrets via command-line arguments is **PROHIBITED**
+(visible in process lists). Passing secrets via URL query parameters is
+**PROHIBITED** (logged by proxies and servers). For environment variable
+injection, use the platform's native secret injection (Kubernetes Secrets, ECS
+task definition secrets, GitHub Actions secrets). For file-based injection, mount
+secrets as read-only volumes with restrictive file permissions (0400 or 0600).
+
+## Anti-Patterns
+
+- Hardcoding credentials directly in source code or configuration files.
+- Storing secrets in CI/CD environment variables without encryption (plaintext in UI).
+- Sharing credentials across multiple environments (dev/staging/prod use same secret).
+- Long-lived static credentials without rotation schedules.
+- Committing `.env` files containing real secrets to version control.
+
+## Integration with Existing Standards
+
+- **`iac-design-principles`** — secret backends (Vault/KMS state) are themselves
+  versioned, access-controlled infrastructure.
+- **`audit-trail`** — rotation, access, and injection events are auditable
+  operations (REQ-002 mandates logging rotation events).
+- **`pii-classification`** — credentials guarding TIER-1 PII inherit the strictest
+  handling controls.
+- **`security-standards`** — this standard is the credential-hygiene facet of the
+  broader security baseline.
+
+## Related Specs
+
+- XSPEC-065 — UDS infrastructure (IaC) pack (this standard's source)
+- DEC-043 — UDS coverage completeness roadmap (Wave 4 scope; D1 cross-cutting owner)
+
+## Changelog
+
+| Version | Date | Changes |
+|---------|------|---------|
+| v1.0.0 | 2026-06-17 | Initial — REQ-001~004: secret source options, rotation policy, hardcoded-secret prevention, secret injection (XSPEC-065) |

package/bundled/core/security-testing.md

@@ -1,7 +1,7 @@
 # Security Testing Standards
 
-**Version**: 1.0.0
-**Last Updated**: 2026-05-04
+**Version**: 1.1.0
+**Last Updated**: 2026-06-19
 **Applicability**: All software projects
 **Scope**: universal
 **Industry Standards**: OWASP Testing Guide v4, NIST SP 800-115, ISO/IEC 27001
@@ -71,6 +71,30 @@ Tools: OWASP ZAP, Nuclei
 
 ---
 
+## Finding Remediation Lifecycle
+
+The layers above detect findings and the CVE policy sets resolution SLAs, but a
+finding also needs an **owned lifecycle** — otherwise "block merge" is the only
+defined action and everything after detection is undefined. Every security
+finding (SAST / DAST / secret / dependency CVE) follows this state machine.
+
+| State | Meaning | Owner | Exit condition |
+|-------|---------|-------|----------------|
+| **Detected** | A layer (SAST/DAST/secret/audit) raised it | the scanning gate (CI) | severity assigned |
+| **Triaged** | Severity + validity confirmed (real vs false positive) | security reviewer | real → In-Progress; false-positive → `suppressed` with recorded justification |
+| **In-Progress** | Fix being implemented | code owner of the affected component | a fix is committed |
+| **Resolved** | Fix merged | code owner | the originating scan re-runs clean |
+| **Verified** | Re-scan confirms the finding is gone | the scanning gate (CI) | finding closed |
+
+- **Gate**: a Critical/High finding in any state other than `Verified` (or
+  `Triaged → suppressed` with justification) **blocks release**, consistent with
+  the CVE Response Policy SLAs above.
+- **No silent close**: a finding may only leave the lifecycle via `Verified`
+  (re-scan clean) or an explicit, recorded `suppressed` decision by the security
+  reviewer — never by deletion, nor by the fix author self-approving.
+
+---
+
 ## Anti-Patterns
 
 - Treating all CVEs as equal urgency

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

@@ -16,7 +16,7 @@
 This standard mandates a **self-review pass** on large markdown edits before commit, to catch internal cross-reference inconsistencies that internal reasoning routinely misses.
 
 **Relationship to Other Standards**:
-- Complements [code-review.md](code-review.md) which covers code changes
+- Complements [code-review.md](code-review-checklist.md) which covers code changes
 - Complements [documentation-writing-standards.md](documentation-writing-standards.md) which covers content creation
 - This standard focuses on **post-edit verification** of large markdown documents (DECs, ADRs, XSPECs, SKILL.md, spec documents, runbooks)
 
@@ -119,7 +119,7 @@ Self-review (protocol v1.0.0): N issues found, M applied in same commit / 0 foun
 
 | Practice | Covers | Trigger |
 |---|---|---|
-| **Code Review** ([code-review.md](code-review.md)) | Code correctness, design, security | Before merging code PR |
+| **Code Review** ([code-review.md](code-review-checklist.md)) | Code correctness, design, security | Before merging code PR |
 | **Content Self-Audit** (e.g., eval-source skill's 7-question audit) | Content completeness (did we include all required sections?) | Each artefact creation |
 | **Self-Review Protocol** (this standard) | Internal cross-reference consistency (form, not content) | After large markdown edit, before commit |
 | **Peer Review** | Independent perspective, blast radius assessment | Significant changes |

package/bundled/core/skill-standard-alignment-check.md

@@ -1,6 +1,9 @@
 # Skill-Standard Alignment Check
 
 > **Source**: XSPEC-070 | **Driven by**: DEC-043 Wave 1 Governance Meta Pack | **Status**: Trial (2026-04-17 ~ 2026-10-17)
+>
+> **Phase 1**（anchor 存在性 / orphan 偵測）— Implemented。
+> **Phase 2**（content-coverage audit：版本偏移 / mandatory keyword / 規模落差）— Implemented（XSPEC-292 T4，`scripts/check-skill-content-coverage.ts`）。
 
 ## Overview
 
@@ -57,6 +60,45 @@ Skill 必有 Standard 作為錨點，Standard 可無 Skill；定期識別孤兒
 5. 驗證 anchor 指向存在且非 Archived 的 id
 6. 產出 `alignment-report.json` / `alignment-report.md`
 
+## Content-Coverage Audit（Phase 2）
+
+> **Driven by**: XSPEC-292 T4（3 個真實 skill↔standard 內容漂移）。Phase 1 只證明 anchor
+> *存在*（防 orphan）；一個 Skill 可帶著有效 `anchor_standard` 仍漂移——標準新增 mandatory
+> 段落、bump 版本、或成長到遠超 Skill 的陳舊摘要。Phase 2 把對齊從「錨點存在」延伸到
+> 「錨點內容同步」。
+
+每個 `(skill, anchor_standard)` 配對執行三項內容層檢查（預設 advisory，`--strict` 轉硬閘）：
+
+| 檢查 | 錯誤碼 | 觸發條件 |
+|------|--------|----------|
+| **版本偏移** | `CONTENT-001` | Skill `**Version**` < anchor 標準版本（取自 `core/<id>.md`）。Skill 無版本則記 `CONTENT-001A`（advisory，永不阻擋）。 |
+| **mandatory keyword 覆蓋** | `CONTENT-002` | 標準在 `.ai.yaml` 宣告為 mandatory 的關鍵字（`audit.mandatory_keywords`）未出現在 Skill 內文。 |
+| **規模落差** | `CONTENT-003` | Skill 行數 / 標準行數 < `audit.min_skill_ratio`（預設 0.15），即 underspecified 骨架。 |
+
+### Audit 宣告（標準側 opt-in）
+
+mandatory keyword 與規模門檻由**標準自己**在其 `.ai.yaml` 宣告（反幻覺：審核器不臆測什麼是
+mandatory，只讀標準作者明文宣告的清單）。支援兩種 schema 位置：頂層 `audit:` 或 `standard.audit:`。
+
+```yaml
+# ai/standards/logging.ai.yaml
+audit:
+  mandatory_keywords:    # logging 的 9 canonical events
+    - application_startup
+    - request_received
+    # ...
+  min_skill_ratio: 0.15  # 選填，覆寫預設
+```
+
+### Advisory → Strict 升級路徑
+
+- 預設 **advisory**：列出所有 finding，exit 0，讓 audit 能在所有漂移修完前先落地。
+- `--strict`：將 `CONTENT-001/002/003` 升為阻擋失敗（exit 1）；`CONTENT-001A`（無版本）始終
+  資訊性、永不阻擋。
+- 建議：先以 advisory 進 CI 觀察 → 漂移清零後於 pre-release gate 加 `--strict`。
+
+腳本：`scripts/check-skill-content-coverage.ts`（npm script `check:content-coverage`）。
+
 ## Usage Examples
 
 - **Scenario 1 — 健康對齊**：`retry-assistant` frontmatter 含 `anchor_standard: retry-standards`，指向 Trial 狀態標準 → 檢查通過
@@ -65,14 +107,25 @@ Skill 必有 Standard 作為錨點，Standard 可無 Skill；定期識別孤兒
 
 ## Error Codes
 
+Phase 1（anchor 存在性）：
+
 - `ALIGN-001` — `SKILL_MISSING_ANCHOR`
 - `ALIGN-002` — `BROKEN_ANCHOR`（指向不存在的 standard id）
 - `ALIGN-003` — `ARCHIVED_ANCHOR`（指向已 Archived 的標準）
 - `ALIGN-004` — `UTILITY_MISSING_REASON`
 
+Phase 2（內容覆蓋）：
+
+- `CONTENT-001` — `VERSION_SKEW`（Skill 版本 < anchor 標準版本，stale；blocking under `--strict`）
+- `CONTENT-001A` — `SKILL_UNVERSIONED`（Skill 無版本，無法比對；advisory only）
+- `CONTENT-002` — `MISSING_MANDATORY_KEYWORD`（標準宣告的 mandatory keyword 未出現於 Skill）
+- `CONTENT-003` — `UNDERSPECIFIED`（Skill 規模遠小於 anchor 標準）
+- `CONTENT-000` — `ANCHOR_NOT_IN_REGISTRY`（內容覆蓋無法評估；broken anchor 屬 ALIGN-002 領域）
+
 ## References
 
 - AI-optimized: [ai/standards/skill-standard-alignment-check.ai.yaml](../ai/standards/skill-standard-alignment-check.ai.yaml)
+- Phase 2 audit 腳本: `scripts/check-skill-content-coverage.ts`（npm `check:content-coverage`）
 - XSPEC-070: DEC-043 Wave 1 Governance Meta Pack 跨專案規格
 - DEC-043: UDS 覆蓋完整性路線圖（XSPEC-063~069 目的之一即清空本標準識別的 orphan 清單）
 - Related: `standard-admission-criteria`, `standard-lifecycle-management`

package/bundled/core/slo-sli.md

@@ -0,0 +1,109 @@
+# SLO/SLI Definition Standards
+
+> **Version**: 1.0.0 | **Status**: Active | **Updated**: 2026-06-17
+> **AI-optimized version**: `ai/standards/slo-sli.ai.yaml`
+> **Spec**: XSPEC-063 (cross-project/specs/XSPEC-063-uds-sre-standards-pack.md)
+
+**Scope**: universal
+
+## Overview
+
+This standard defines how teams **select, measure, and govern Service Level
+Indicators (SLIs) and Service Level Objectives (SLOs)**. It covers SLI selection
+per service type, SLO target-setting methodology, error-budget policies, and
+multi-window burn-rate alerting. It is designed to bridge engineering reliability
+work with customer-facing SLA commitments.
+
+It is part of the **SRE/operations pack** (XSPEC-063) and is the
+reliability-target member alongside `incident-response` (error-budget burn often
+triggers incidents) and `runbook` (the error-budget policy is linked from the
+service runbook). It complements the existing `slo-standards` Skill anchor and
+feeds the proactive reliability ownership described in XSPEC-251 (Operator).
+
+> **Scope.** This standard defines *how to choose SLIs, set SLO targets, and
+> govern error budgets*. The metrics backend (Prometheus, Datadog), the dashboard
+> product, and the alerting tool are adoption choices, not part of this standard.
+
+## Requirements
+
+| ID | Rule | Level |
+|----|------|-------|
+| REQ-001 | SLI selection per service type (API / batch / frontend) | MUST |
+| REQ-002 | SLO target-setting methodology (historical P5 baseline + buffer) | MUST |
+| REQ-003 | Error budget policy (freeze + reliability-sprint triggers) | MUST |
+| REQ-004 | Multi-window burn-rate alerting (fast / medium / slow burn) | SHOULD |
+| REQ-005 | SLO documentation and review cadence (standard spec + quarterly review) | MUST |
+| REQ-006 | SLO compliance reporting (monthly stakeholder report) | SHOULD |
+
+### REQ-001 — SLI Selection Per Service Type
+
+Every production service MUST define at least one SLI matched to its service type.
+API services MUST measure availability (non-5xx / total) and latency (proportion
+of requests below a threshold). Batch jobs MUST measure freshness (data lag ≤
+threshold) and correctness (successfully processed / total). Frontend services
+MUST measure Core Web Vitals (LCP < 2.5s, FID < 100ms, CLS < 0.1).
+
+### REQ-002 — SLO Target Setting Methodology
+
+SLO targets MUST be set using historical baseline data. Teams MUST start from the
+observed P5 performance (the 5th-percentile worst period) over at least 28 rolling
+days, then add a small buffer. The SLO target MUST be strictly higher than any
+external SLA commitment (e.g., SLA 99.9% → SLO ≥ 99.95%). Never set an SLO equal
+to the SLA; maintain a ≥ 0.05% buffer.
+
+### REQ-003 — Error Budget Policy
+
+Every service with an SLO MUST have a written Error Budget Policy specifying
+actions when the error budget is partially or fully exhausted. At minimum the
+policy MUST define: (1) a freeze threshold (typically 50% exhausted → release
+freeze), (2) a reliability-sprint trigger (100% exhausted), and (3) an SLO review
+cadence (quarterly). The error-budget computation follows
+`budget = (1 − SLO) × time window` (e.g., 99.9% over 30 days → 43.2 minutes).
+
+### REQ-004 — Multi-Window Burn-Rate Alerting
+
+Teams SHOULD implement multi-window burn-rate alerts to catch both fast and slow
+budget exhaustion. Recommended thresholds: fast burn (2% of monthly budget
+consumed in 1 hour → P1 page), medium burn (5% in 6 hours → P2 alert), slow burn
+(10% in 3 days → P3 ticket).
+
+### REQ-005 — SLO Documentation and Review Cadence
+
+Each SLO MUST be documented in a standard SLO spec file containing: service name,
+SLI formula, measurement window, target value, error budget, alerting thresholds,
+and owner. SLO specs MUST be reviewed quarterly and updated within 2 weeks of any
+major architecture change.
+
+### REQ-006 — SLO Compliance Reporting
+
+Teams SHOULD publish a monthly SLO compliance report to stakeholders. The report
+MUST include achieved vs. target SLI value, error budget remaining, significant
+incidents affecting the SLO, and planned reliability improvements. Dashboard links
+MUST be included.
+
+## Integration with Existing Standards
+
+- **`slo-standards`** — the existing Skill-anchor standard; `slo-sli` provides the
+  detailed selection/target/error-budget methodology behind it.
+- **`incident-response`** — error-budget burn-rate alerts feed incident
+  declaration and severity assessment.
+- **`runbook`** — the error-budget policy MUST be linked from the service runbook.
+- **`rollback-standards`** — error-budget exhaustion can trigger a deployment
+  freeze and, downstream, automated rollback.
+- **`observability-standards`** — SLIs are computed from the metric/log/trace
+  pillars defined there.
+- **`alerting-standards`** — burn-rate alerts follow the symptom-based alerting
+  and severity grading rules.
+
+## Related Specs
+
+- XSPEC-063 — UDS SRE/operations pack (this standard's source)
+- XSPEC-251 — Operator proactive reliability (SLO ownership upstream of incidents)
+- DEC-041 — EU AI Act 2026 compliance (reliability evidence)
+- DEC-042 — Guardian / Governance Agent pattern (error-budget-driven actions)
+
+## Changelog
+
+| Version | Date | Changes |
+|---------|------|---------|
+| v1.0.0 | 2026-06-17 | Initial — REQ-001~006: SLI selection, SLO target methodology, error-budget policy, burn-rate alerting, SLO documentation/review, compliance reporting (XSPEC-063) |

package/bundled/core/smoke-test.md

@@ -60,7 +60,7 @@ echo "=== PASS ==="
 
 ## Related Standards
 
-- [Testing Standards](testing.md) — overall test pyramid
+- [Testing Standards](testing-standards.md) — overall test pyramid
 - [Deployment Standards](deployment-standards.md) — deployment pipeline
 - [Performance Standards](performance-standards.md) — latency SLOs
 

package/bundled/core/tech-debt-standards.md

@@ -54,7 +54,7 @@ Every technical debt item must be recorded in a registry with the following 11 f
 | 1 | **ID** | Unique identifier using `TD-NNN` format | TD-001 |
 | 2 | **Title** | Short descriptive title | "Monolithic auth module needs decomposition" |
 | 3 | **Type** | One of the 6 debt types above | Design |
-| 4 | **Source** | How the debt was introduced (deliberate/inadvertent) | Deliberate |
+| 4 | **Source** | How the debt was introduced (deliberate / inadvertent / incident-postmortem — see [postmortem-standards](postmortem-standards.md) action-item hand-off) | Deliberate (or `postmortem PM-042`) |
 | 5 | **Impact** | Business and technical impact description | "Slows feature development by ~2 days per sprint" |
 | 6 | **Estimated Cost** | Effort to resolve (story points or person-days) | 8 story points |
 | 7 | **Interest** | Ongoing cost of not resolving (see Interest Types) | 1 day/sprint additional debugging |

package/bundled/core/test-data-standards.md

@@ -296,8 +296,8 @@ ID?      → Hash / UUID / sequential
 
 - [Testing Standards](testing-standards.md) — Test levels, coverage, and quality requirements
 - [Security Standards](security-standards.md) — Data protection and PII handling
-- [Unit Testing Standards](unit-testing-standards.md) — Unit test patterns and best practices
-- [Integration Testing Standards](integration-testing-standards.md) — Integration test strategies
+- [Unit Testing Standards](../options/testing/unit-testing.md) — Unit test patterns and best practices
+- [Integration Testing Standards](../options/testing/integration-testing.md) — Integration test strategies
 
 ---