universal-dev-standards 5.5.0 → 5.7.0

package/bundled/core/full-coverage-testing.md

@@ -0,0 +1,183 @@
+# Full Coverage Testing Standards
+
+> **AI-optimized version**: `ai/standards/full-coverage-testing.ai.yaml`
+> **XSPEC**: XSPEC-178
+> **Replaces**: Pyramid threshold model (UT≥80%, IT≥70%, E2E happy-path-only)
+
+## Overview
+
+Full Coverage Testing is a behavior-completeness paradigm designed for the AI-era, where the cost of generating tests equals the cost of generating code. Traditional pyramid thresholds assumed tests were expensive to write — this assumption no longer holds.
+
+**Core principle**: Every public function must be tested for all three behavioral paths. Coverage is measured by behavior completeness, not percentage floors. CI enforces a ratchet: coverage can only increase, never decrease.
+
+---
+
+## Behavior-Completeness Model
+
+Instead of "80% line coverage", require:
+
+| Path | Description | Example |
+|------|-------------|---------|
+| **Happy path** | Normal input produces correct output | `calculateDiscount(100, 0.1) → 90` |
+| **Edge case** | Boundary values do not cause unexpected errors | `calculateDiscount(0, 1.0) → 0 without throwing` |
+| **Error path** | Invalid input raises clear error or error state | `calculateDiscount(-1, 2.0) → throws ArgumentError` |
+
+Every public function requires all three. This replaces the "80% of business logic" target with a qualitative, behavior-driven requirement.
+
+---
+
+## Ratchet CI Policy
+
+- The current coverage baseline is the minimum acceptable coverage
+- Any PR that decreases coverage is blocked from merging
+- Improvements update the baseline automatically on merge
+- No fixed percentage floor — the coverage achieved today is tomorrow's floor
+
+```bash
+# Stored in .coverage-baseline.json
+{ "line": 91.3, "branch": 88.7, "timestamp": "2026-05-06" }
+
+# PR regression → blocked
+Coverage regression: 91.3% → 89.1%. Ratchet threshold violated.
+
+# PR improvement → baseline updated
+Coverage improved: 91.3% → 92.0%. New baseline set.
+```
+
+---
+
+## Anti-Fake Test Rules
+
+### Forbidden: Tautology Assertions
+
+Assertions that always pass regardless of behavior provide false coverage.
+
+```typescript
+// ❌ FORBIDDEN — always passes, tests nothing
+expect(true).toBe(true)
+expect(result).toBeDefined()  // without specific value
+
+// ✅ REQUIRED — verifies actual behavior
+expect(result).toBe(90)
+expect(result).toEqual({ discount: 10, total: 90 })
+```
+
+### Forbidden: Mocking Core Business Logic
+
+Mocking your own code means the business logic is never actually executed.
+
+```typescript
+// ❌ FORBIDDEN — business logic never runs
+jest.mock('./orderService', () => ({ calculateTotal: jest.fn(() => 100) }))
+
+// ✅ ALLOWED — mock only external dependencies
+// MOCK: External Stripe API — no sandbox available in CI
+jest.mock('./payment-gateway', () => ({ charge: jest.fn().mockResolvedValue({ id: 'ch_test' }) }))
+```
+
+### Required: Mock Reason Comments
+
+Every mock must explain why the dependency cannot be real.
+
+```typescript
+// ❌ FORBIDDEN — no explanation
+jest.mock('./payment-gateway')
+
+// ✅ REQUIRED — explicit reason
+// MOCK: External payment gateway — network dependency, no sandbox in CI
+jest.mock('./payment-gateway', () => ({ ... }))
+```
+
+### Mock Boundary: What Can Be Mocked
+
+| ✅ Allowed to Mock | ❌ Forbidden to Mock |
+|-------------------|---------------------|
+| External HTTP APIs (payment, OAuth) | Core business calculation functions |
+| Hardware interfaces (sensors, GPIO) | Your own service layer methods |
+| Third-party SDKs without test mode | Database queries (use in-memory SQLite) |
+| Docker daemon | Your own utility functions |
+
+---
+
+## STUB Marker Protocol
+
+All temporary/placeholder implementations MUST be marked with the standard STUB marker. This is enforced by pre-push hooks and deploy.sh.
+
+### Marking a STUB
+
+```typescript
+// WARNING: STUB — Remove before UAT
+async function validatePayment(card: Card): Promise<boolean> {
+  return true; // Always approve — replace with real Stripe call
+}
+```
+
+### Exempting a Genuine Limitation
+
+When a dependency truly cannot be tested (hardware, live API without sandbox):
+
+```typescript
+// COVERAGE_EXEMPT: Hardware temperature sensor — no simulation available in CI
+async function readTemperature(): Promise<number> {
+  return hardwareSensor.read();
+}
+```
+
+The exemption reason MUST be non-empty and specific.
+
+### Deployment Gates
+
+| Environment | STUB Present | Action |
+|-------------|-------------|--------|
+| Feature branch push | Yes | ⚠️ Warning (not blocked) |
+| `main` branch push | Yes | ❌ Blocked |
+| Staging deploy | Yes | ⚠️ Warning (not blocked) |
+| UAT deploy | Yes | ❌ Blocked |
+| Production deploy | Yes | ❌ Blocked (critical log) |
+
+---
+
+## AC Traceability
+
+Link each test to its Acceptance Criteria using the `@ac` JSDoc tag:
+
+```typescript
+/**
+ * @ac AC-US03-2
+ */
+it('should block PR when coverage regresses below baseline', () => {
+  // test body
+})
+
+// If no AC maps to this test:
+/**
+ * @ac UNTRACED
+ */
+it('helper utility returns correct format', () => { ... })
+```
+
+CI reports AC coverage rate. If more than 20% of ACs lack `@ac`-tagged tests, a warning is shown.
+
+---
+
+## Migration from Pyramid Model
+
+If your project previously used pyramid thresholds:
+
+1. **Delete** any hardcoded coverage thresholds from `jest.config.js` / `vitest.config.ts` (`coverageThreshold` option)
+2. **Install** `.coverage-baseline.json` with current coverage as the starting ratchet
+3. **Add** `scripts/check-coverage-ratchet.sh` to CI
+4. **Add** `scripts/check-stubs.sh` to deploy.sh and pre-push hook
+5. **Add** `scripts/check-anti-fake-tests.sh` to pre-commit or CI
+
+The ratchet starts at your current coverage. From that point on, it can only increase.
+
+---
+
+## Related Standards
+
+- `testing.ai.yaml` — Test structure, FIRST principles, AAA pattern (pyramid thresholds deprecated here)
+- `unit-testing.ai.yaml` — Unit test scope and organization
+- `integration-testing.ai.yaml` — Integration test patterns
+- `deployment-standards.ai.yaml` — Deploy gate requirements
+- XSPEC-178 — Full specification and implementation phases

package/bundled/core/git-worktree.md

@@ -42,7 +42,7 @@ Define a lifecycle for using Git worktrees to isolate development work, ensuring
 
 1. **Choose worktree location** — priority order:
    - Existing configured path
-   - `.devap/worktrees/` or similar project-local directory
+   - `.uds/worktrees/` or similar project-local directory
    - Ask the user
 2. **Verify `.gitignore`** — run `git check-ignore` to confirm the worktree directory is ignored
 3. **Create the worktree** — `git worktree add <path> -b <branch-name>`

package/bundled/core/governance-layer.md

@@ -0,0 +1,151 @@
+# Governance Layer Standard
+
+> **Language**: English | [繁體中文](../locales/zh-TW/core/governance-layer.md)
+
+**Version**: 1.0.0
+**Last Updated**: 2026-05-07
+**Applicability**: All software projects with multi-agent or multi-role AI workflows
+**Scope**: universal
+**Industry Standards**: None (UDS original)
+
+---
+
+## Purpose
+
+A governance layer provides a shared anchor for all agents and roles in a project:
+Vision (direction) → Mission (boundaries + red lines) → Goals (measurable KPIs).
+
+It is **Standard #0**: evaluated before all other standards. When any conflict exists between this standard and other domain standards, this standard takes precedence.
+
+---
+
+## Three-Layer Schema
+
+### Vision
+
+| Field | Requirement |
+|-------|-------------|
+| Format | Single sentence, ≤ 50 tokens |
+| Content | Long-term direction; timeless; no metrics |
+| Change frequency | Annual review |
+
+**Example**:
+> "To be the most trusted AI development workflow standard for software teams worldwide."
+
+---
+
+### Mission
+
+| Field | Requirement |
+|-------|-------------|
+| Format | 3–5 commitment statements + red lines table (≤ 300 tokens total) |
+| Content | What we do / don't do; red lines with trigger conditions + actions |
+| Change frequency | Quarterly review |
+
+**Red line mandatory fields**:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `id` | string | Unique identifier (e.g., R1, GUARD-001) |
+| `category` | string | Classification (quality / safety / compliance / ethics) |
+| `clause` | string | Human-readable statement of what is forbidden or required |
+| `action` | enum | One of `block` \| `warn` \| `escalate_to_human` |
+
+---
+
+### Goals
+
+| Field | Requirement |
+|-------|-------------|
+| Format | KPI table, ≤ 500 tokens |
+| Change frequency | Per-Sprint calibration |
+| Falsifiability | Every KPI must be measurable — no vague terms like "improve" or "enhance" |
+
+**KPI mandatory fields**:
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `id` | string | Unique identifier (e.g., KPI-01) |
+| `metric_name` | string | Name of the metric being tracked |
+| `threshold` | string | Quantified target (e.g., ≥ 95%, < 200 ms) |
+| `measurement_method` | string | How and when the metric is measured |
+
+---
+
+## Priority
+
+The governance layer has **higher priority** than all other standards. Resolution order when conflicts exist:
+
+1. **Governance layer** (this standard) — direction, red lines, KPIs
+2. **Domain standards** (testing, commit message, deployment, etc.)
+3. **Project-specific overrides** (local `.standards/` customizations)
+
+---
+
+## Red Lines Format
+
+Each red line entry must contain all mandatory fields. Enforcement actions:
+
+| Action | Behavior |
+|--------|----------|
+| `block` | Halt the pipeline immediately; do not proceed |
+| `warn` | Log the violation and continue; escalate if threshold exceeded |
+| `escalate_to_human` | Pause and require human decision before continuing |
+
+Additionally, each red line should include a `mission_clause_ref` field referencing the mission commitment it enforces.
+
+---
+
+## Evaluator Integration
+
+When a project uses an AI evaluator agent, the governance layer provides scoring anchors:
+
+| Axis | Weight | Veto threshold |
+|------|--------|---------------|
+| Correctness | 0.4 | < 0.3 → FAIL |
+| Mission alignment | 0.3 | < 0.3 → FAIL |
+| Goal achievement | 0.3 | < 0.3 → FAIL |
+
+- **mission_alignment_score**: Degree to which the output aligns with Mission commitments
+- **goal_achievement_score**: Degree to which the output advances Goals KPIs
+- Any single axis falling below 0.3 triggers a FAIL regardless of the weighted sum
+
+---
+
+## Risk Acceptance (trace_only mode)
+
+If a project relaxes human gates (e.g., `gate.mode = trace_only`), a **Risk Acceptance Clause** must be written explicitly into `mission.md`, containing:
+
+| Required Field | Description |
+|---------------|-------------|
+| `date` | Date the risk was accepted |
+| `signatory` | Person or role accepting the risk |
+| `gates_bypassed` | Enumerated list of human gates that are bypassed |
+| `risks_accepted` | Explicit description of accepted risks |
+
+Without a valid Risk Acceptance Clause, the pipeline **must refuse to start (fail-closed)**.
+
+---
+
+## Governance File Structure
+
+Projects adopting this standard should maintain the following files:
+
+```
+governance/
+├── vision.md          # Single-sentence vision statement
+├── mission.md         # Commitments + red lines table
+└── goals.md           # KPI table (updated each Sprint)
+```
+
+---
+
+## Compliance Checklist
+
+- [ ] Vision is a single sentence ≤ 50 tokens and contains no metrics
+- [ ] Mission has 3–5 commitments and a red lines table with all mandatory fields
+- [ ] Every red line has: id, category, clause, action
+- [ ] Goals table is present with all KPIs containing: id, metric_name, threshold, measurement_method
+- [ ] No KPI uses vague language ("improve", "enhance", "better")
+- [ ] If `gate.mode = trace_only`, a Risk Acceptance Clause is present in `mission.md`
+- [ ] All AI evaluators weight correctness/mission_alignment/goal_achievement with fail-closed veto at < 0.3

package/bundled/core/llm-output-validation.md

@@ -135,10 +135,10 @@ LLM 產生「聽起來正確但實際上沒有根據」的內容。例如：
 
 ```bash
 # 1. 修改前：用 temperature=0 記錄 golden output
-vibeops run planner --input fixtures/planner-input.json --temp 0 > golden.json
+ai-agent run planner --input fixtures/planner-input.json --temp 0 > golden.json
 
 # 2. 修改後：重跑並比對
-vibeops run planner --input fixtures/planner-input.json --temp 0 > after.json
+ai-agent run planner --input fixtures/planner-input.json --temp 0 > after.json
 
 # 3. 用 contract test 驗證 after.json 仍符合 schema
 npx vitest run agents/__tests__/contract.test.ts

package/bundled/core/mock-boundary.md

@@ -21,7 +21,7 @@ This document defines rules for what can and cannot be mocked in tests. Its goal
 
 A hollow test mocks so much of the system that the test becomes a specification of mock wiring rather than system behavior. The classic symptom: you can delete the implementation file and the test still passes.
 
-**Real example (VibeOps SPEC-002.test.ts)**:
+**Real example (Multi-agent pipeline SPEC-002.test.ts)**:
 
 ```typescript
 vi.mock('../../src/runner/agent-runner.js')      // Core logic replaced

package/bundled/core/packaging-standards.md

@@ -4,19 +4,19 @@
 
 **Version**: 1.0.0
 **Last Updated**: 2026-04-15
-**Applicability**: Projects using UDS/DevAP toolchain
+**Applicability**: Projects using a UDS-aware 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.
+This standard defines a Recipe-based packaging framework that enables user projects to declare packaging targets in their packaging config (file path is adoption-layer specific). UDS provides the Recipe definitions and built-in Recipe library; the adoption-layer runtime 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)
+- **Adoption-layer pipeline**: executes *when* to package (pipeline stage between Review and Deploy)
 
 ---
 
@@ -25,9 +25,9 @@ The framework separates concerns:
 | 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 |
+| **Declarative targets** | Projects declare targets in their packaging config (file path adoption-layer specific); the runtime 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 |
+| **Pipeline-integrated** | Packaging runs as a named stage between Review and Deploy in the adoption-layer pipeline |
 
 ---
 
@@ -111,15 +111,15 @@ Projects that need to deviate from built-in Recipe defaults should use the lowes
 
 | 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 |
+| **L1 — Config Override** | `config:` block in `.uds/packaging.yaml` | Change default values (registry URL, tag, output dir) |
+| **L2 — Hook Injection** | `hooks:` block in `.uds/packaging.yaml` | Run extra commands before/after build or publish |
+| **L3 — Custom Recipe** | New `.yaml` file in project's `.uds/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
+# .uds/packaging.yaml
 targets:
   - name: publish-npm
     recipe: npm-library
@@ -132,7 +132,7 @@ targets:
 ### L2 Example — Hook Injection
 
 ```yaml
-# .devap/packaging.yaml
+# .uds/packaging.yaml
 targets:
   - name: docker-push
     recipe: docker-service
@@ -145,7 +145,7 @@ targets:
 ### L3 Example — Custom Recipe
 
 ```yaml
-# .devap/recipes/electron-app.yaml
+# .uds/recipes/electron-app.yaml
 name: electron-app
 description: Build Electron desktop application
 requires:
@@ -161,7 +161,7 @@ config:
 ### L4 Example — Escape Hatch
 
 ```yaml
-# .devap/packaging.yaml
+# .uds/packaging.yaml
 targets:
   - name: legacy-bundle
     script: |
@@ -179,9 +179,9 @@ A packaging run is considered **successful** when ALL of the following condition
 |-----------|-----------|-------|
 | 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 |
+| `postBuild` artifact exists | Present in expected path | Verified by the adoption-layer runtime 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 |
+| Published artifact is retrievable | HTTP 200 / registry query succeeds | Verified by the adoption-layer runtime post-publish smoke check |
 
 ### Failure Handling
 

package/bundled/core/performance-standards.md

@@ -323,6 +323,70 @@ Analogous to the SRE Error Budget concept, a Performance Budget defines the tole
 
 ---
 
+## Per-Release Capacity Sign-off
+
+This section defines the **capacity gate** that must be satisfied before production release (Dimension 10 in `release-readiness-gate.md`, Tier-3).
+
+### Capacity Forecast
+
+Before each release candidate, produce a capacity forecast based on:
+
+1. **Baseline**: 90-day rolling average of peak TPS and resource utilization (CPU, memory, DB connections, storage growth rate)
+2. **Release impact estimate**: expected traffic delta from new features (e.g., +15% TPS from new notification flow)
+3. **Seasonal adjustment**: any known traffic spikes within the next 30 days (marketing campaigns, seasonal peaks)
+
+### Headroom Thresholds
+
+| Metric | Target (PASS) | Warn Band | Fail Threshold |
+|--------|--------------|-----------|----------------|
+| CPU headroom at projected peak | ≥ 30% | 20–30% | < 20% |
+| Memory headroom | ≥ 25% | 15–25% | < 15% |
+| DB connection pool headroom | ≥ 40% | 25–40% | < 25% |
+| p99 latency vs baseline | ≤ +5% | +5% to +10% | > +10% regression |
+| Error rate at peak load | < 0.1% | 0.1–0.5% | > 0.5% |
+
+### Load Test Requirement
+
+Run the load test scenario defined in the Performance Testing sections above (Soak + Spike test minimum) before finalizing the capacity sign-off:
+
+```bash
+# Example: k6 capacity verification run
+k6 run --vus 500 --duration 20m scripts/perf/soak-test.js
+# Pass criterion: headroom metrics above, p99 within budget
+```
+
+### Sign-off Evidence
+
+The capacity gate requires **two named sign-offs** — both Engineering Lead and SRE Lead:
+
+```markdown
+## Capacity Sign-off — <version>
+
+**Projection date**: YYYY-MM-DD
+**Baseline period**: last 90 days
+
+| Metric | Baseline peak | Projected peak | Headroom | Status |
+|--------|-------------|---------------|----------|--------|
+| CPU | [X]% | [Y]% | [Z]% | PASS/WARN/FAIL |
+| Memory | [X]% | [Y]% | [Z]% | PASS/WARN/FAIL |
+| DB pool | [X]% | [Y]% | [Z]% | PASS/WARN/FAIL |
+| p99 latency | [X]ms | [Y]ms | [±Z]% | PASS/WARN/FAIL |
+
+**Load test artifact**: [link to load test report]
+
+**Eng Lead sign-off**: _______________ Date: __________
+**SRE Lead sign-off**: _______________ Date: __________
+```
+
+### When Tier-3 Applies as N/A
+
+The capacity sign-off is `N/A` (with documented rationale) when:
+- Project has < 100 DAU and no significant traffic growth expected
+- Internal tooling with fixed user count
+- Static content / documentation site
+
+---
+
 ## Related Standards
 
 - [Testing Standards](testing-standards.md) - Performance testing integration
@@ -330,6 +394,7 @@ Analogous to the SRE Error Budget concept, a Performance Budget defines the tole
 - [Logging Standards](logging-standards.md) - Performance logging
 - [Code Review Checklist](code-review-checklist.md) - Performance review
 - [Deployment Standards](deployment-standards.md) - Performance validation pre-deployment
+- [Release Readiness Gate](release-readiness-gate.md) - Dimension 1 (load) and Dimension 10 (capacity)
 
 ---
 

package/bundled/core/policy-as-code-testing.md

@@ -25,20 +25,20 @@ Policy as Code 的特殊風險：
 ```rego
 # 檔案命名：<policy_module>_test.rego
 # Package：<policy_package>_test
-package vibeops.guardian.forbidden_patterns_test
+package governance.guardian.forbidden_patterns_test
 
 import future.keywords.if
 
 # 正向測試：規則應觸發（assert rule fires）
 test_drop_database_is_forbidden if {
-    data.vibeops.guardian.forbidden_patterns.has_forbidden_pattern with input as {
+    data.governance.guardian.forbidden_patterns.has_forbidden_pattern with input as {
         "plan": [{"command_type": "sql", "command": "DROP DATABASE prod_main", "reversible": false}]
     }
 }
 
 # 負向測試：規則不應觸發（assert rule does NOT fire）
 test_safe_select_is_not_forbidden if {
-    not data.vibeops.guardian.forbidden_patterns.has_forbidden_pattern with input as {
+    not data.governance.guardian.forbidden_patterns.has_forbidden_pattern with input as {
         "plan": [{"command_type": "sql", "command": "SELECT * FROM users LIMIT 10", "reversible": true}]
     }
 }
@@ -79,9 +79,9 @@ docker run --rm \
 default allow = false
 
 allow if {
-    not data.vibeops.guardian.forbidden_patterns.has_forbidden_pattern
-    not data.vibeops.guardian.env_policy.prod_violation
-    not data.vibeops.guardian.logic_constraints.has_logic_violation
+    not data.governance.guardian.forbidden_patterns.has_forbidden_pattern
+    not data.governance.guardian.env_policy.prod_violation
+    not data.governance.guardian.logic_constraints.has_logic_violation
 }
 ```
 
@@ -93,9 +93,9 @@ OPA ≥ 0.40 的型別系統嚴格區分 array 和 set。`violations` partial ru
 
 ```rego
 # ✅ 正確：partial set rule 集合 violations
-deny_reasons[r] if { r := data.vibeops.guardian.forbidden_patterns.violations[_] }
-deny_reasons[r] if { r := data.vibeops.guardian.env_policy.violations[_] }
-deny_reasons[r] if { r := data.vibeops.guardian.logic_constraints.violations[_] }
+deny_reasons[r] if { r := data.governance.guardian.forbidden_patterns.violations[_] }
+deny_reasons[r] if { r := data.governance.guardian.env_policy.violations[_] }
+deny_reasons[r] if { r := data.governance.guardian.logic_constraints.violations[_] }
 
 # ❌ 錯誤：array.concat 用在 set 上 → rego_type_error
 # deny_reasons := array.concat(violations1, violations2)

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

@@ -56,8 +56,8 @@ escalation:                         # required
 
 ## Applicable Scenarios
 
-- DevAP Orchestrator selects recovery strategy before fix loop
-- VibeOps PipelineRunner handles `agent:error` with registry lookup
+- Orchestrator (adoption layer) selects recovery strategy before fix loop
+- Pipeline Runner (adoption layer) handles `agent:error` with registry lookup
 - Custom `recovery-recipes.yaml` for project-level recipe override
 - Telemetry tracking recovery strategy effectiveness