universal-dev-standards 5.1.0-beta.6 → 5.1.0

package/bundled/core/model-selection.md

@@ -151,3 +151,83 @@ Escalation means using a more capable model, not repeating the same action. The
 
 - **Superpowers**: [subagent-driven-development](https://github.com/obra/superpowers) (MIT)
 - **Cost-Effective AI**: Principle of using the minimum capability needed
+
+---
+
+## LLM 能力管理（XSPEC-027）
+
+> **Version**: 2.0.0 — 本節於 2026-04-13 新增，對應 XSPEC-027 Phase 1。
+
+三層模型選擇策略處理「任務複雜度」維度；本節新增「模型能力維度」管理，用於多模型池環境。
+
+### capability_dimensions — 能力維度分類
+
+能力維度分為四大類，共 9 個子維度：
+
+| 大類 | 子維度 | 說明 | 基準測試 |
+|------|--------|------|---------|
+| modality | vision | 圖片/截圖理解（UI 分析、圖表解讀） | internal-vision-bench |
+| modality | audio | 語音理解能力 | future-audio-bench |
+| modality | image_generation | 圖片生成能力 | provider-specific |
+| reasoning | code_reasoning | 程式碼理解與生成品質 | humaneval-plus |
+| reasoning | math_reasoning | 數學推理準確率 | gsm8k |
+| reasoning | instruction_following | 複雜多步驟指令遵循率 | internal-instruction-bench |
+| reasoning | long_context_quality | 長文件中間段資訊存取 | needle-in-haystack |
+| output | structured_output | JSON/Schema 格式輸出成功率 | internal-json-bench |
+| output | tool_use | Function Calling 正確率 | internal-tool-bench |
+| language | multilingual_zh_tw | 繁體中文品質（本系統優先語言） | internal-zh-tw-bench |
+
+**評分量表（1–5）**：
+
+| 分數 | 意義 |
+|------|------|
+| 5 | 生產就緒 — 高準確率，可直接使用 |
+| 4 | 良好 — 偶有遺漏，可接受 |
+| 3 | 基本可用 — 需人工補充 |
+| 2 | 部分可用 — 僅供參考 |
+| 1 | 不可靠 — 不建議使用 |
+
+### capability_registry — 模型能力登記表
+
+各子專案依實際測試，在自己的 `capability_registry` 中維護每個模型的能力分數。
+
+**格式**：
+```yaml
+- model_id: "provider/model-name"
+  version_pinned: "版本鎖定識別（SHA、日期戳或 model_version）"
+  pin_date: "YYYY-MM-DD"
+  eol_date: "YYYY-MM-DD"  # 可選
+  capabilities:
+    "modality.vision": 4
+    "reasoning.instruction_following": 5
+    "output.structured_output": 5
+```
+
+**版本鎖定（DEC-031 D1）**：必須記錄 `version_pinned` 與 `pin_date`，避免模型靜默升級造成能力變化。
+
+### routing_rules — 路由策略決策樹
+
+根據模型能力分數，路由規則分三態：
+
+```
+任務需要 capability X
+  ├── 模型得分 ≥ min_score            → SUPPORTED  — 正常執行
+  ├── 模型得分 2–3（低於 min_score）  → DEGRADED   — 降級執行，產出標記 [DEGRADED]
+  └── 模型得分 ≤ 1 或未登記           → UNSUPPORTED — 替代流程或提示用戶
+```
+
+**降智偵測（DEC-033）額外規則**：
+
+| 規則 | 條件 | 動作 |
+|------|------|------|
+| CAP-004 | 降智偵測觸發 moderate 信號 | 啟動金絲雀測試，記錄降智警告 |
+| CAP-005 | 降智偵測觸發 critical 信號 | 自動切換備用模型，上報 P1 Issue |
+
+**選擇策略**：`pareto_weighted` — 優先選擇在所需維度得分最高、成本最低的模型。
+
+### 與三層分級的關係
+
+- **三層分級（Tier 1/2/3）** — 基於任務複雜度（How hard is the task?）
+- **能力維度（XSPEC-027）** — 基於模型能力（Can this model do it?）
+
+兩者並用：先依複雜度選擇 Tier，再依能力維度確認選中的模型支援任務所需的 capability。

package/bundled/core/packaging-standards.md

@@ -0,0 +1,216 @@
+# Packaging Standards
+
+> **Language**: English | [繁體中文](../locales/zh-TW/core/packaging-standards.md)
+
+**Version**: 1.0.0
+**Last Updated**: 2026-04-15
+**Applicability**: Projects using UDS/DevAP toolchain
+**Scope**: universal
+
+---
+
+## Purpose
+
+This standard defines a Recipe-based packaging framework that enables user projects to declare packaging targets in `.devap/packaging.yaml`. UDS provides the Recipe definitions and built-in Recipe library; DevAP executes the orchestration at pipeline time.
+
+The framework separates concerns:
+- **User project**: declares *what* to package (targets + config overrides)
+- **UDS**: defines *how* to package (Recipe structure + built-in Recipes)
+- **DevAP**: executes *when* to package (pipeline stage between Review and Deploy)
+
+---
+
+## Core Principles
+
+| Principle | Description |
+|-----------|-------------|
+| **Recipe-based** | Every packaging target references a named Recipe; no ad-hoc scripts in pipeline YAML |
+| **Declarative targets** | Projects declare targets in `.devap/packaging.yaml`; DevAP resolves and executes |
+| **Customizable** | Four customization layers allow config overrides, hook injection, custom Recipes, and escape hatches |
+| **Pipeline-integrated** | Packaging runs as a named stage between Review and Deploy in the VibeOps pipeline |
+
+---
+
+## Recipe Structure
+
+A Recipe is a YAML file that defines how to package a project. The following fields are defined:
+
+```yaml
+# Recipe: <name>.yaml
+name: <string>            # REQUIRED — unique recipe identifier (kebab-case)
+description: <string>     # OPTIONAL — human-readable description
+requires:                 # OPTIONAL — files that must exist before execution
+  - <file-path>
+steps:                    # REQUIRED — ordered list of build/package steps
+  - run: <shell-command>
+    description: <string> # OPTIONAL — human-readable step description
+config:                   # OPTIONAL — default configuration values (overridable)
+  <key>: <value>
+hooks:                    # OPTIONAL — lifecycle hooks (null = no-op)
+  preBuild: ~
+  postBuild: ~
+  prePublish: ~
+  postPublish: ~
+```
+
+### Required vs Optional Fields
+
+| Field | Required | Description |
+|-------|----------|-------------|
+| `name` | Yes | Unique recipe identifier, kebab-case |
+| `steps` | Yes | At least one step must be defined |
+| `description` | No | Human-readable description |
+| `requires` | No | Pre-condition file checks |
+| `config` | No | Default config values; all keys are overridable by user project |
+| `hooks` | No | Lifecycle hook points; `~` means no-op |
+
+### Step Variables
+
+Config values and runtime context are available as `{variable}` placeholders in `run` commands:
+
+| Variable | Source | Example |
+|----------|--------|---------|
+| `{registry}` | `config.registry` | `ghcr.io` |
+| `{name}` | `package.json#name` or `config.name` | `my-app` |
+| `{version}` | `package.json#version` or `config.version` | `1.2.3` |
+| `{platforms}` | `config.platforms` | `linux/amd64,linux/arm64` |
+| `{output_dir}` | `config.output_dir` | `dist/installers` |
+
+---
+
+## Built-in Recipes
+
+UDS ships four built-in Recipes located in the `recipes/` directory:
+
+| Recipe | File | Use Case |
+|--------|------|----------|
+| `npm-library` | `recipes/npm-library.yaml` | npm package without a binary entry point |
+| `npm-cli` | `recipes/npm-cli.yaml` | npm package with a `bin` field (CLI tool) |
+| `docker-service` | `recipes/docker-service.yaml` | Docker container image build and push |
+| `windows-installer` | `recipes/windows-installer.yaml` | Windows installer (.msi / .exe) via user script |
+
+### When to Use Each Recipe
+
+```
+Is the output an npm package?
+├── Yes → Does package.json contain a "bin" field?
+│         ├── Yes → npm-cli
+│         └── No  → npm-library
+└── No  → Is the output a container image?
+          ├── Yes → docker-service
+          └── No  → Is the output a Windows installer?
+                    ├── Yes → windows-installer
+                    └── No  → write a custom recipe (see Customization Layers)
+```
+
+---
+
+## Customization Layers
+
+Projects that need to deviate from built-in Recipe defaults should use the lowest applicable layer:
+
+| Layer | Mechanism | When to Use |
+|-------|-----------|-------------|
+| **L1 — Config Override** | `config:` block in `.devap/packaging.yaml` | Change default values (registry URL, tag, output dir) |
+| **L2 — Hook Injection** | `hooks:` block in `.devap/packaging.yaml` | Run extra commands before/after build or publish |
+| **L3 — Custom Recipe** | New `.yaml` file in project's `.devap/recipes/` | Entirely different build process; built-ins don't apply |
+| **L4 — Escape Hatch** | `script:` key replacing `recipe:` in target definition | Raw shell script when no Recipe abstraction is suitable |
+
+### L1 Example — Config Override
+
+```yaml
+# .devap/packaging.yaml
+targets:
+  - name: publish-npm
+    recipe: npm-library
+    config:
+      registry: https://npm.pkg.github.com
+      access: restricted
+      tag: beta
+```
+
+### L2 Example — Hook Injection
+
+```yaml
+# .devap/packaging.yaml
+targets:
+  - name: docker-push
+    recipe: docker-service
+    hooks:
+      postPush: |
+        curl -X POST https://hooks.example.com/deploy-notify \
+          -d "{\"version\": \"{version}\"}"
+```
+
+### L3 Example — Custom Recipe
+
+```yaml
+# .devap/recipes/electron-app.yaml
+name: electron-app
+description: Build Electron desktop application
+requires:
+  - package.json
+  - electron-builder.yml
+steps:
+  - run: npm run build
+  - run: npx electron-builder --publish never
+config:
+  output_dir: dist
+```
+
+### L4 Example — Escape Hatch
+
+```yaml
+# .devap/packaging.yaml
+targets:
+  - name: legacy-bundle
+    script: |
+      ./scripts/legacy-bundle.sh
+      mv output/ dist/bundle/
+```
+
+---
+
+## Acceptance Criteria for Packaging
+
+A packaging run is considered **successful** when ALL of the following conditions are met:
+
+| Criterion | Threshold | Notes |
+|-----------|-----------|-------|
+| All `requires` files exist | 100% | Checked before any step runs |
+| All steps exit with code 0 | 100% | Any non-zero exit fails the run |
+| `postBuild` artifact exists | Present in expected path | Verified by DevAP after build step |
+| Hook commands exit with code 0 | 100% | Hook failure propagates as step failure |
+| Published artifact is retrievable | HTTP 200 / registry query succeeds | Verified by DevAP post-publish smoke check |
+
+### Failure Handling
+
+| Failure Type | Action | Retry? |
+|--------------|--------|--------|
+| Missing `requires` file | Fail immediately, report missing path | No |
+| Step non-zero exit | Fail immediately, run `postBuild` hook if defined | Configurable (default: no) |
+| Hook non-zero exit | Fail immediately | No |
+| Publish unreachable | Retry up to 3 times with exponential backoff | Yes (3×) |
+
+---
+
+## Related Standards
+
+- [Deployment Standards](deployment-standards.md) — Deploy stage that follows packaging
+- [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
+
+---
+
+## Version History
+
+| Version | Date | Changes |
+|---------|------|---------|
+| 1.0.0 | 2026-04-15 | Initial release — XSPEC-034 Phase 1 |
+
+---
+
+## License
+
+This standard is released under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

package/bundled/core/recovery-recipe-registry.md

@@ -0,0 +1,69 @@
+# Recovery Recipe Registry Standard
+
+> **Source**: XSPEC-046 | **Borrowed from**: ultraworkers/claw-code ROADMAP Phase 3 Recovery Recipes
+> **Depends on**: failure-source-taxonomy (XSPEC-045)
+
+## Overview
+
+The Recovery Recipe Registry unifies scattered recovery logic (Fix Loop, Circuit Breaker, Guardian auto-repair, staging retry) into an externalized YAML-configurable Recipe format. Each Recipe uses `failureSource` (XSPEC-045) as the match key, selects the corresponding recovery strategy, and defines an escalation path. When no Recipe matches, the system falls back to existing behavior (backward compatible).
+
+## 6 Recovery Strategies
+
+| Strategy | Description | Best For |
+|----------|-------------|----------|
+| `fix_loop` | Inject structured error feedback and retry the task | compilation, test_failure |
+| `circuit_breaker` | Three-state circuit breaker (XSPEC-036), open after consecutive failures | tool_failure, prompt_delivery |
+| `rebase_and_retry` | Run git rebase to sync base branch, then retry | branch_divergence |
+| `model_switch` | Switch to fallback model then retry | model_degradation, prompt_delivery |
+| `degraded_mode` | Continue in degraded mode (skip quality validation, partial results) | resource_exhaustion, model_degradation |
+| `human_checkpoint` | Pause execution, wait for human intervention | policy_violation, branch_divergence |
+
+## Recipe Format
+
+```yaml
+id: RR-001                          # RR-NNN format, required
+name: "Fix Loop for Compilation"    # required
+match:
+  failure_source: compilation       # FailureSource, required
+  severity: [high, medium]          # optional, empty = match all
+strategy: fix_loop                  # RecoveryStrategy, required
+config:                             # optional, overrides strategy defaults
+  max_attempts: 3
+  budget_usd: 0.50
+escalation:                         # required
+  on_exhaust: human_checkpoint      # must not reference self
+  message: "..."                    # optional notification message
+```
+
+## Default Recipes (RR-001 ~ RR-005)
+
+| ID | Trigger | Strategy | Escalation |
+|----|---------|----------|------------|
+| RR-001 | compilation | fix_loop (3 attempts, $0.50) | human_checkpoint |
+| RR-002 | test_failure | fix_loop (3 attempts, $0.50) | human_checkpoint |
+| RR-003 | model_degradation | model_switch (2 attempts) | degraded_mode |
+| RR-004 | branch_divergence | rebase_and_retry (1 attempt) | human_checkpoint |
+| RR-005 | resource_exhaustion | degraded_mode | human_checkpoint |
+
+## Guidelines
+
+- Every Recovery Recipe must have a unique ID (RR-NNN format)
+- `match.failure_source` must be one of the 8 classes defined in failure-source-taxonomy
+- `escalation.on_exhaust` must be defined — infinite loops are forbidden (escalation must not reference self)
+- When no Recipe matches, system must fallback to existing default behavior (must not throw errors)
+- User-defined Recipes take priority over built-in Recipes (when `failureSource` matches, user config is matched first)
+- Recipe config format errors fallback to strategy defaults (do not interrupt execution)
+
+## Applicable Scenarios
+
+- DevAP Orchestrator selects recovery strategy before fix loop
+- VibeOps PipelineRunner handles `agent:error` with registry lookup
+- Custom `recovery-recipes.yaml` for project-level recipe override
+- Telemetry tracking recovery strategy effectiveness
+
+## References
+
+- AI-optimized: [ai/standards/recovery-recipe-registry.ai.yaml](../ai/standards/recovery-recipe-registry.ai.yaml)
+- XSPEC-046: Cross-project specification
+- Depends on: Failure Source Taxonomy (XSPEC-045)
+- Borrowed from: [ultraworkers/claw-code](https://github.com/ultraworkers/claw-code) ROADMAP Phase 3 Recovery Recipes

package/bundled/core/retry-standards.md

@@ -0,0 +1,62 @@
+# Retry Standards
+
+> **Source**: XSPEC-067 | **Driven by**: DEC-043 Wave 1 Reliability Pack | **Status**: Trial (2026-04-17 ~ 2026-10-17)
+
+## Overview
+
+重試策略標準 — 延伸既有 `circuit-breaker` 與 `failure-source-taxonomy`，補齊 retry 層的標準化規則。避免各元件各自實作重試造成行為不一致（無上限重試、無 jitter 導致 thundering herd）。與 `failure-source-taxonomy` 深度整合：依失敗類型決定是否重試、重試幾次、退避多久。
+
+## Key Principles
+
+- **指數退避加 full jitter**：所有重試邏輯必須使用 exponential + jitter，禁止固定間隔或無 jitter 的純指數
+- **明確重試上限**：必須有 `max_attempts`（預設 5），禁止無限重試
+- **依 failureSource 分類**：先查 `failure-source-taxonomy`，fail-fast 類別不得重試
+- **與 circuit-breaker 整合**：OPEN 狀態下 fail-fast，不消耗 `max_attempts`；`retry_exhausted` 計入 failure count
+- **重試可觀察**：每次重試上報 `retry_attempted` / `retry_exhausted` 遙測事件
+
+## Backoff Formula
+
+```
+wait_ms = min(cap_ms, base_ms * 2^attempt) * (0.5 + random() * 0.5)
+```
+
+| Parameter | Default | Description |
+|-----------|---------|-------------|
+| `base_ms` | 100 | 基礎退避時間 |
+| `cap_ms` | 30000 | 單次最長等待上限 |
+| `max_attempts` | 5 | 最多重試次數（不含第 0 次原始呼叫）|
+| `jitter_ratio` | 0.5 | Jitter 比例（±50%）|
+
+## Failure Source Retry Rules
+
+| Failure Source | Retry? | Max Attempts | Base ms | Note |
+|----------------|--------|--------------|---------|------|
+| `transient_network` | Yes | 5 | 100 | 短暫網路抖動 |
+| `rate_limit` | Yes | 3 | 1000 | 依 `Retry-After` 優先 |
+| `upstream_unavailable` | Yes | 3 | 500 | 連續失敗觸發 breaker OPEN |
+| `tool_failure` | Yes | 2 | 200 | 工具層失敗多半非 transient |
+| `prompt_delivery` | Yes | 2 | 100 | 超過改走 model_switch |
+| `authentication` | **No** | — | — | Fail-fast，重試不會變對 |
+| `validation` | **No** | — | — | Fail-fast，input 錯不改 |
+| `policy_violation` | **No** | — | — | Fail-fast，禁止繞過 |
+| `quota_exhausted` | **No** | — | — | Fail-fast，等 reset |
+
+## Usage Examples
+
+- **Scenario 1 — 指數退避**：`failure_source=transient_network`，已重試 2 次。第 3 次 wait 範圍 = `min(30000, 100 * 2^3) * [0.5..1.0] = 400~800ms`
+- **Scenario 2 — 401 Fail-fast**：API 回 401 Unauthorized，`failure_source=authentication`。立即 fail-fast，不進退避、不計入 breaker failure count
+- **Scenario 3 — Circuit Open 跳過**：breaker 為 OPEN，發起重試時立即回 `CircuitOpenError`，不消耗 `max_attempts`
+
+## Error Codes
+
+- `RETRY-001` — `RETRY_EXHAUSTED`（達到 max_attempts 仍失敗）
+- `RETRY-002` — `RETRY_SKIPPED_NON_RETRYABLE`（failureSource 屬 fail-fast 類別）
+- `RETRY-003` — `RETRY_SKIPPED_CIRCUIT_OPEN`（breaker OPEN 狀態下跳過）
+
+## References
+
+- AI-optimized: [ai/standards/retry-standards.ai.yaml](../ai/standards/retry-standards.ai.yaml)
+- XSPEC-067: DEC-043 Wave 1 Reliability Pack 跨專案規格
+- DEC-043: UDS 覆蓋完整性路線圖（驅動來源）
+- Related: `circuit-breaker`, `failure-source-taxonomy`, `timeout-standards`, `recovery-recipe-registry`
+- Industry: Netflix Hystrix retry, Google SRE Book Ch.22, AWS Architecture Blog — exponential backoff and jitter

package/bundled/core/security-decision.md

@@ -0,0 +1,65 @@
+# Security Decision Standard
+
+> **Source**: XSPEC-037 | **Borrowed from**: claude-code-book Ch.4
+
+## Overview
+
+The Security Decision Standard defines a three-state decision model (`deny` / `ask` / `allow`) with an iron-law priority: **deny always wins**, regardless of the source's priority level. This means a low-priority user setting with `deny` overrides a high-priority policy setting with `allow`.
+
+## Three States
+
+| Decision | Priority | Behavior |
+|----------|----------|----------|
+| `deny` | 1 (highest) | Block immediately, no further evaluation |
+| `ask` | 2 | Pause and request user confirmation |
+| `allow` | 3 (lowest) | Permit operation to proceed |
+
+## Arbitration Rule
+
+```
+if any rule has deny → final decision: deny
+else if any rule has ask → final decision: ask
+else → final decision: allow
+```
+
+**Invariant**: deny wins regardless of source priority level.
+
+## CI Mode
+
+In non-interactive (CI/CD) environments, `ask` is treated as `deny` — there is no mechanism to provide human confirmation, so the operation must be blocked.
+
+## projectSettings Trust Radius
+
+Configuration from `projectSettings` (`.devap/`, `.vibeops/`) is excluded from security-sensitive operations to prevent malicious repository injection:
+
+**Blocked operations from projectSettings**:
+- Setting `requiresUserConfirmation: false`
+- Redirecting memory paths outside project directory
+- Expanding tool allowlist beyond userSettings scope
+- Downgrading deny rules to allow
+
+Log: `[WARN] projectSettings security override rejected: {operation}`
+
+## Interface
+
+```typescript
+type SecurityDecision = "deny" | "ask" | "allow";
+
+interface SecurityDecisionRule {
+  source: string;        // user | project | policy | builtin
+  decision: SecurityDecision;
+  reason?: string;
+}
+
+function arbitrate(rules: SecurityDecisionRule[]): SecurityDecision {
+  if (rules.some(r => r.decision === "deny")) return "deny";
+  if (rules.some(r => r.decision === "ask")) return "ask";
+  return "allow";
+}
+```
+
+## References
+
+- AI-optimized: [ai/standards/security-decision.ai.yaml](../ai/standards/security-decision.ai.yaml)
+- XSPEC-037: Cross-project specification
+- Borrowed from: [claude-code-book](https://github.com/lintsinghua/claude-code-book) Ch.4 four-stage permission pipeline

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

@@ -0,0 +1,79 @@
+# Skill-Standard Alignment Check
+
+> **Source**: XSPEC-070 | **Driven by**: DEC-043 Wave 1 Governance Meta Pack | **Status**: Trial (2026-04-17 ~ 2026-10-17)
+
+## Overview
+
+Skill 必有 Standard 作為錨點，Standard 可無 Skill；定期識別孤兒 Skill。Skill 是 UX 糖衣，Standard 是 standards-of-truth。若 Skill 無錨定 Standard，其行為就沒有明文依據，會隨作者口味飄移。本標準規範 Skill 必須指明錨定哪個 Standard，並定期識別「孤兒 Skill」（無對應 Standard），觸發補 Standard 的流程。反向允許 Standard 無 Skill（不強制每個 Standard 都造 Skill）。
+
+## Key Principles
+
+- **Skill 必錨 Standard**：所有 Skill frontmatter 必須含 `anchor_standard`（至少一個）
+- **Anchor 有效性**：必須指向 Trial / Active / Deprecated 狀態的標準 id
+- **Standard 可獨立**：Standard 無對應 Skill 是合法的（非錯誤，僅資訊）
+- **Orphan 治理**：無 anchor 的 Skill 列為 orphan，下一版必補或降 Proposed
+- **定期檢查**：建議季度執行 alignment check，產出 orphan 清單
+
+## Alignment Rules
+
+### Skill must have Standard
+
+- Frontmatter 必須含 `anchor_standard: <standard-id>` 或 `[<id1>, <id2>, ...]`
+- CI / pre-release 強制，缺欄位視為 fail
+- **例外**：純 utility Skill（如 docs-generator）可標 `anchor_standard: none` + 填 `utility_reason`
+
+### Standard may have Skill
+
+- Standard 獨立存在合法（可被 QualityGate / Agent 直接消費）
+- 強制每 Standard 造 Skill 會導致 Skill 庫膨脹
+- 範例：`immutability-first` 無對應 Skill 合法
+
+### Orphan Detection
+
+- 無 `anchor_standard` 的 Skill → orphan
+- 偵測後動作：列入季度報告 → 建立對應 Standard 的 XSPEC（走 admission 流程） → 無法建立則降 Skill 為 Proposed
+
+## Known Orphans (as of 2026-04)
+
+本 XSPEC-070 識別的現存 orphan Skill（由 XSPEC-063~069 補齊）：
+
+| Skill | Needs Standard | Planned XSPEC |
+|-------|----------------|---------------|
+| `slo-assistant` | slo-standards | XSPEC-063 |
+| `runbook-assistant` | runbook-standards | XSPEC-064 |
+| `incident-response-assistant` | incident-response-standards | XSPEC-063 |
+| `observability-assistant` | observability-standards | XSPEC-063 |
+| `metrics-dashboard-assistant` | metrics-dashboard-standards | XSPEC-063 |
+| `ci-cd-assistant` | ci-cd-standards | XSPEC-066 |
+
+清單將隨 XSPEC-063~069 實作逐步清空。
+
+## Alignment Check Workflow
+
+1. 掃描 `skills/**/*.md` 抽取 frontmatter `anchor_standard`
+2. 掃描 `ai/standards/*.ai.yaml` 抽取所有 `standard.id`
+3. 計算差集：Skill without anchor → orphan 清單
+4. 計算反向差集：Standard without Skill → informational
+5. 驗證 anchor 指向存在且非 Archived 的 id
+6. 產出 `alignment-report.json` / `alignment-report.md`
+
+## Usage Examples
+
+- **Scenario 1 — 健康對齊**：`retry-assistant` frontmatter 含 `anchor_standard: retry-standards`，指向 Trial 狀態標準 → 檢查通過
+- **Scenario 2 — Orphan 偵測**：`slo-assistant` 無 `anchor_standard` → 列入 orphan 清單，報告標註「需建立 slo-standards 或降 Proposed」
+- **Scenario 3 — 孤立 Standard 合法**：`immutability-first.ai.yaml` 存在但無 Skill → `standalone-standard` 計數 +1，非錯誤
+
+## Error Codes
+
+- `ALIGN-001` — `SKILL_MISSING_ANCHOR`
+- `ALIGN-002` — `BROKEN_ANCHOR`（指向不存在的 standard id）
+- `ALIGN-003` — `ARCHIVED_ANCHOR`（指向已 Archived 的標準）
+- `ALIGN-004` — `UTILITY_MISSING_REASON`
+
+## References
+
+- AI-optimized: [ai/standards/skill-standard-alignment-check.ai.yaml](../ai/standards/skill-standard-alignment-check.ai.yaml)
+- XSPEC-070: DEC-043 Wave 1 Governance Meta Pack 跨專案規格
+- DEC-043: UDS 覆蓋完整性路線圖（XSPEC-063~069 目的之一即清空本標準識別的 orphan 清單）
+- Related: `standard-admission-criteria`, `standard-lifecycle-management`
+- Internal: AsiaOstrich DEC-043 七主題缺口分析（slo/runbook/observability 等 40+ Skill 部分無 Standard 錨點）

package/bundled/core/standard-admission-criteria.md

@@ -0,0 +1,84 @@
+# Standard Admission Criteria
+
+> **Source**: XSPEC-070 | **Driven by**: DEC-043 Wave 1 Governance Meta Pack | **Status**: Trial (2026-04-17 ~ 2026-10-17)
+
+## Overview
+
+新標準納入 UDS 的四項條件。在 DEC-043 提出 60+ 候選新標準的背景下，需要一個明文的納入檢查清單，避免標準庫膨脹（重疊、未使用）與降低品質。本標準是 UDS 的治理層 meta 標準 — 用來「決定標準的標準」。每個候選新標準必須通過四項條件才能從 Proposed 進入 Trial。
+
+## Key Principles
+
+- **四項硬性條件**：所有候選新標準必須同時通過 Evidence / Scope / Non-overlapping / AI-executable
+- **拒絕理由必須具體**：不得以「不合適」之類籠統用詞結案，必須指出未通過的 criterion
+- **Admission ≠ Active**：通過 admission 僅代表可進 Trial，不代表直接 Active
+- **Self-applicability**：本標準也必須符合四項條件
+- **Backward compat**：既有 66 個 Active 標準不溯及既往
+
+## The Four Criteria
+
+### 1. Evidence（具體場景）
+
+至少 2 個具體使用場景（非 hypothetical）：
+
+- 場景來自實際專案、Repo、論文或 DEC 記錄
+- 描述具體（可舉出檔案 / 函式 / commit）
+- 至少 1 個來自 AsiaOstrich 內部痛點或外部產業佐證
+
+**拒絕範例**：「未來可能用到」— 無具體場景
+
+### 2. Scope（明確作用域）
+
+- `meta.scope` 標示 `universal` / `partial` / `uds-specific`
+- frontmatter 列出適用的活動類型（development / deployment / testing）
+- 若為 partial 或 uds-specific，說明不通用的原因
+
+**拒絕範例**：「所有場合都適用」— 過度泛化
+
+### 3. Non-overlapping（無重大重疊）
+
+與既有 UDS 標準內容重複 < 30%：
+
+- 列出最接近的 3 個既有標準，說明差異
+- 若有 ≥ 30% 重疊，應改為擴充既有標準
+- 明確定義 `integration_points`
+
+**拒絕範例**：與 `retry-standards` 80% 內容重複 — 應合併
+
+### 4. AI-executable（AI 可消費）
+
+至少一個 DevAP QualityGate / VibeOps Agent prompt / Skill 能消費：
+
+- 定義清楚的 guidelines（每條可驗證）
+- 至少 2 個 Given-When-Then scenarios
+- 需型別時提供 interface / types 區塊
+- 明確的 `integration_points`
+
+**拒絕範例**：只有抽象原則，無任何 AI 可執行的規則
+
+## Rejection Protocol
+
+1. 拒絕理由必須指出未通過的 criterion（evidence / scope / non-overlapping / ai-executable）
+2. 拒絕記錄寫入 `cross-project/decisions/` 或 DEC 的 rejection log
+3. 候選者可依理由修正後重新申請（不永久封鎖）
+4. 若拒絕理由涉及重疊，應建議改為擴充既有標準
+
+## Usage Examples
+
+- **Scenario 1 — 通過**：`retry-standards` 申請。Evidence（XSPEC-067 Scenario 1-1/1-2）、Scope（universal）、Non-overlapping（與 circuit-breaker 互補）、AI-executable（9 guidelines + 3 scenarios）全通過 → 進入 Trial
+- **Scenario 2 — 因重疊拒絕**：`advanced-retry-with-jitter` 申請。與 `retry-standards` 重疊 > 30% → 拒絕，建議改為 Phase 2 擴充
+- **Scenario 3 — 因證據不足拒絕**：`universal-best-practices` 申請。僅「未來可能用到」類描述 → 拒絕，要求至少 2 個已發生案例
+
+## Error Codes
+
+- `ADMISSION-001` — `MISSING_EVIDENCE`
+- `ADMISSION-002` — `SCOPE_UNDEFINED`
+- `ADMISSION-003` — `OVERLAP_EXCEEDED`（> 30%）
+- `ADMISSION-004` — `NOT_AI_EXECUTABLE`
+
+## References
+
+- AI-optimized: [ai/standards/standard-admission-criteria.ai.yaml](../ai/standards/standard-admission-criteria.ai.yaml)
+- XSPEC-070: DEC-043 Wave 1 Governance Meta Pack 跨專案規格
+- DEC-043: UDS 覆蓋完整性路線圖（本標準是 Wave 1 前置條件）
+- Related: `standard-lifecycle-management`, `skill-standard-alignment-check`, `adr-standards`
+- Industry: IETF RFC admission criteria, Python PEP process, W3C Recommendation Track