docs(harness): document control plane workflow

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>

docs/harness-engineering.md

@@ -63,6 +63,8 @@ Primary suites:
   - lint, typecheck, and unit coverage for normal component work
 - `pnpm harness:validate:docs`
   - Storybook build for docs-surface changes
+- `pnpm harness:validate:a11y`
+  - curated Storybook accessibility validation from the shared browser coverage contract
 - `pnpm harness:validate:docs-smoke`
   - Playwright smoke coverage for high-value Storybook flows
 - `pnpm harness:validate:consumers`
@@ -76,6 +78,9 @@ Primary suites:
 
 Each run writes a JSON report to `.artifacts/harness/<suite>.json`.
 
+GitHub Actions uploads the generated harness, a11y, and browser test artifacts from `.artifacts/`
+so CI failures stay debuggable after the run finishes.
+
 ## Working Loop
 
 Recommended change loop:
@@ -98,6 +103,10 @@ Harness selection is exposed through `pnpm harness:select` and `pnpm harness:val
 - `pnpm harness:validate:changed`
   - runs the selected suites with a JSON report
 
+The CI workflow uses `pnpm harness:validate:changed` as its execution entrypoint. Selection is no
+longer advisory-only: harness-risk and release-risk surfaces escalate directly to the broader `pr`
+or `release` gates instead of falling back to `static`.
+
 Selection intentionally maps repo surfaces to validation surfaces:
 
 - package source changes select `component`, `docs`, `docs-smoke`, and `consumers`
@@ -105,6 +114,25 @@ Selection intentionally maps repo surfaces to validation surfaces:
 - registry/consumer changes select `static` and `consumers`
 - doc-only or metadata-only changes may select no suites
 
+High-risk control-plane changes override those narrow mappings:
+
+- `scripts/harness/*` and other harness-control files escalate to `pr`
+- release workflows, release docs, registry docs, and consumer/release scripts escalate to `release`
+
+## Browser Coverage Contract
+
+Curated browser coverage lives in `tests/e2e/support/story-harness-contract.json`.
+
+That contract is the shared source of truth for:
+
+- `pnpm harness:validate:a11y`
+- `pnpm harness:validate:docs-smoke`
+
+Each entry records the story id, why it is covered, which suites own it, and any required
+interaction scenario keys. When a new high-value review surface should participate in browser or
+accessibility validation, update this contract instead of adding one-off story lists in multiple
+scripts.
+
 ## Worktree Orchestration
 
 Cadence UI also exposes an orchestration wrapper:
@@ -114,23 +142,35 @@ Cadence UI also exposes an orchestration wrapper:
 The wrapper keeps orchestration state under `.artifacts/orch/` and applies worktree defaults for
 dispatch. Details live in [docs/orchestration.md](/Users/xd/project/cadence-ui/docs/orchestration.md).
 
+Use `pnpm harness:orch -- doctor` to verify binary discovery and plan parsing on a new machine, and
+prefer `dispatch --plan-file <plan>` so execution plans remain the source of truth for generated
+task bodies.
+
 ## Current Rollout Scope
 
 This repository is adding harness engineering in phases.
 
-Phase 1 establishes:
+Phase 1 established:
 
 - a documented harness workflow
 - execution-plan conventions
 - shared validation suites
-- a pull request workflow that runs the PR suite
+- a pull request workflow that runs the repository harness gate
 
-Phase 2 adds:
+Phase 2 established:
 
 - change-aware suite selection from git diff
 - a stabilized Storybook smoke harness
 - worktree-oriented orchestration defaults
 
+Phase 3 hardens:
+
+- authoritative changed-suite execution in CI
+- uploaded CI artifacts for harness, a11y, and browser test output
+- a shared browser coverage contract
+- orchestration preflight and plan-linked dispatch helpers
+- harness self-tests for selection, artifact, and orchestration helpers
+
 Future phases can layer on:
 
 - richer browser/app harnesses for interactive review