universal-dev-standards 5.5.0 → 5.7.0

package/bundled/ai/standards/full-coverage-testing.ai.yaml

@@ -0,0 +1,192 @@
+# Full Coverage Testing Standards - AI Optimized
+# XSPEC-178: Replaces pyramid threshold model with behavior-completeness paradigm
+# Source: core/full-coverage-testing.md
+
+standard:
+  id: full-coverage-testing
+  name: Full Coverage Testing Standards
+  description: Behavior-completeness full coverage paradigm replacing pyramid thresholds. Enforces anti-fake-test rules, STUB marker protocol, ratchet CI, and @ac traceability.
+
+  meta:
+    version: "1.0.0"
+    updated: "2026-05-06"
+    source: core/full-coverage-testing.md
+    replaces: "testing pyramid thresholds (UT≥80%/IT≥70%/E2E happy-path-only)"
+    xspec: "XSPEC-178"
+    description: AI-era full coverage paradigm — cost of writing tests equals cost of writing code, so there is no reason to set lower thresholds for any test layer.
+
+  rationale: |
+    Traditional pyramid thresholds (UT≥80%, IT≥70%) assumed tests were expensive to write.
+    AI code generation eliminates this cost differential — code and tests are produced at the
+    same speed. Therefore: maximize coverage everywhere, with behavior-completeness as the
+    measure, not a percentage floor.
+
+  coverage_model:
+    type: behavior_completeness
+    description: Every public function must have tests for all three behavioral paths
+    required_paths:
+      - id: happy_path
+        description: Normal input produces correct output
+        example: "calculateDiscount(100, 0.1) → 90"
+      - id: edge_case
+        description: Boundary values do not cause unexpected errors
+        example: "calculateDiscount(0, 1.0) → 0 without throwing"
+      - id: error_path
+        description: Invalid input raises clear error or returns error state
+        example: "calculateDiscount(-1, 2.0) → throws ArgumentError"
+
+  ratchet_policy:
+    enabled: true
+    description: Coverage can only increase, never decrease. PR that regresses coverage is blocked.
+    mechanism:
+      - Store baseline in .coverage-baseline.json on main branch
+      - Every PR compares current coverage against baseline
+      - Regression = PR blocked, not merged
+      - Improvement = new baseline set on merge
+    note: No fixed floor threshold. The current coverage IS the threshold.
+
+  rules:
+    # ── Behavior completeness ──────────────────────────────────────
+    - id: three-path-coverage
+      trigger: writing tests for any public function
+      instruction: |
+        Write at least three tests per public function:
+        1. happy_path — normal inputs, expected output
+        2. edge_case — boundary values (zero, max, empty, null)
+        3. error_path — invalid inputs trigger explicit error or error state
+      priority: required
+
+    - id: ac-traceability
+      trigger: writing any test
+      instruction: |
+        Tag each test with the Acceptance Criteria it covers using JSDoc @ac tag.
+        Format: /** @ac AC-ID */ above the test function.
+        If no AC maps to this test, use: /** @ac UNTRACED */
+      priority: recommended
+      example: |
+        /**
+         * @ac AC-US03-2
+         */
+        it('should block PR when coverage regresses', () => { ... })
+
+    # ── Anti-fake test rules ───────────────────────────────────────
+    - id: no-tautology-assertions
+      trigger: writing any test assertion
+      instruction: |
+        FORBIDDEN: Tautology assertions that always pass regardless of behavior.
+        These add false coverage without verifying anything.
+      priority: required
+      forbidden_patterns:
+        - "expect(true).toBe(true)"
+        - "expect(false).toBe(false)"
+        - "expect(result).toBeDefined()  // without specific value"
+        - "expect(result).not.toBeNull()  // without specific value"
+      required_instead: "expect(result).toBe(<specific expected value>)"
+
+    - id: no-mock-business-logic
+      trigger: deciding what to mock
+      instruction: |
+        FORBIDDEN: Mocking core business logic or your own service functions.
+        Mocking your own code means the business logic is never actually executed.
+      priority: required
+      allowed_to_mock:
+        - External HTTP APIs (payment gateways, OAuth providers)
+        - Hardware interfaces (sensors, GPIO, Docker daemon)
+        - Third-party SDKs with no test mode
+        - File system (use tmpdir, not mock)
+      forbidden_to_mock:
+        - Core business calculation functions
+        - Your own service layer methods
+        - Database queries (use in-memory SQLite instead)
+        - Your own utility functions
+
+    - id: mock-must-have-reason
+      trigger: writing any mock/stub/spy
+      instruction: |
+        Every jest.mock(), vi.mock(), jest.spyOn(), or sinon.stub() must be preceded
+        by a comment explaining WHY this dependency must be mocked.
+        Format: // MOCK: <reason — what external dependency and why it cannot be real>
+      priority: required
+      example: |
+        // MOCK: External Stripe payment API — no sandbox available in CI
+        jest.mock('./payment-gateway', () => ({ charge: jest.fn().mockResolvedValue({ id: 'ch_test' }) }))
+
+    # ── STUB marker protocol ───────────────────────────────────────
+    - id: stub-marker-required
+      trigger: writing any temporary/placeholder implementation
+      instruction: |
+        ALL temporary implementations, placeholder functions, and fake returns
+        MUST be marked with the standard STUB marker.
+        Format: // WARNING: STUB — Remove before UAT
+        This marker is scanned by pre-push hooks and deploy.sh.
+        STUB markers block pushes to main and deployments to UAT/production.
+      priority: required
+      example: |
+        // WARNING: STUB — Remove before UAT
+        async function validatePayment(card: Card): Promise<boolean> {
+          return true; // Always approve — replace with real Stripe call
+        }
+
+    - id: coverage-exempt-format
+      trigger: dealing with genuinely untestable external dependencies
+      instruction: |
+        If a dependency truly cannot be tested (hardware, live external API with no sandbox),
+        declare an explicit exemption with a mandatory reason.
+        Format: // COVERAGE_EXEMPT: <specific reason why real test is impossible>
+        This exemption is respected by STUB scanners and will not trigger blocking.
+        The reason MUST be non-empty and specific.
+      priority: required
+      example: |
+        // COVERAGE_EXEMPT: Hardware temperature sensor — no simulation available in CI
+        async function readTemperature(): Promise<number> {
+          return hardwareSensor.read();
+        }
+
+    - id: no-silent-stub
+      trigger: reviewing code before commit
+      instruction: |
+        Stubbed/placeholder code without // WARNING: STUB is a violation.
+        Common patterns to watch for: functions that always return hardcoded values,
+        empty function bodies that should have logic, TODO comments without STUB marker.
+        These will eventually reach production undetected.
+      priority: required
+
+  deployment_gates:
+    pre_push_to_main:
+      action: block
+      trigger: "// WARNING: STUB" marker found in src/
+      message: "[STUB-BLOCK] STUB markers detected. Push to main rejected."
+    deploy_to_uat:
+      action: block
+      trigger: "// WARNING: STUB" marker found in src/
+      message: "[DEPLOY-BLOCK] STUB markers detected. UAT deployment aborted."
+    deploy_to_production:
+      action: block
+      trigger: "// WARNING: STUB" marker found in src/
+      message: "[CRITICAL] Production deployment with STUB markers is strictly prohibited."
+    deploy_to_staging:
+      action: warn
+      trigger: "// WARNING: STUB" marker found in src/
+      message: "[STUB-WARN] Deploying with STUB markers to staging. NOT permitted in UAT/production."
+    feature_branch_push:
+      action: warn
+      trigger: "// WARNING: STUB" marker found in src/
+      message: "[STUB-WARN] STUB markers found. Must remove before merging to main."
+
+  migration_from_pyramid:
+    deprecated:
+      - "UT ≥ 80% coverage threshold"
+      - "IT ≥ 70% coverage threshold"
+      - "E2E happy-path-only requirement"
+    replaced_by:
+      - "Behavior-completeness: happy/edge/error per public function"
+      - "Ratchet CI: coverage can only increase"
+      - "Anti-fake rules: no tautology, no business-logic mocks"
+      - "STUB protocol: deployment gates on all environments"
+
+physical_spec:
+  type: custom_script
+  validator:
+    command: >
+      test -f scripts/check-stubs.sh && test -f scripts/check-anti-fake-tests.sh
+    rule: "xspec178_enforcement_scripts_present"

package/bundled/ai/standards/git-worktree.ai.yaml

@@ -23,7 +23,7 @@ standard:
   lifecycle:
     - phase: setup
       steps:
-        - "選擇 worktree 目錄位置（優先順序：existing → .devap/worktrees → 詢問使用者）"
+        - "選擇 worktree 目錄位置（優先順序：existing → .uds/worktrees → 詢問使用者）"
         - "執行 git check-ignore 確認目錄被忽略"
         - "建立 worktree + 新分支"
         - "安裝依賴（若需要）"

package/bundled/ai/standards/governance-layer.ai.yaml

@@ -0,0 +1,114 @@
+# Governance Layer Standard - AI Optimized
+# Source: core/governance-layer.md
+
+id: governance-layer
+meta:
+  version: "1.0.0"
+  updated: "2026-05-07"
+  source: core/governance-layer.md
+  description: "治理層標準（Vision/Mission/Goals 三層架構 + KPI + 紅線清單）"
+  scope: universal
+  priority: meta
+
+# This is Standard #0 — evaluated before all other standards
+priority_order:
+  rule: "Governance layer overrides all other standards on conflict"
+  resolution_order:
+    1: governance-layer (this standard)
+    2: domain standards (testing, commit, deployment, etc.)
+    3: project-specific overrides
+
+# Three-layer schema requirements
+schema:
+  vision:
+    required: true
+    format: "Single sentence, ≤ 50 tokens"
+    content: "Long-term direction; timeless; no metrics"
+    change_frequency: annual
+
+  mission:
+    required: true
+    format: "3–5 commitments + red_lines table (≤ 300 tokens total)"
+    content: "What we do / don't do; red lines with trigger conditions + actions"
+    change_frequency: quarterly
+    red_lines:
+      required_fields:
+        - id           # Unique identifier (e.g., R1, GUARD-001)
+        - category     # quality | safety | compliance | ethics
+        - clause       # Human-readable forbidden/required statement
+        - action       # block | warn | escalate_to_human
+      recommended_fields:
+        - mission_clause_ref  # Reference to the mission commitment this enforces
+
+  goals:
+    required: true
+    format: "KPI table, ≤ 500 tokens"
+    change_frequency: per_sprint
+    falsifiability: "Every KPI must be measurable — no 'improve', 'enhance', 'better'"
+    kpi:
+      required_fields:
+        - id                 # Unique identifier (e.g., KPI-01)
+        - metric_name        # Name of the tracked metric
+        - threshold          # Quantified target (e.g., ≥ 95%, < 200 ms)
+        - measurement_method # How and when the metric is measured
+
+# Red line action semantics
+red_line_actions:
+  block:
+    description: "Halt pipeline immediately; do not proceed"
+  warn:
+    description: "Log violation and continue; escalate if threshold exceeded"
+  escalate_to_human:
+    description: "Pause and require human decision before continuing"
+
+# AI evaluator integration
+evaluator:
+  scoring_axes:
+    correctness:
+      weight: 0.4
+      veto_threshold: 0.3
+    mission_alignment:
+      weight: 0.3
+      veto_threshold: 0.3
+    goal_achievement:
+      weight: 0.3
+      veto_threshold: 0.3
+  veto_rule: "Any single axis < 0.3 → FAIL regardless of weighted sum"
+
+# Risk acceptance for relaxed gates
+risk_acceptance:
+  trigger: "gate.mode = trace_only (or any human gate bypass)"
+  required_fields:
+    - date
+    - signatory
+    - gates_bypassed
+    - risks_accepted
+  fail_closed: "Pipeline MUST refuse to start without a valid Risk Acceptance Clause"
+
+# Governance file structure
+file_structure:
+  directory: "governance/"
+  files:
+    - name: "vision.md"
+      content: "Single-sentence vision statement"
+    - name: "mission.md"
+      content: "Commitments + red lines table; Risk Acceptance Clause if applicable"
+    - name: "goals.md"
+      content: "KPI table (updated each Sprint)"
+
+# Compliance checklist (AI-verifiable)
+compliance_checks:
+  - id: CK-01
+    check: "Vision is a single sentence ≤ 50 tokens with no metrics"
+  - id: CK-02
+    check: "Mission has 3–5 commitments and a red_lines table"
+  - id: CK-03
+    check: "Every red line has: id, category, clause, action"
+  - id: CK-04
+    check: "Goals table present with all KPIs containing required fields"
+  - id: CK-05
+    check: "No KPI uses vague language (improve / enhance / better)"
+  - id: CK-06
+    check: "If gate.mode=trace_only, Risk Acceptance Clause exists in mission.md"
+  - id: CK-07
+    check: "Evaluator weights 0.4/0.3/0.3 with fail-closed veto at < 0.3"

package/bundled/ai/standards/mock-boundary.ai.yaml

@@ -20,7 +20,7 @@ core_problem:
     a specification of mock behavior rather than system behavior.
     The tests pass in CI while the real system silently fails.
   real_world_example: |
-    // SPEC-002.test.ts (VibeOps) — hollow test example
+    // SPEC-002.test.ts (multi-agent pipeline project) — hollow test example
     vi.mock('../../src/runner/agent-runner.js')      // Core dependency mocked
     vi.mock('../../src/runner/guardian-hooks.js')     // Core dependency mocked
     vi.mock('../../src/runner/prototyper.js')         // Core dependency mocked

package/bundled/ai/standards/model-selection.ai.yaml

@@ -103,7 +103,7 @@ standard:
           description: "數學推理準確率"
           benchmark: "gsm8k"
         instruction_following:
-          description: "複雜多步驟指令遵循率（VibeOps 最重視）"
+          description: "複雜多步驟指令遵循率（多 Agent pipeline 場景最重視）"
           benchmark: "internal-instruction-bench"
         long_context_quality:
           description: "長文件中間段資訊存取（Lost-in-the-Middle）"

package/bundled/ai/standards/packaging-standards.ai.yaml

@@ -4,12 +4,12 @@
 standard:
   id: packaging
   name: Packaging Standards
-  description: Recipe-based packaging framework for user projects using UDS/DevAP toolchain
+  description: Recipe-based packaging framework for user projects using a UDS-aware toolchain
   guidelines:
     - "Recipe-based: use built-in or custom recipes for each packaging target"
-    - "Declarative: declare targets in .devap/packaging.yaml"
+    - "Declarative: declare targets in your project's packaging config (path is adoption-layer specific)"
     - "Customizable: override config, inject hooks, or write custom recipes"
-    - "Pipeline-integrated: packaging runs between Review and Deploy in VibeOps"
+    - "Pipeline-integrated: packaging runs between Review and Deploy in the adoption-layer pipeline"
 
   meta:
     version: "1.0.0"
@@ -19,7 +19,7 @@ standard:
   principles:
     core:
       - 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 is adoption-layer specific); the adoption-layer 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"
 
@@ -82,15 +82,15 @@ built_in_recipes:
 customization_layers:
   L1:
     name: config_override
-    mechanism: "config: block in .devap/packaging.yaml"
+    mechanism: "config: block in .uds/packaging.yaml"
     when: "Change default values (registry URL, tag, output dir)"
   L2:
     name: hook_injection
-    mechanism: "hooks: block in .devap/packaging.yaml"
+    mechanism: "hooks: block in .uds/packaging.yaml"
     when: "Run extra commands before/after build or publish"
   L3:
     name: custom_recipe
-    mechanism: "New .yaml file in project's .devap/recipes/"
+    mechanism: "New .yaml file in project's .uds/recipes/"
     when: "Entirely different build process; built-ins don't apply"
   L4:
     name: escape_hatch
@@ -138,5 +138,5 @@ recipe_selection_guide:
 physical_spec:
   type: custom_script
   validator:
-    command: "test -f .devap/packaging.yaml"
+    command: "test -f .uds/packaging.yaml"
     rule: "packaging_config_declared"

package/bundled/ai/standards/pipeline-integration-standards.ai.yaml

@@ -1,6 +1,6 @@
 # Pipeline Integration Standards - DEPRECATED STUB
-# This file has been migrated to DevAP per DEC-049 (UDS/DevAP responsibility split).
-# Canonical location: dev-autopilot/standards/flow/pipeline-integration-standards.ai.yaml
+# Runtime details relocated to adoption layer (runtime moved to adoption layer 2026-04-28).
+# Adoption layer must implement an equivalent runtime; UDS retains only the human-readable concept under core/.
 # Migration: XSPEC-086 Phase 2 (2026-04-27)
 #
 # Human-readable standard: core/pipeline-integration-standards.md (remains in UDS)
@@ -14,20 +14,19 @@ standard:
     deprecated: true
     deprecated_since: "5.4.0"
     removal_version: "6.0.0"
-    canonical_owner: devap
-    canonical_path: "dev-autopilot/standards/flow/pipeline-integration-standards.ai.yaml"
+    canonical_owner: adoption-layer
+    canonical_path: "" # adoption-layer responsibility
     source: core/pipeline-integration-standards.md
     description: >
-      DEPRECATED: This standard has moved to DevAP (flow orchestration layer).
-      Install DevAP and load standards/flow/pipeline-integration-standards.ai.yaml instead.
+      DEPRECATED: Runtime details relocated to adoption layer (runtime moved to adoption layer 2026-04-28).
+      Adoption layer must implement an equivalent runtime.
 
   rules:
     - id: deprecation-notice
       trigger: starting pipeline execution
       instruction: >
-        This standard (pipeline-integration-standards.ai.yaml) has been migrated to DevAP.
+        Runtime details for this standard are now adoption-layer responsibility (runtime moved to adoption layer 2026-04-28).
         For the canonical executable definition, load:
-          dev-autopilot/standards/flow/pipeline-integration-standards.ai.yaml
 
         The human-readable standard remains at:
           universal-dev-standards/core/pipeline-integration-standards.md
@@ -36,7 +35,7 @@ standard:
     - id: fail-safe-defaults
       trigger: toggle not found in configuration
       instruction: >
-        DEPRECATED — load dev-autopilot/standards/flow/pipeline-integration-standards.ai.yaml
+        DEPRECATED — see universal-dev-standards/core/ for human-readable concept; runtime is adoption-layer responsibility
         for the current executable pipeline integration rules.
 
         Minimal fallback: Default all unset pipeline toggles to OFF (manual mode).

package/bundled/ai/standards/pipeline-security-gates.ai.yaml

@@ -1,5 +1,9 @@
 # Pipeline Security Gates (AI-Optimized v1)
 # Source: core/pipeline-security-gates.md
+# DEPRECATION NOTICE (XSPEC-086 Phase 3, 2026-04-28):
+#   Security gate orchestration (pipeline stage ordering, escalation flow) is now
+#   adoption-layer responsibility — UDS no longer ships an executable runtime.
+#   This file retains gate definitions, tools, severity levels, and failure_behavior only.
 
 standard:
   id: pipeline-security-gates

package/bundled/ai/standards/recovery-recipe-registry.ai.yaml

@@ -187,14 +187,10 @@ standard:
           on_exhaust: RecoveryStrategy
           message: "string (optional)"
 
+  # Integration guidance (informative; concrete file paths are adoption-layer concerns).
   integration_points:
-    devap:
-      files:
-        - "packages/core/src/types.ts — RecoveryRecipe / RecoveryStrategy type"
-        - "packages/core/src/recovery-registry.ts — Registry 實作與預設 recipe"
-        - "packages/core/src/orchestrator.ts — fix loop 前查詢 Registry"
-    vibeops:
-      files:
-        - "src/types/index.ts — 獨立定義 RecoveryRecipe（AGPL 隔離）"
-        - "src/runner/recovery-registry.ts — 獨立實作"
-        - "recovery-recipes.yaml — 預設 recipe 配置"
+    expected_call_sites:
+      - "core types module — RecoveryRecipe / RecoveryStrategy type"
+      - "recovery-registry module — Registry 實作與預設 recipe"
+      - "orchestrator module — fix loop 前查詢 Registry"
+      - "recovery-recipes config — 預設 recipe 配置（檔名由採用層決定）"

package/bundled/ai/standards/release-readiness-gate.ai.yaml

@@ -0,0 +1,77 @@
+# Release Readiness Gate Standards - AI Optimized
+# Source: core/release-readiness-gate.md
+
+id: release-readiness-gate
+meta:
+  version: "1.0.0"
+  updated: "2026-05-05"
+  source: core/release-readiness-gate.md
+  description: Single aggregated release gate covering 16 quality dimensions with tiered sign-off template and RQM integration
+
+requirements:
+  REQ-1:
+    id: REQ-RRG-001
+    title: 16-Dimension Coverage
+    rule: >
+      Every production release MUST evaluate all 16 quality dimensions defined in
+      core/release-readiness-gate.md. Tier-1 dimensions block release if FAIL.
+      Tier-2 dimensions require documented rationale if WARN. Tier-3 dimensions
+      require rationale if N/A.
+    rationale: >
+      Without explicit multi-dimension coverage, teams pass individual gate checks
+      but ship with unverified quality dimensions, creating systematic blind spots.
+
+  REQ-2:
+    id: REQ-RRG-002
+    title: Release Readiness Sign-off
+    rule: >
+      A Release Readiness Sign-off document MUST be created from the template in
+      core/release-readiness-gate.md for every release tag. It must be stored at
+      .release-readiness/<version>.md. The Overall Decision field must be explicitly
+      set to GO or NO-GO by a named release owner.
+    rationale: >
+      Anonymous or implicit GO decisions remove accountability; the sign-off creates
+      a named, dated, auditable record of the go/no-go decision and its evidence.
+
+  REQ-3:
+    id: REQ-RRG-003
+    title: Tier-1 Hard Block
+    rule: >
+      ANY Tier-1 dimension at FAIL status MUST block production deployment.
+      Tier-1 dimensions are: Security (Dim 2), DB Migration (Dim 5), Operational
+      Readiness (Dim 7), Rollback/DR (Dim 13), Production Smoke (Dim 14).
+    rationale: >
+      Tier-1 dimensions represent existential risks: security vulnerabilities,
+      broken rollback, misconfigured monitoring. No business justification
+      overrides a Tier-1 FAIL.
+
+  REQ-4:
+    id: REQ-RRG-004
+    title: RQM Alignment
+    rule: >
+      The machine-readable Release Quality Manifest (release-quality-manifest.md)
+      MUST include entries for all automated dimensions (a11y_critical, contract_drift,
+      cross_flow_cuj_pass_rate, browser_tier1_pass_rate, capacity_headroom_cpu_pct,
+      smoke_pass_rate, flow_gate_report). The RQM overall field must be PASS or WARN
+      (never FAIL) before deployment.
+    rationale: >
+      Human sign-off and machine manifest are complementary; the manifest enables
+      automated enforcement while the sign-off provides human accountability.
+
+  REQ-5:
+    id: REQ-RRG-005
+    title: Incremental Collection
+    rule: >
+      Release Readiness Sign-off evidence MUST be collected incrementally throughout
+      the release cycle (Gate 0 at PRD, Gate 3 pre-UAT, Gate 4 post-UAT). Creating
+      the sign-off on the day of deployment is an anti-pattern.
+    rationale: >
+      Last-minute sign-offs are rubber stamps; evidence collected late cannot
+      be acted upon without delaying the release.
+
+quick_reference:
+  tier_1_dimensions: "Security, DB Migration, Operational Readiness, Rollback/DR, Production Smoke"
+  tier_2_dimensions: "Performance, a11y, Cross-flow Regression, i18n, Docs, Feature Flags, Multi-Gate Flow"
+  tier_3_dimensions: "Contract Testing, Browser Compat, Capacity, Compliance/Privacy"
+  sign_off_location: ".release-readiness/<version>.md"
+  rqm_integration: "flow_gate_report.json → release-quality-manifest.yaml field flow_gate_report"

package/bundled/ai/standards/security-decision.ai.yaml

@@ -76,9 +76,9 @@ standard:
       message: "[WARN] projectSettings security override rejected: {operation}"
 
   applicable_components:
-    - "DevAP Safety Hook"
-    - "VibeOps CommandPolicy"
-    - "VibeOps Governance Framework (SPEC-049)"
+    - "Safety Hook 實作（採用層）"
+    - "CommandPolicy 實作（採用層）"
+    - "Governance Framework（採用層；OPA / Cedar / 自訂 policy engine 皆可）"
     - "任何多來源規則合併的安全仲裁場景"
 
   error_codes:

package/bundled/ai/standards/server-ops-security.ai.yaml

@@ -180,7 +180,7 @@ categories:
       aws: [Security Groups, NACLs, VPC Flow Logs]
       gcp: [VPC Firewall Rules, Cloud Armor]
     outbound_allowlist_format: |
-      # Example: /etc/vibeops/outbound-allowlist.conf
+      # Example: /etc/ai-agent/outbound-allowlist.conf
       ALLOW api.openai.com:443
       ALLOW registry.npmjs.org:443
       DENY *:* (default deny)

package/bundled/ai/standards/standard-admission-criteria.ai.yaml

@@ -54,7 +54,7 @@ standard:
       rejection_example: "與既有 `retry-standards` 80% 內容重複 — 應合併，不通過"
 
     ai_executable:
-      description: "至少一個 DevAP QualityGate / VibeOps Agent prompt / Skill 能消費此標準"
+      description: "至少一個採用層元件（Quality Gate / Agent prompt / Skill / IDE rule）能消費此標準"
       checks:
         - "定義清楚的 guidelines（bullet point，每條可驗證）"
         - "至少包含 2 個具體 scenarios（Given-When-Then 格式）"

package/bundled/ai/standards/standard-lifecycle-management.ai.yaml

@@ -104,7 +104,7 @@ standard:
   scenarios:
     scenario_1_trial_to_active:
       given: "retry-standards 處於 trial 狀態，since=2026-04-17, expires=2026-10-17"
-      when: "2026-08-01 審視使用情況，發現 DevAP Fix Loop 和 VibeOps Builder 都已採用，無重大缺陷"
+      when: "2026-08-01 審視使用情況，發現多個採用層（Fix Loop / Builder Agent 等）都已採用，無重大缺陷"
       then: "轉移到 Active，更新 status=active, since=2026-08-01，移除 expires 欄位"
       note: "Trial → Active 的典型路徑"
 

package/bundled/ai/standards/supply-chain-attestation.ai.yaml

@@ -85,7 +85,7 @@ examples:
           {
             "_type": "https://in-toto.io/Statement/v0.1",
             "predicateType": "https://slsa.dev/provenance/v0.2",
-            "subject": [{"name": "vibeops", "digest": {"sha256": "${IMAGE_DIGEST}"}}],
+            "subject": [{"name": "your-app", "digest": {"sha256": "${IMAGE_DIGEST}"}}],
             "predicate": {
               "buildType": "https://github.com/Attestations/GitHubActionsWorkflow@v1",
               "builder": {"id": "https://github.com/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID}"},