@jterrats/open-orchestra 1.0.3 → 1.0.5

package/docs/secret-scanning-gitleaks.md

@@ -0,0 +1,53 @@
+# Secret Scanning With Gitleaks
+
+Open Orchestra uses Gitleaks as the primary repository secret-scanning gate.
+The lightweight Node scanner remains as a local fallback when the `gitleaks`
+binary is not installed.
+
+## Local Use
+
+```bash
+npm run secret-scan
+```
+
+When `gitleaks` is available on `PATH`, the command runs:
+
+```bash
+gitleaks dir . --config .gitleaks.toml --redact --no-banner
+```
+
+When the binary is unavailable, the fallback scanner checks common private key,
+cloud key, token, password, and API key patterns so offline development still
+has a minimum guardrail.
+
+## CI
+
+The CI quality job installs the pinned Gitleaks binary and runs it before the
+precommit gate. The precommit gate then calls `npm run secret-scan`, which uses
+the same Gitleaks configuration in CI because the binary is already installed.
+
+## Configuration
+
+Rules live in `.gitleaks.toml` and extend the default Gitleaks ruleset.
+Allowlists are limited to generated/dependency paths and explicit placeholder
+values such as `<secret>` or GitHub Actions `${{ secrets.NAME }}` references.
+
+Do not allowlist real secrets. Rotate and purge the secret instead.
+
+## Operational SaaS Boundary
+
+Repository scanning is not enough for a SaaS/runtime deployment. Runtime inputs
+also need secret and prompt-injection guardrails before agents or providers can
+read them:
+
+- prompts
+- lessons learned
+- evidence
+- logs
+- uploaded artifacts
+- model outputs
+- GitHub issue bodies and comments
+- tenant integrations
+
+Operational scans must redact or quarantine findings, record provenance, and
+apply tenant-specific retention and regulatory policies.

package/docs/site-manifest.json

@@ -112,6 +112,9 @@
     "links": [
       { "title": "Adoption guide", "source": "docs/adoption-guide.md", "heading": "Open Orchestra 1.0.0 Adoption Guide" },
       { "title": "Core command surface", "source": "docs/core-command-surface.md", "heading": "Core Command Surface" },
+      { "title": "Duplicate-code enforcement", "source": "docs/duplicate-code-enforcement.md", "heading": "Duplicate-Code Enforcement" },
+      { "title": "Sonar quality gates", "source": "docs/sonar-quality-gates.md", "heading": "Sonar Quality Gates" },
+      { "title": "Sonar architecture model", "source": "docs/sonar-architecture-model.md", "heading": "Sonar Architecture Model" },
       { "title": "Runtime adapters", "source": "docs/runtime-adapters.md", "heading": "Runtime Adapters" },
       { "title": "Site content workflow", "source": "docs/site-content-workflow.md", "heading": "Public Site Content Workflow" }
     ]
@@ -119,6 +122,8 @@
   "releaseDocs": {
     "links": [
       { "title": "Release test matrix", "source": "docs/release-test-matrix.md", "heading": "1.0.0 Release Test Matrix" },
+      { "title": "Sonar quality gates", "source": "docs/sonar-quality-gates.md", "heading": "Sonar Quality Gates" },
+      { "title": "Sonar architecture model", "source": "docs/sonar-architecture-model.md", "heading": "Sonar Architecture Model" },
       { "title": "QA evidence", "source": "docs/site-content-workflow.md", "heading": "QA Evidence" },
       { "title": "Package naming", "source": "docs/package-naming.md", "heading": "Package Naming Decision" },
       { "title": "Upgrade dogfooding", "source": "README.md", "heading": "Quick Start" }

package/docs/sonar-architecture-model.md

@@ -0,0 +1,178 @@
+# Sonar Architecture Model
+
+This document defines the intended module boundaries that Sonar architecture
+analysis should eventually enforce for Open Orchestra. Until Sonar-specific
+directives are configured, this is the portable source of truth for architecture
+review, code review, and workflow gate evidence.
+
+## Domains
+
+### CLI and Command Surface
+
+Files:
+
+- `bin/`
+- `src/*-commands.ts`
+- `src/commands.ts`
+
+Responsibilities:
+
+- parse command input;
+- call domain services;
+- format CLI output;
+- avoid business logic beyond validation and dispatch.
+
+Expected dependencies:
+
+- may depend on domain services, workflow services, config loaders, and typed
+  output helpers;
+- must not own persistence rules, workflow state transitions, provider routing,
+  or web UI behavior.
+
+### Workflow and Delivery Domain
+
+Files:
+
+- `src/workflow*.ts`
+- `src/task*.ts`
+- `src/release*.ts`
+- `src/review*.ts`
+- `src/evidence*.ts`
+- `src/qa*.ts`
+
+Responsibilities:
+
+- task lifecycle;
+- workflow phases and gates;
+- handoffs, reviews, evidence, acceptance coverage, release readiness.
+
+Expected dependencies:
+
+- may depend on persistence helpers, domain types, policy checks, and prompt
+  registry services;
+- should expose narrow service APIs for command and web entry points.
+
+### Runtime, Model, Budget, and Telemetry
+
+Files:
+
+- `src/model*.ts`
+- `src/runtime*.ts`
+- `src/budget*.ts`
+- `src/telemetry*.ts`
+
+Responsibilities:
+
+- provider routing;
+- model provenance;
+- cost, token, runtime, and budget controls;
+- telemetry consent, export, and submission audit.
+
+Expected dependencies:
+
+- may depend on workflow identifiers and policy/config types;
+- must not depend on UI code or generated site assets.
+
+### Profiles, Roles, Skills, and Guidance
+
+Files:
+
+- `src/profiles/`
+- `src/roles/`
+- `src/skills*.ts`
+- `src/generators/`
+- `src/prompt*.ts`
+- `skills/`
+- `rules/`
+
+Responsibilities:
+
+- role metadata;
+- runtime capability selection;
+- skill rendering;
+- generated guidance and prompt registry validation.
+
+Expected dependencies:
+
+- may depend on shared domain types and generation utilities;
+- must keep role/capability data centralized instead of hardcoding lists across
+  commands or UI surfaces.
+
+### Web API and Web Console
+
+Files:
+
+- `src/web-api*.ts`
+- `src/web-console-client.js`
+- `web-console/src/`
+
+Responsibilities:
+
+- expose local read/write APIs;
+- render task, workflow, evidence, recovery, provider, and settings views;
+- keep user-facing flows responsive, accessible, and evidence-oriented.
+
+Expected dependencies:
+
+- web API may depend on domain services;
+- React/client code should not import Node-only modules or mutate workflow files
+  directly.
+
+### Site and Documentation Publishing
+
+Files:
+
+- `site/`
+- `scripts/generate-site-content.js`
+- `docs/site-manifest.json`
+- public documentation under `docs/`
+
+Responsibilities:
+
+- generate and publish public documentation content;
+- render docs-driven site pages;
+- keep public docs separate from internal workflow evidence.
+
+Expected dependencies:
+
+- may read approved docs manifests and public content;
+- must not depend on local workflow state, secrets, or private evidence.
+
+### Extensions
+
+Files:
+
+- `extensions/`
+
+Responsibilities:
+
+- editor integration;
+- command invocation adapters;
+- local service bridge behavior.
+
+Expected dependencies:
+
+- may call public CLI/API contracts;
+- should not duplicate workflow business rules already owned by `src/`.
+
+## Boundary Rules
+
+- Commands stay logic-light and delegate to services.
+- Domain services do not import from web console, site, or extension code.
+- Generated assets and docs do not become runtime sources of truth.
+- Capability, role, provider, command, and workflow phase lists use centralized
+  domain helpers instead of repeated hardcoded arrays.
+- Security-sensitive code paths keep auth, secrets, file paths, shell execution,
+  network calls, and provider credentials behind explicit services and tests.
+- Architecture changes that cross these boundaries need an Orchestra decision or
+  ADR-style note before implementation.
+
+## Sonar Directive Adoption
+
+When Sonar directive files are introduced, they should encode the domains above
+as enforceable layers or dependency rules. The implementation task must include:
+
+- the directive format supported by the connected Sonar edition;
+- a failing/passing validation example;
+- a Sonar run showing directives consumed by the architecture sensor;
+- a review that maps any initial violations to GitHub issues or accepted risks.

package/docs/sonar-quality-gates.md

@@ -0,0 +1,178 @@
+# Sonar Quality Gates
+
+Open Orchestra uses Sonar as a repository and SaaS project-quality signal. It
+does not replace secret scanning or runtime policy enforcement.
+
+## Repo Audit
+
+The repository includes `sonar-project.properties` and a dedicated GitHub
+Actions workflow at `.github/workflows/sonar.yml`.
+
+Required GitHub secret:
+
+- `SONAR_TOKEN`: token for SonarQube Cloud or SonarQube Server.
+
+Optional GitHub secret:
+
+- `SONAR_HOST_URL`: required only for self-hosted SonarQube Server. Leave unset
+  for SonarQube Cloud.
+
+The workflow skips analysis when `SONAR_TOKEN` is not configured. This keeps
+forks and offline development usable while making Sonar a CI quality gate for
+configured environments.
+
+The workflow supports remote quality gate enforcement when the repository
+variable `SONAR_QUALITY_GATE_WAIT=true` is configured. In that mode the scanner
+runs with `sonar.qualitygate.wait=true` and `sonar.qualitygate.timeout=300`. A
+failed quality gate fails the GitHub Actions job instead of reporting only a
+successful scanner upload.
+
+The token used for this mode must be able to read the Sonar project and quality
+gate status. If the scanner can upload analysis but the wait step fails with
+`Project not found`, update the `SONAR_TOKEN` permissions or keep
+`SONAR_QUALITY_GATE_WAIT` unset until the token can read the project.
+
+Recommended minimum quality gate for new code:
+
+- 0 new blocker or critical issues.
+- 0 new vulnerabilities.
+- Security hotspots reviewed before release.
+- Duplicated lines on new code below 3%.
+- Maintainability rating A on new code.
+- Reliability rating A on new code.
+- Coverage reported from `coverage/lcov.info` for source files on every Sonar
+  run.
+
+## Coverage Publishing
+
+The Sonar workflow runs `npm run test:coverage` before analysis. That command
+builds the TypeScript sources, runs the Node test suite through `c8`, and writes
+LCOV to `coverage/lcov.info`.
+
+`sonar.javascript.lcov.reportPaths=coverage/lcov.info` publishes the LCOV file
+to Sonar. The report is generated from source maps, so coverage entries map back
+to `src/*.ts` files instead of generated `dist/*.js` files.
+
+Coverage is intentionally split by surface:
+
+- Core TypeScript modules: included in LCOV.
+- CLI entry points under `bin/`: included in LCOV when exercised by tests.
+- VS Code extension runtime files under `extensions/`: included in LCOV when
+  exercised by tests.
+- Site and web console: excluded from LCOV until browser coverage is wired in;
+  they require Playwright screenshots, traces, videos, or E2E reports as release
+  evidence.
+- Tests and E2E files: excluded from coverage accounting.
+- Scripts: excluded from product coverage, but validated through CI commands
+  and targeted script tests where they enforce delivery gates.
+
+`coverage/` is ignored locally and should not be committed.
+
+## New Code Baseline
+
+The project uses `main` as the new-code reference branch through
+`sonar.newCode.referenceBranch=main`. This aligns Sonar's changed-lines and
+new-code behavior with the repository default branch and avoids falling back to a
+legacy `master` reference.
+
+The Sonar workflow also creates local `master` compatibility refs that point to
+`origin/main` inside the temporary GitHub Actions checkout. This does not create
+or push a real `master` branch; it only gives Sonar's SCM changed-lines analysis
+a legacy fallback ref when the remote Sonar project still asks for `master`.
+
+## Architecture Analysis
+
+The intended architecture model is documented in
+[`sonar-architecture-model.md`](sonar-architecture-model.md). Sonar's scanner can
+discover JavaScript and TypeScript dependency graphs today, but Open Orchestra
+does not yet commit Sonar-specific architecture directive files because the
+portable architecture source of truth is still the repository documentation,
+rules, and Orchestra review gates.
+
+Until Sonar directives are adopted, architecture violations are enforced through:
+
+- repo standards in `AGENTS.md` and `rules/*.mdc`;
+- architecture gate decisions and ADR-style records;
+- code review against domain boundaries;
+- tests that protect command contracts, workflow behavior, and generated
+  guidance.
+
+When Sonar directive support is configured for this project, it should use the
+same domains from `sonar-architecture-model.md`; the two models must not diverge.
+
+## Dependency Analysis
+
+## Tool Boundaries
+
+Use the tools together instead of treating one as a replacement for another:
+
+- Sonar: bugs, code smells, maintainability, duplication, coverage, and security
+  hotspots.
+- Sonar dependency analysis/SCA: enabled when the connected Sonar plan supports
+  it. Dependency manifests such as `package-lock.json` must remain visible to
+  the scanner.
+- Gitleaks: secrets in code, history, issues, prompts, lessons, evidence, logs,
+  artifacts, and model output.
+- `npm audit`: local and CI dependency vulnerability control for this package.
+- jscpd: local duplicate-code detection and fast copy-paste feedback.
+- `collection-standards`: semantic duplication of domain lists, command
+  matrices, role/status lists, providers, fixtures, selectors, and validators.
+
+If a Sonar run still reports `Dependency analysis skipped`, treat that as an
+environment or plan-level SCA limitation, not as proof that dependency risk is
+covered. Release evidence must then include `npm audit` and secret scanning
+results, plus Dependabot or equivalent repository alerts when available.
+
+When Sonar reports duplicated code that represents a repeated domain collection,
+the remediation should load `collection-standards` and extract a typed source of
+truth rather than only reshaping the copied block.
+
+## SaaS Findings Architecture
+
+Future SaaS integration should import or correlate Sonar findings as project
+quality evidence without moving tenant source code through Open Orchestra unless
+the tenant explicitly enables that mode.
+
+Minimum SaaS controls:
+
+- Bind each Sonar project to one tenant and one Open Orchestra project.
+- Store Sonar tokens per tenant/project with least privilege and rotation
+  metadata.
+- Keep tenant findings isolated by tenant id, project id, provider, branch, and
+  scan id.
+- Persist finding provenance: detector, rule id, severity, component, branch,
+  commit, quality gate status, imported timestamp, actor, and review state.
+- Convert findings into Orchestra evidence, reviews, or GitHub issues with
+  explicit owner and severity mapping.
+- Apply retention policies per tenant and regulation profile.
+- Never expose another tenant's findings, source paths, or scan metadata.
+- Do not use Sonar as a prompt/log/secret scanner; route those surfaces through
+  Gitleaks/redaction/quarantine policy before they reach agents or providers.
+- Use `.gitleaks.toml` and `npm run secret-scan` for repository scanning.
+  Runtime/SaaS secret scanning needs additional tenant-aware redaction,
+  quarantine, provenance, and retention controls.
+
+Suggested SaaS flow:
+
+1. Tenant connects Sonar project with scoped token.
+2. Open Orchestra stores provider binding and quality gate expectations.
+3. CI or webhook publishes scan metadata to the SaaS.
+4. SaaS imports quality gate status and selected findings.
+5. Findings are deduplicated against existing Orchestra evidence/issues.
+6. Security, Tech Lead, QA, or Release Manager reviews findings based on
+   severity and release impact.
+7. Approved mappings become task evidence, review blockers, or GitHub issues.
+
+## Release Readiness
+
+For this repository, Sonar should be treated as:
+
+- Required when `SONAR_TOKEN` is configured in CI.
+- Blocking at the remote quality gate level when `SONAR_QUALITY_GATE_WAIT=true`
+  and the token has read permission for the Sonar project.
+- Advisory for local/offline development.
+- Blocker for release when the configured quality gate fails on new code.
+
+For SaaS tenants, whether Sonar is required or advisory is a tenant policy
+decision. Regulated tenants may require quality gate pass evidence before
+release approval.

package/docs/task-split-assessment.md

@@ -0,0 +1,34 @@
+# Task Split Assessment
+
+Open Orchestra treats oversized work as an advisory delivery risk before
+implementation starts. The goal is not to block small tasks; it is to make PO/BA
+and Architect reviews explicit when one backlog item is trying to carry multiple
+stories or too much technical coupling.
+
+## Ownership
+
+- Product Owner / BA review functional oversize: multiple journeys, unrelated
+  outcomes, too many acceptance criteria, hidden support/release scope, or UX
+  discovery that expands the story.
+- Architect reviews technical complexity: too many modules, boundaries,
+  integrations, data changes, runtime changes, UI changes, infra changes, or
+  release surfaces in one task.
+
+## Expected Output
+
+When split risk is found, the reviewer records a recommendation with:
+
+- rationale
+- proposed child stories or technical slices
+- dependency order
+- risks
+- owner roles
+
+Routine small fixes stay as one task when they do not exceed the advisory
+thresholds.
+
+## CLI Surface
+
+`orchestra workflow phase-plan --task <id> --json` includes
+`splitAssessment`. The field is advisory and can be attached to a review,
+clarification, decision, or follow-up task.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jterrats/open-orchestra",
-  "version": "1.0.3",
+  "version": "1.0.5",
   "type": "module",
   "workspaces": [
     "extensions/vscode-open-orchestra",
@@ -14,12 +14,14 @@
     "build": "tsc && npm run build:web",
     "typecheck": "tsc --noEmit",
     "test": "npm run build && node --test test/**/*.js extensions/**/*.test.cjs",
+    "test:coverage": "npm run build && c8 --reporter=lcov --reports-dir coverage --exclude \"test/**\" --exclude \"e2e/**\" --exclude \"extensions/**/test/**\" --exclude \"dist/assets/**\" --exclude \"dist/web-console/**\" node --test test/**/*.js extensions/**/*.test.cjs",
     "test:e2e": "npm run build && npm run site:build && playwright test",
     "test:e2e:init": "node --test e2e/init-onboarding.test.js",
     "lint": "eslint . && prettier --check \"{bin,e2e,scripts,test,src}/**/*.js\" \"{site,web-console}/src/**/*.{css,js,jsx}\" \"{site,web-console}/*.{html,js,json}\" \"extensions/**/*.{cjs,json,md}\" \"src/**/*.ts\" \"*.{js,json}\"",
     "format": "prettier --write \"{bin,e2e,scripts,test,src}/**/*.js\" \"{site,web-console}/src/**/*.{css,js,jsx}\" \"{site,web-console}/*.{html,js,json}\" \"extensions/**/*.{cjs,json,md}\" \"src/**/*.ts\" \"*.{js,json}\"",
     "secret-scan": "node scripts/secret-scan.js",
     "security:audit": "node scripts/security-audit.js",
+    "duplicates": "jscpd --config .jscpd.json",
     "validate:workflow": "node scripts/validate-workflow.js",
     "release:matrix": "node scripts/release-test-matrix.js",
     "performance:bench": "npm run build && node scripts/performance-benchmark.js",
@@ -40,9 +42,11 @@
     "@eslint/js": "^10.0.1",
     "@playwright/test": "^1.59.1",
     "@types/node": "^25.6.0",
+    "c8": "^11.0.0",
     "chart.js": "^4.5.1",
     "esbuild": "^0.28.0",
     "eslint": "^10.2.1",
+    "jscpd": "^4.2.3",
     "prettier": "^3.8.3",
     "typescript": "^6.0.3",
     "typescript-eslint": "^8.59.0"

package/skills/chaos-resilience-testing/SKILL.md

@@ -0,0 +1,127 @@
+# Chaos Resilience Testing
+
+Design deterministic failure scenarios that prove workflows, APIs, providers,
+gates, budgets, and regulated flows degrade safely.
+
+## When To Load
+
+- Trigger: `chaos`
+- Trigger: `resilience`
+- Trigger: `fault injection`
+- Trigger: `failure mode`
+- Trigger: `provider timeout`
+- Trigger: `provider unavailable`
+- Trigger: `offline mode`
+- Trigger: `circuit breaker`
+- Trigger: `rate limit`
+- Trigger: `budget exhaustion`
+- Trigger: `approval race`
+- Trigger: `policy failure`
+- Trigger: `audit failure`
+- Trigger: `stale data`
+- Trigger: `corrupted state`
+- Trigger: `tenant isolation`
+- Trigger: `regulated flow`
+
+## Procedure
+
+1. Identify the task, acceptance criteria, impacted runtime surfaces, and the
+   user-visible or release-critical outcome that must survive failure.
+2. Classify each failure as one of:
+   - fail closed: security, approvals, regulated authority, secrets, PII/PHI,
+     payment, policy, tenant isolation, or destructive actions;
+   - degrade with recovery: optional enrichment, UI panels, advisory features,
+     non-critical telemetry, or external references;
+   - retry with bounds: transient provider/API, storage, webhook, or scheduler
+     failures with explicit timeout, backoff, and retry limits.
+3. Select deterministic scenarios before implementation. Prefer controlled
+   stubs, fake providers, injected stores, fixture corruption, and bounded
+   timeout simulation over random production-style fault injection.
+4. For each scenario, define:
+   - fault injected;
+   - expected behavior;
+   - expected user/operator message;
+   - expected audit/event/evidence output;
+   - recovery path;
+   - acceptance criteria covered.
+5. Validate at least the relevant categories:
+   - provider/model timeout or unavailable provider;
+   - external API/network unavailable;
+   - corrupted or partially written local state;
+   - stale reads or cache mismatch;
+   - concurrent update/approval race;
+   - budget/rate-limit exhaustion;
+   - policy engine denial or failure;
+   - audit/event write failure;
+   - offline mode with optional sources unavailable;
+   - tenant/regulatory boundary enforcement.
+6. Capture observable evidence. A passing command alone is not enough; prove the
+   final state, emitted event, user message, skipped activation, blocked gate, or
+   recovery artifact.
+7. Record unresolved resilience gaps with owner, severity, release impact, and
+   whether Product/Security/Compliance accepted the risk.
+
+## Stack Guidance
+
+- Start with local deterministic faults: Node tests, fake providers, fake
+  storage/repositories, controlled timers, `AbortController`, injected clocks,
+  and fixture corruption.
+- Use Playwright route stubs for web/API degraded states such as timeout, stale
+  data, malformed payload, empty response, or server error.
+- Use Docker Compose, Toxiproxy, WireMock/MSW/Pact, k6, and OpenTelemetry only
+  when integration or SaaS boundaries require network/service-level evidence.
+- Use Chaos Mesh or LitmusChaos only for future Kubernetes-managed services;
+  these are not npm package MVP dependencies.
+- Keep stack details in backlog or architecture docs and load only the relevant
+  scenario guidance into task context.
+
+## Evidence Report Template
+
+```md
+# Chaos / Resilience Evidence
+
+Task:
+Issue/User Story:
+Environment:
+Date:
+
+## Scenario Matrix
+
+| Scenario | Fault | Expected behavior | Actual behavior | Evidence | Result |
+| -------- | ----- | ----------------- | --------------- | -------- | ------ |
+
+## Acceptance Criteria Coverage
+
+| AC | Scenario | Result | Notes |
+| -- | -------- | ------ | ----- |
+
+## Recovery And Audit
+
+| Scenario | Recovery path | Audit/event evidence | User/operator message |
+| -------- | ------------- | -------------------- | --------------------- |
+
+## Gaps
+
+| Gap | Severity | Owner | Release decision |
+| --- | -------- | ----- | ---------------- |
+```
+
+## Acceptance Rules
+
+- Security, compliance, tenant isolation, approval, regulated authority, secrets,
+  and payment-related failures must fail closed unless an explicit accepted risk
+  says otherwise.
+- Optional enrichment and advisory features may degrade, but must expose clear
+  rationale and recovery guidance.
+- Retries must be bounded by timeout, retry count, backoff, and budget policy.
+- Chaos evidence must map back to acceptance criteria and release gates.
+- A generated or automated reviewer cannot self-approve resilience gaps in
+  regulated or high-risk flows.
+
+## Evidence
+
+- `command`
+- `file`
+- `log`
+- `report`
+- `trace`

package/skills/chaos-resilience-testing/manifest.json

@@ -0,0 +1,61 @@
+{
+  "id": "chaos-resilience-testing",
+  "name": "Chaos Resilience Testing",
+  "summary": "Design deterministic failure scenarios that prove workflows, APIs, providers, gates, budgets, and regulated flows degrade safely.",
+  "triggers": [
+    "chaos",
+    "resilience",
+    "fault injection",
+    "failure mode",
+    "provider timeout",
+    "provider unavailable",
+    "offline mode",
+    "circuit breaker",
+    "rate limit",
+    "budget exhaustion",
+    "approval race",
+    "policy failure",
+    "audit failure",
+    "stale data",
+    "corrupted state",
+    "tenant isolation",
+    "regulated flow"
+  ],
+  "roles": [
+    "qa",
+    "sdet",
+    "sre",
+    "security",
+    "architect",
+    "developer",
+    "devops",
+    "platform_engineer",
+    "release_manager"
+  ],
+  "capabilities": [
+    "resilience-testing",
+    "chaos-testing",
+    "failure-mode-analysis",
+    "operational-readiness"
+  ],
+  "riskAreas": [
+    "security",
+    "release",
+    "integration",
+    "governance",
+    "sre",
+    "devops",
+    "compliance",
+    "performance"
+  ],
+  "sourceGroups": [
+    "quality-security",
+    "devops-runtime",
+    "architecture",
+    "product-backlog",
+    "agent-memory"
+  ],
+  "evidence": ["command", "file", "log", "report", "trace"],
+  "loadBudget": "normal",
+  "entry": "skills/chaos-resilience-testing/SKILL.md"
+}