Workflow

The harness expects non-trivial change to flow through OpenSpec, land as Conventional Commits, and pass a fresh-eyes review before merge.

OpenSpec

Non-trivial changes go through the OpenSpec cycle:

/opsx:propose  →  /opsx:apply  →  /opsx:verify  →  /opsx:archive

• propose writes the change: proposal, design, spec deltas, and a task list.
• apply implements the tasks.
• verify is required before opening a PR — it checks the implementation against the change artifacts.
• archive moves the completed change into history; the archived folder ships in the PR.

Conventional Commits

Commit messages are enforced by the commit-msg hook:

type(scope)?(!)?: subject

Types: feat, fix, docs, style, refactor, perf, test, build, chore, ci, revert. Examples:

• feat(api): add rate limiting to /submit
• fix(health): return 503 when the KV probe fails
• chore(deps): bump wrangler to 3.101

The version bump at release time is derived from these commits by git-cliff.

Review, proportional to risk

After /opsx:verify, and before any non-trivial PR:

• harness-reviewer — a fresh-eyes subagent for correctness and scope. verify checks spec compliance; the reviewer checks a *different* failure class (bugs, scope creep, missed edge cases).
• app-evaluator — for UI-bearing changes only. It drives the live PR preview and evaluates the actual rendered behavior.

Reviewer proportionality. Skip both for trivial changes — a typo, a log line, a one-liner you can describe in a single sentence. Match the review to the risk: don't run a full evaluation on a comment fix, and don't skip it on a change that touches auth, money, or data shape.

After the PR opens

Raw make check output is posted to the PR automatically as a comment (chunked if it is large), so reviewers see the exact gate result with no clicking through CI.