universal-dev-standards 5.4.0 → 5.6.0

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

@@ -0,0 +1,274 @@
+# Server Operations Security Standard - AI Optimized
+# Source: core/server-ops-security.md
+
+id: server-ops-security
+meta:
+  version: "1.0.0"
+  updated: "2026-05-04"
+  source: core/server-ops-security.md
+  description: >
+    Server and infrastructure operational security covering SSH hardening,
+    host configuration, privilege management, bastion patterns, patch management,
+    and network isolation for AI Agent production environments.
+
+# ─────────────────────────────────────────────────────────
+# Core Categories
+# ─────────────────────────────────────────────────────────
+categories:
+  - id: ssh_hardening
+    name: SSH Hardening
+    description: SSH service must use key-based authentication only; password login is prohibited
+    required_sshd_config:
+      - directive: PasswordAuthentication
+        value: "no"
+      - directive: PermitRootLogin
+        value: "no"
+      - directive: PubkeyAuthentication
+        value: "yes"
+      - directive: Port
+        value: "non-default (not 22)"
+      - directive: MaxAuthTries
+        value: 3
+      - directive: LoginGraceTime
+        value: 30
+      - directive: AllowUsers
+        value: explicit allowlist
+      - directive: ClientAliveInterval
+        value: 300
+      - directive: ClientAliveCountMax
+        value: 2
+    tools:
+      - name: fail2ban
+        purpose: Block brute-force IPs
+        config:
+          jailtime: ">= 3600 seconds (1 hour)"
+          findtime: 600
+          maxretry: 5
+    key_management:
+      algorithm: Ed25519 (not RSA-1024)
+      private_key: Must be passphrase-protected
+      rotation: Annual or on suspected compromise
+    iso_mapping:
+      - "ISO/IEC 27001:2022 A.8.5 Secure Authentication"
+      - "ISO/IEC 27001:2022 A.8.20 Network Security"
+
+  - id: host_hardening
+    name: Host Hardening
+    description: Minimal OS installation; only retain required services
+    cis_benchmark: CIS Benchmark Level 1 (Linux)
+    required_actions:
+      - action: Disable unused services
+        examples: [avahi-daemon, cups, bluetooth]
+      - action: Enable firewall
+        tools: [UFW, iptables]
+      - action: Enable auditd
+        purpose: System call auditing
+        target_score: ">= 75 (Lynis audit score)"
+      - action: Apply sysctl hardening
+        settings:
+          - "kernel.dmesg_restrict = 1"
+          - "net.ipv4.ip_forward = 0 (unless router)"
+          - "kernel.randomize_va_space = 2"
+      - action: Disable USB storage
+        when: USB storage not required
+      - action: Set umask 027
+        scope: system-wide default
+    tools:
+      - name: Lynis
+        command: "lynis audit system"
+        gate: Score >= 75
+      - name: OpenSCAP
+        purpose: CIS Benchmark compliance scanning
+    iso_mapping:
+      - "ISO/IEC 27001:2022 A.8.9 Configuration Management"
+      - "NIST SP 800-123 Guide to General Server Security"
+
+  - id: privilege_management
+    name: Privilege Management
+    description: Least privilege principle; service accounts must not have shell or sudo access
+    rules:
+      - rule: AI Agent service account is non-root with no login shell (/sbin/nologin)
+      - rule: Service account has access only to required directories
+      - rule: sudo entries must be explicit allowlist (no NOPASSWD ALL)
+      - rule: Each service uses an independent Unix account (no sharing)
+      - rule: Privileged accounts audited quarterly
+    sudo_policy:
+      location: /etc/sudoers.d/
+      prohibited: "NOPASSWD ALL"
+      required: Explicit command allowlist per account
+    pam_lockout:
+      module: pam_faillock (or pam_tally2 on older systems)
+      failed_attempts: 5
+      lockout_duration: "15 minutes (900 seconds)"
+    audit_tools:
+      - "sudo -l (per account review)"
+      - last
+      - lastlog
+    iso_mapping:
+      - "ISO/IEC 27001:2022 A.8.2 Privileged Access Rights"
+      - "ISO/IEC 27001:2022 A.8.18 Use of privileged utility programs"
+
+  - id: bastion_pattern
+    name: Bastion / Jump Host Pattern
+    description: Production environments must be accessed through a Bastion Host; direct SSH to prod nodes is prohibited
+    applicability:
+      staging: recommended
+      production: required
+    architecture:
+      bastion_host:
+        - Dedicated VM; sole external SSH entry point
+        - MFA enforced (TOTP or YubiKey)
+        - Session recording enabled
+      prod_nodes:
+        - Firewall rule: "iptables -A INPUT -p tcp --dport 22 -s <bastion_ip> -j ACCEPT; DROP all other SSH"
+        - No direct internet SSH exposure
+      session_recording:
+        tools: [tmux + script, Teleport, AWS Session Manager]
+        purpose: All shell sessions recorded and auditable
+      emergency_access:
+        method: Out-of-band console (iLO / iDRAC / console server)
+        purpose: Access when Bastion is unavailable
+    iso_mapping:
+      - "ISO/IEC 27001:2022 A.8.3 Information Access Restriction"
+      - "NIST SP 800-207 Zero Trust Architecture"
+
+  - id: patch_management
+    name: Patch Management
+    description: OS and packages must be regularly updated; CVE remediation has defined SLAs
+    sla:
+      - severity: Critical CVE
+        deadline: "Patch or isolate within 24 hours"
+      - severity: High CVE
+        deadline: "Patch within 72 hours"
+      - severity: Medium CVE
+        deadline: "Patch within 7 days"
+      - severity: Low CVE
+        deadline: "Next maintenance window (≤ 30 days)"
+    automation:
+      debian_ubuntu:
+        tool: unattended-upgrades
+        config: "APT::Periodic::Unattended-Upgrade 1; security updates auto-applied"
+      rhel_centos:
+        tools: [yum-cron, dnf-automatic]
+        config: "apply_updates = yes (security only)"
+    scanning:
+      containers:
+        tool: Trivy
+        command: "trivy image <image>"
+        frequency: Weekly + on every build
+      systems:
+        tool: OpenVAS
+        frequency: Weekly
+    ai_agent_specific:
+      - rule: Use official base images only
+      - rule: Base image update cadence must not exceed 90 days
+      - rule: Guardian OPA Sidecar and application containers follow same patch SLA
+    iso_mapping:
+      - "ISO/IEC 27001:2022 A.8.8 Management of Technical Vulnerabilities"
+
+  - id: network_isolation
+    name: Network Isolation
+    description: Services are network-isolated; attack surface is minimized
+    rules:
+      - rule: Prod nodes must not be directly internet-facing; expose only through load balancer or API gateway
+      - rule: Inter-service communication uses internal VPC or overlay network (no public IPs)
+      - rule: AI Agent outbound traffic uses an explicit allowlist of permitted API endpoints
+      - rule: Database ports (5432, 3306, 6379) must not be exposed externally
+      - rule: Monitoring ports (Prometheus :9090, Grafana :3000) accessible from internal network only
+    tools:
+      on_prem: [iptables, nftables]
+      aws: [Security Groups, NACLs, VPC Flow Logs]
+      gcp: [VPC Firewall Rules, Cloud Armor]
+    outbound_allowlist_format: |
+      # Example: /etc/vibeops/outbound-allowlist.conf
+      ALLOW api.openai.com:443
+      ALLOW registry.npmjs.org:443
+      DENY *:* (default deny)
+    iso_mapping:
+      - "ISO/IEC 27001:2022 A.8.20 Networks Security"
+      - "ISO/IEC 27001:2022 A.8.22 Web Filtering"
+
+# ─────────────────────────────────────────────────────────
+# Quality Gates
+# ─────────────────────────────────────────────────────────
+quality_gates:
+  pre_deploy:
+    - ssh_password_auth: disabled
+    - root_login: disabled
+    - fail2ban: enabled
+    - firewall: enabled_and_configured
+    - unattended_upgrades: enabled
+  prod_only:
+    - bastion_host: required
+    - mfa_on_bastion: required
+    - session_recording: enabled
+    - all_critical_cve: patched
+  ai_agent_specific:
+    - service_account: non_root_no_shell
+    - outbound_whitelist: configured
+    - guardian_sidecar: running
+    - audit_log: enabled
+
+# ─────────────────────────────────────────────────────────
+# Rules
+# ─────────────────────────────────────────────────────────
+rules:
+  - id: ssh-key-only
+    trigger: configuring SSH on any server
+    instruction: >
+      Set PasswordAuthentication no and PermitRootLogin no in /etc/ssh/sshd_config.
+      Verify with: sshd -T | grep -E "passwordauthentication|permitrootlogin"
+    priority: required
+
+  - id: least-privilege-service-accounts
+    trigger: deploying any AI Agent or service
+    instruction: >
+      Create a dedicated non-root Unix account for each service.
+      Set shell to /sbin/nologin. Grant only necessary directory permissions.
+    priority: required
+
+  - id: bastion-for-prod
+    trigger: accessing production servers
+    instruction: >
+      Always connect via Bastion Host. Never SSH directly to prod nodes.
+      Verify Bastion MFA is active before connecting.
+    priority: required
+
+  - id: patch-critical-cvs-24h
+    trigger: critical CVE disclosure affecting deployed system
+    instruction: >
+      Apply patch or isolate affected system within 24 hours.
+      If patch unavailable, block network access to vulnerable component.
+    priority: required
+
+  - id: outbound-allowlist
+    trigger: deploying AI Agent to production
+    instruction: >
+      Configure explicit outbound allowlist. Default deny all outbound.
+      Document each permitted endpoint with business justification.
+    priority: required
+
+anti_patterns:
+  - Direct SSH to prod nodes without Bastion
+  - PasswordAuthentication yes in /etc/ssh/sshd_config
+  - Service running as root user
+  - NOPASSWD ALL in /etc/sudoers or /etc/sudoers.d/
+  - Database or monitoring ports exposed to internet
+  - Base images older than 90 days without CVE re-scan
+  - No outbound traffic restriction on AI Agent hosts
+
+quick_reference:
+  server_ops_security_checklist: |
+    □ SSH password auth disabled (PasswordAuthentication no)
+    □ Root SSH login disabled (PermitRootLogin no)
+    □ fail2ban enabled with jailtime >= 1 hour
+    □ Firewall enabled and default-deny inbound
+    □ unattended-upgrades (security) enabled
+    □ AI Agent service account: non-root, no shell
+    □ sudo entries: explicit commands only, no NOPASSWD ALL
+    □ Bastion Host in place for prod access
+    □ MFA enforced on Bastion
+    □ Session recording enabled
+    □ Critical CVEs patched within 24h SLA
+    □ AI Agent outbound allowlist configured
+    □ DB/monitoring ports not exposed externally

package/bundled/ai/standards/slo-sli.ai.yaml

@@ -0,0 +1,97 @@
+# SLO/SLI Standards - AI Optimized
+# Source: XSPEC-063 Wave 3 SRE Pack
+
+id: slo-sli
+title: SLO/SLI Definition Standards
+version: "1.0.0"
+status: Active
+tags: [sre, reliability, observability, slo, sli, error-budget]
+summary: |
+  Defines how teams select, measure, and govern Service Level Indicators (SLIs)
+  and Service Level Objectives (SLOs). Covers SLI selection per service type,
+  SLO target-setting methodology, error budget policies, and multi-window
+  burn-rate alerting. Designed to bridge engineering reliability work with
+  customer-facing SLA commitments.
+
+requirements:
+  - id: REQ-001
+    title: SLI Selection Per Service Type
+    description: |
+      Every production service MUST define at least one SLI matched to its
+      service type. API services must measure availability (non-5xx / total)
+      and latency (requests below threshold proportion). 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).
+    level: MUST
+    examples:
+      - "availability_sli = count(http_status != 5xx) / count(all_requests)"
+      - "latency_sli = count(request_duration_ms < 200) / count(all_requests)"
+      - "freshness_sli = 1 if data_lag_minutes <= 5 else 0"
+
+  - id: REQ-002
+    title: SLO Target Setting Methodology
+    description: |
+      SLO targets MUST be set using historical baseline data. Teams MUST
+      start from the observed P5 performance (i.e., 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%).
+    level: MUST
+    examples:
+      - "Historical 28-day availability P5 = 99.92% → SLO = 99.95%"
+      - "SLA guarantees 99.9% → internal SLO set to 99.95%"
+      - "Never set SLO equal to SLA; maintain ≥ 0.05% buffer"
+
+  - id: REQ-003
+    title: Error Budget Policy
+    description: |
+      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) freeze threshold
+      (typically 50% exhausted → release freeze), (2) reliability sprint
+      trigger (100% exhausted), and (3) SLO review cadence (quarterly).
+    level: MUST
+    examples:
+      - "50% budget consumed → new feature deploys require VP approval"
+      - "100% budget consumed → team enters reliability sprint, no new features"
+      - "Error budget policy must be linked from the service runbook"
+
+  - id: REQ-004
+    title: Multi-Window Burn-Rate Alerting
+    description: |
+      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).
+    level: SHOULD
+    examples:
+      - "fast_burn: burn_rate > 14.4 for 5 minutes → PagerDuty P1"
+      - "medium_burn: burn_rate > 6 for 30 minutes → Slack #oncall P2"
+      - "slow_burn: burn_rate > 3 for 6 hours → Jira ticket auto-created"
+
+  - id: REQ-005
+    title: SLO Documentation and Review Cadence
+    description: |
+      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.
+    level: MUST
+    examples:
+      - "File: docs/slos/payment-api.slo.yaml with all required fields"
+      - "Quarterly review scheduled as recurring calendar event for service owner"
+      - "After database migration, SLO re-baselining completed within 14 days"
+
+  - id: REQ-006
+    title: SLO Compliance Reporting
+    description: |
+      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 SLO, and planned reliability
+      improvements. Dashboard links must be included.
+    level: SHOULD
+    examples:
+      - "Monthly Slack post in #reliability with SLO compliance dashboard link"
+      - "Report includes: 99.97% achieved (target 99.95%), budget 85% remaining"
+      - "Incident summary: 2 incidents, root causes addressed, no budget risk"

package/bundled/ai/standards/smoke-test.ai.yaml

@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: MIT
+name: Smoke Test Standards
+nameZh: 煙霧測試標準
+id: smoke-test
+version: "1.0.0"
+category: testing
+scope: deployment-validation
+summary: >
+  Post-deployment sanity checks that verify critical system paths are
+  operational within 30 seconds of deployment. Smoke tests fail fast and
+  alert on-call before users encounter broken deployments.
+
+requirements:
+  - id: REQ-01
+    title: Critical Path Coverage
+    titleZh: 關鍵路徑覆蓋
+    level: MUST
+    description: >
+      Smoke tests MUST cover the minimum set of critical paths: (1) process
+      starts and binds to expected port, (2) health endpoint returns 200,
+      (3) at least one core feature responds correctly. Smoke tests MUST NOT
+      cover edge cases, performance, or correctness — that is the unit test suite's job.
+
+  - id: REQ-02
+    title: Execution Time
+    titleZh: 執行時間
+    level: MUST
+    description: >
+      The full smoke test suite MUST complete in under 30 seconds. Tests that
+      take longer provide false confidence — if smoke tests run for 5 minutes,
+      on-call won't run them after every deployment.
+
+  - id: REQ-03
+    title: Zero Dependencies
+    titleZh: 零外部依賴
+    level: MUST
+    description: >
+      Smoke tests MUST NOT depend on external services (LLM APIs, databases,
+      third-party APIs) unless verifying the integration itself. Use local
+      stubs or mock servers for external dependencies.
+
+  - id: REQ-04
+    title: Deployment Integration
+    titleZh: 部署整合
+    level: SHOULD
+    description: >
+      Smoke tests SHOULD be invocable via a single command (e.g. `npm run smoke`
+      or `./smoke.sh`) and SHOULD be wired into the deployment pipeline to run
+      automatically after each deployment.
+
+  - id: REQ-05
+    title: Exit Code Contract
+    titleZh: 退出碼契約
+    level: MUST
+    description: >
+      Smoke tests MUST exit with code 0 on success and non-zero on any failure.
+      The failure message MUST identify which check failed and why.
+
+examples:
+  - name: "Node.js health check smoke test"
+    code: |
+      #!/usr/bin/env node
+      const http = require('http')
+      function check(path, expectedStatus = 200) {
+        return new Promise((resolve, reject) => {
+          http.get(`http://localhost:3000${path}`, (res) => {
+            if (res.statusCode !== expectedStatus) reject(new Error(`${path}: ${res.statusCode}`))
+            else resolve()
+          }).on('error', reject)
+        })
+      }
+      Promise.all([check('/health'), check('/api/status')])
+        .then(() => { console.log('Smoke: PASS'); process.exit(0) })
+        .catch(e => { console.error('Smoke: FAIL', e.message); process.exit(1) })
+
+anti_patterns:
+  - description: >
+      Running full integration test suite as smoke tests — smoke tests should
+      complete in 30s, not 5 minutes.
+  - description: >
+      Not failing on non-200 HTTP status — always assert the status code,
+      not just that the server responded.
+
+related_standards:
+  - testing
+  - deployment-standards
+  - performance-standards

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

@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: MIT
+name: Supply Chain Attestation Standards
+nameZh: 供應鏈溯源標準
+id: supply-chain-attestation
+version: "1.0.0"
+category: security
+scope: software-delivery
+summary: >
+  SBOM generation, SLSA provenance, and cosign signing to establish verifiable
+  software supply chain integrity from source to deployed artefact.
+
+requirements:
+  - id: REQ-01
+    title: Software Bill of Materials (SBOM)
+    titleZh: 軟體材料清單（SBOM）
+    level: MUST
+    description: >
+      Every release artefact MUST be accompanied by a CycloneDX JSON SBOM
+      listing all direct and transitive dependencies with name, version,
+      licence, and PURL. SBOM MUST be generated at build time from the
+      lock file (not package.json) to capture exact resolved versions.
+    implementation: |
+      # npm + CycloneDX
+      npm install -g @cyclonedx/cyclonedx-npm
+      cyclonedx-npm --output-format JSON --output-file sbom.cdx.json
+
+  - id: REQ-02
+    title: SLSA Provenance
+    titleZh: SLSA 溯源聲明
+    level: MUST
+    description: >
+      Every release MUST include a SLSA provenance document (minimum SLSA L1)
+      attesting the build inputs, builder identity, and build environment.
+      SLSA L2 is RECOMMENDED for public releases (requires GitHub Actions
+      OIDC token signing via slsa-framework/slsa-github-generator).
+    implementation: |
+      # SLSA L1 self-attestation (minimum)
+      provenance.json includes: buildType, builder.id,
+      invocation.configSource (repo+commit), materials, metadata.
+
+  - id: REQ-03
+    title: Artefact Signing
+    titleZh: 製品簽章
+    level: MUST
+    description: >
+      The SBOM, provenance document, and all release artefacts MUST be signed
+      using cosign (keyless Sigstore OIDC or key-based). Signatures MUST be
+      bundled with the release artefact for offline verification.
+    implementation: |
+      cosign sign-blob --key env://COSIGN_PRIVATE_KEY sbom.cdx.json > sbom.cdx.json.sig
+      cosign sign-blob --key env://COSIGN_PRIVATE_KEY provenance.json > provenance.json.sig
+
+  - id: REQ-04
+    title: Release Bundle
+    titleZh: 發布包完整性
+    level: MUST
+    description: >
+      The release bundle MUST include: primary artefact, sbom.cdx.json,
+      provenance.json, checksums.txt, and all .sig files.
+      SHA-256 checksums MUST cover all artefacts including SBOM and provenance.
+
+  - id: REQ-05
+    title: Verification Instructions
+    titleZh: 驗證指引
+    level: SHOULD
+    description: >
+      Release notes SHOULD include one-command verification instructions for
+      end-users to confirm artefact integrity using cosign and the SBOM.
+
+examples:
+  - name: "CycloneDX SBOM in GitHub Actions"
+    code: |
+      - name: Generate SBOM
+        run: |
+          npm install -g @cyclonedx/cyclonedx-npm
+          cyclonedx-npm --output-format JSON \
+                        --output-file sbom.cdx.json \
+                        --package-lock-only
+
+  - name: "SLSA L1 provenance generation"
+    code: |
+      - name: Generate SLSA L1 provenance
+        run: |
+          cat > provenance.json << EOF
+          {
+            "_type": "https://in-toto.io/Statement/v0.1",
+            "predicateType": "https://slsa.dev/provenance/v0.2",
+            "subject": [{"name": "vibeops", "digest": {"sha256": "${IMAGE_DIGEST}"}}],
+            "predicate": {
+              "buildType": "https://github.com/Attestations/GitHubActionsWorkflow@v1",
+              "builder": {"id": "https://github.com/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID}"},
+              "invocation": {"configSource": {"uri": "git+https://github.com/${GITHUB_REPOSITORY}@${GITHUB_SHA}"}},
+              "metadata": {"buildInvocationId": "${GITHUB_RUN_ID}"}
+            }
+          }
+          EOF
+
+anti_patterns:
+  - description: >
+      Generating SBOM from package.json alone — always use the lock file
+      to capture exact resolved versions, not declared ranges.
+  - description: >
+      Signing only the primary artefact and omitting SBOM/provenance from
+      the signature scope — all attestation documents must also be signed.
+
+related_standards:
+  - supply-chain-security-standards
+  - container-security
+  - sast-advanced

package/bundled/ai/standards/test-completeness-dimensions.ai.yaml

@@ -3,10 +3,10 @@
 
 id: test-completeness-dimensions
 meta:
-  version: "1.1.0"
-  updated: "2026-01-25"
+  version: "1.2.0"
+  updated: "2026-05-04"
   source: core/test-completeness-dimensions.md
-  description: Framework for evaluating test completeness across 8 dimensions
+  description: Framework for evaluating test completeness across 10 dimensions (v1.2.0 adds Flow Completeness and Branch Coverage)
 
 dimensions:
   - id: 1
@@ -92,6 +92,28 @@ dimensions:
       naming: Descriptive names (should_reject_invalid_email)
       coverage_intent: Covers all code paths meaningfully
 
+  - id: 9
+    name: Flow Completeness
+    description: At least one complete path from initial state to each terminal state exists
+    test_items:
+      - Happy path flow covers all steps in sequence with shared context
+      - Each failure terminal state has at least one flow test that reaches it
+      - Shared context (state) is verified at each intermediate step, not only the final step
+      - Preconditions are explicitly established, not assumed from previous test runs
+    when_required: When feature has 3 or more sequential steps
+    note: See flow-based-testing.ai.yaml for the full 3-step flow decomposition methodology
+
+  - id: 10
+    name: Branch Coverage
+    description: Each decision point in a flow has all branches covered by at least one scenario
+    test_items:
+      - Every if/else branch has a corresponding test scenario
+      - Each distinct error branch (not just the "main" error) has its own test
+      - Decision table applied with minimum Each-Choice coverage strategy
+      - Critical flows (auth / payment / license / security) use All-Combinations strategy
+    when_required: When flow has any conditional logic or decision points
+    note: Use decision_table_expansion from flow-based-testing.ai.yaml to enumerate scenarios
+
 feature_type_mapping:
   note: "Dimension 8 (AI Generation Quality) applies when tests are AI-generated"
   types:
@@ -119,6 +141,12 @@ feature_type_mapping:
       dimensions: [1, 3, 7]
       with_ai: [1, 3, 7, 8]
 
+    - type: Workflow / Multi-step Process
+      dimensions: [1, 3, 4, 5, 9, 10]
+      with_ai: [1, 3, 4, 5, 9, 10, 8]
+      required_pattern: journey-chained-test
+      note: Apply flow-based-testing standard; use shared ctx; Each-Choice minimum branch coverage
+
 error_code_coverage:
   - code: 200
     meaning: Success
@@ -162,11 +190,15 @@ anti_patterns:
   - Accepting AI-generated tests without review
   - Assuming high line coverage means effective tests
   - Skipping mutation testing for critical code
+  - Testing all steps in a multi-step flow independently without state threading (misses step interaction bugs)
+  - Using a single test case for a flow with multiple decision points (hides which branch failed)
+  - Resetting shared context between steps in journey tests (breaks state accumulation)
+  - Applying All-Combinations to every flow (unmaintainable; reserve for critical auth/payment/security paths)
 
 rules:
   - id: use-checklist
     trigger: designing tests for a feature
-    instruction: Use the 8 dimensions checklist to ensure completeness (dimension 8 for AI-generated tests)
+    instruction: Use the 10 dimensions checklist to ensure completeness (dim 8 for AI-generated tests; dim 9/10 for multi-step workflows)
     priority: required
 
   - id: authorization-matrix
@@ -234,6 +266,18 @@ checklist_template: |
     □ Tests are independent and self-contained
     □ Mutation score > 80% (if evaluated)
 
+  □ Flow Completeness (for multi-step features, 3+ steps)
+    □ Happy path journey test covers all steps in sequence
+    □ Each failure terminal state has a flow test reaching it
+    □ Intermediate step state verified in ctx, not only final result
+    □ Preconditions explicitly set up before Step 1
+
+  □ Branch Coverage (for flows with conditional logic)
+    □ Decision table created with all decision points and values
+    □ Each-Choice minimum coverage applied
+    □ Each distinct error branch has its own describe block
+    □ Critical flows (auth/payment/security) use All-Combinations
+
 quick_reference:
   dimensions:
     columns: [ID, Dimension, Key Focus]
@@ -246,9 +290,11 @@ quick_reference:
       - [6, Validation, Format and business rules]
       - [7, Integration, Real query verification]
       - [8, AI Generation, AI-generated test quality]
+      - [9, Flow Completeness, Complete path to each terminal state]
+      - [10, Branch Coverage, All decision-point branches covered]
 
   feature_dimensions:
-    note: "*Dimension 8 applies when tests are AI-generated"
+    note: "*Dimension 8 applies when tests are AI-generated; †Dimensions 9/10 apply to multi-step workflows"
     columns: [Feature Type, Required Dimensions]
     rows:
       - [CRUD API, "1,2,3,4,6,7,8*"]
@@ -257,3 +303,4 @@ quick_reference:
       - [Validation, "1,2,3,6,8*"]
       - [Background Job, "1,3,5,8*"]
       - [External Integration, "1,3,7,8*"]
+      - [Workflow / Multi-step Process, "1,3,4,5,9†,10†,8*"]