@jterrats/open-orchestra 1.0.4 → 1.0.6

package/docs/runtime-adapters.md

@@ -26,6 +26,13 @@ packet:
 
 - `codex-cli`: use the current Codex CLI/session. Tool permissions and shell
   approvals stay inside Codex; Orchestra renders briefs and packets only.
+- `claude-cli`: use the current Claude Code session. Orchestra renders the
+  packet and the Claude parent launches it with the native Agent/Subagent tool
+  when available; `Task` is treated as a legacy alias if that is what the
+  runtime exposes.
+- `cursor-cli`: use the current Cursor runtime. Orchestra renders the packet
+  and the Cursor parent launches it as a Background Agent so the current chat
+  remains usable while the child works.
 - `opencode-cli`: use an authenticated OpenCode CLI with its own provider
   config. Orchestra uses the generic instruction target and never copies
   provider keys into workflow artifacts.
@@ -144,12 +151,95 @@ orchestra runtime sessions --task STORY-001 --json
 orchestra runtime session --session STORY-001:claude-cli --action suspend --json
 orchestra runtime session --session STORY-001:claude-cli --action resume --json
 orchestra runtime session --session STORY-001:claude-cli --action cancel --json
+orchestra runtime spawn-request --task STORY-001 --role developer --runtime codex-cli --json
+orchestra runtime spawn-lifecycle --session STORY-001:manual:developer:codex-cli --status spawned --agent-id <runtime-agent-id> --json
 ```
 
-The matching read API is `/api/runtime/sessions`. Session operations do not kill
-external provider processes directly; they record auditable suspend, resume,
-cancel, or close events so the parent runtime can reconcile claimed work,
-stale sessions, and handoff state without inventing a second source of truth.
+The matching local APIs are `GET /api/runtime/sessions`,
+`POST /api/runtime/spawn-request`, and `POST /api/runtime/spawn-lifecycle`.
+Session operations do not kill external provider processes directly; they
+record auditable suspend, resume, cancel, close, spawned, active, completed,
+failed, or timed-out events so the parent runtime can reconcile claimed work,
+spawned agent ids, stale sessions, and handoff state without inventing a second
+source of truth.
+
+## Native Background Agent Notes
+
+Claude Code and Cursor do not need Orchestra to call vendor APIs directly.
+They need a precise packet and lifecycle hooks:
+
+- Claude Code: render `runtime spawn-request`, then launch the packet from the
+  parent Claude session with the native Agent/Subagent tool. If the local
+  Claude runtime exposes `Task` as the tool name, treat it as the compatible
+  legacy alias. Record the returned child id or role label through
+  `runtime spawn-lifecycle`.
+- Cursor: render `runtime spawn-request`, then launch it as a Cursor Background
+  Agent. Background work should stay detached from the current chat and report
+  lifecycle state back to Orchestra before the workflow is resumed.
+- All runtimes: keep `directProviderApiAllowed=false`, keep child prompts
+  scoped to the request artifact, avoid full transcript transfer, and record a
+  terminal lifecycle event before marking the phase complete.
+
+The current vendor behavior this maps to is:
+
+- Claude Code supports custom subagents with separate context and allows direct
+  subagent invocation from the parent session.
+- Cursor Background Agents run isolated remote agents in parallel and can be
+  launched while the user continues working.
+
+## Workflow Phase Executors
+
+`workflow run` can plan how each phase should be executed without confusing the
+role/profile with the runtime executor:
+
+- **Role/profile**: PM, PO, Architect, Developer, QA, Release, or another phase
+  owner. This controls responsibilities, playbooks, expected evidence, and gate
+  authority.
+- **Runtime executor**: `codex-cli`, `claude-cli`, `cursor-cli`,
+  `opencode-cli`, `vscode-agent`, `windsurf-agent`, or `generic-runtime`.
+  This controls where the brief or delegation packet is intended to run.
+- **Subagent**: a runtime-native role-scoped execution unit, only available
+  when the selected runtime adapter declares `subagents.runtimeNative: true`
+  and a supported `subagents.spawn.mode`.
+- **Spawn bridge**: the runtime-specific mechanism for creating that child
+  execution. Modes are `unsupported`, `request-only`, `parent-tool`, and
+  `local-process`. `codex-cli` is the first `parent-tool` bridge and renders a
+  `spawn_agent` request for the active Codex parent session; other runtimes can
+  consume the same request artifact without allowing Orchestra to call vendor
+  APIs directly.
+- **Provider**: a direct model/provider route used by provider-backed phase
+  prompts. Provider APIs are separate from runtime-native subagents and are
+  never used as a silent fallback for runtime delegation.
+
+The workflow phase execution mode can be selected per run:
+
+```bash
+orchestra workflow run --task STORY-001 --phase-execution auto
+orchestra workflow run --task STORY-001 --phase-execution subagents
+orchestra workflow run --task STORY-001 --phase-execution single-agent
+```
+
+`auto` uses runtime spawn request artifacts when the selected runtime supports
+them and delegation guardrails allow the spawn; otherwise it records a
+parent-agent fallback reason. `subagents` requires runtime-native support and
+fails fast if the runtime cannot satisfy it. `single-agent` forces the parent
+agent path and records that choice in phase provenance.
+
+Subagent spawning is bounded by `runtimePolicy.delegation.guardrails`.
+`maxConcurrentDelegates` is the threshold for simultaneously running delegated
+sessions, `maxSpawnsPerTask` limits fan-out for one task, and `limitAction`
+controls whether pressure should `queue` or `reject`. With the default `queue`
+policy, a phase that cannot acquire capacity is paused as a queued runtime
+subagent instead of silently falling back to the parent agent. Resume the
+workflow after capacity is released.
+
+Each phase stores executor provenance in the workflow run and handoff:
+execution mode, executor type, phase, role, runtime id, delegation packet path
+or spawn request path when one was rendered, session id when available,
+fallback reason, and `directProviderApiAllowed=false`. Spawn request artifacts
+include the phase, role, session id, parent tool name when applicable, prompt
+artifact, expected result artifact, ownership paths, queue status, and the
+guardrail evaluation so the parent runtime can prove what was delegated.
 
 Cursor canvas sync is intentionally runtime-specific:
 
@@ -200,5 +290,7 @@ The stable inspection commands are:
 orchestra runtime adapters --json
 orchestra runtime brief --task <id> --runtime codex-cli --json
 orchestra runtime delegate-plan --task <id> --runtime opencode-cli --roles qa --json
+orchestra runtime spawn-request --task <id> --role developer --runtime codex-cli --json
+orchestra runtime spawn-lifecycle --session <id> --status completed --agent-id <id> --json
 orchestra model providers --json
 ```

package/docs/runtime-llm-flow.md

@@ -223,8 +223,10 @@ budget fallback.
   approval.
 - Runtime execution adapters render briefs and delegation packets, but they do
   not yet launch external CLI/IDE processes non-interactively.
-- It records delegation decisions, but it does not automatically spawn
-  subagents yet.
+- `workflow run --phase-execution auto|subagents|single-agent` records phase
+  executor provenance and can render role-scoped runtime-native delegation
+  packets, but the parent runtime still owns any real spawn/interaction with
+  external CLI or IDE subagents.
 - Parallel independent CLI commands are expected to work, but dependent commands
   still need parent-agent ordering or future DAG semantics.
 - Workflow files are local state. Promote durable lessons into docs, skills, or

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.4",
+  "version": "1.0.6",
   "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"