@shahboura/harness 3.0.4

package/.opencode/skills/dev-workflow/steps/harden-task.md

@@ -0,0 +1,12 @@
+# Instruction: hardening tests (developer shape, mode `harden`)
+
+You are topping up coverage on code that already exists — tests must be
+meaningful, not gaming:
+
+- **Assertion depth (review-policy `assertion-depth`):** assert the full
+  observable contract — response body shape, error envelope, side effects.
+  Status-code-only or not-throws-only assertions are incomplete.
+- Target the diff-coverage gaps you were given, not incidental old code.
+- Never modify implementation code in this mode — tests only.
+- Commit via `bin/harness commit --commit-class working`; report via the status
+  block with the coverage delta you achieved.

package/.opencode/skills/dev-workflow/steps/harden.md

@@ -0,0 +1,30 @@
+# Step: harden (developer shape, mode `harden`)
+
+Coverage top-up after ⟨approve-impl⟩ — tests here are green-from-birth
+(they cover code that already exists), so NO red-proof machinery applies.
+
+1. Resolve the coverage command: `bin/harness
+   resolve-coverage-cmd --repo <repo>` (per repo, `language.repos.<repo-
+   name>.coverage_cmd` — `discover` proposes one at `/init-workspace` time
+   where repo evidence supports it: python/go conventions, a node
+   `coverage` script or jest/vitest+provider, jacoco in a java pom). Null
+   means unconfigured — ask the user, never improvise a command. Their
+   answer is either a command (write it to
+   `language.repos.<name>.coverage_cmd` the `/workspace-config` way, then
+   re-resolve) or an explicit skip — record that with
+   `bin/harness log-event --json '{"kind":
+   "coverage-skipped", "repo": "<name>", "reason": "<their words>"}'` and
+   harden that repo from the tasks' own test gaps instead. Run the resolved command to find diff-coverage gaps against
+   the tasks' touched files.
+2. Spawn `developer` with `harness-mode: harden` (+ run/repo/test-cmd
+   headers — test-cmd is per repo, same `language.repos.<repo-name>.test_cmd`
+   convention as `develop`) and the gap list. It follows `steps/harden-task.md`.
+3. Spawn `reviewer` (`harness-mode: review`) on the new tests.
+4. The DEVELOPER already committed its tests (harden-task.md's own
+   commit step — do not commit again from here; a second commit in
+   the same repo either fails on "nothing to commit" or sweeps unrelated
+   files via `git add -A`). Produce `<run>/reports/coverage.md`
+   summarizing before/after coverage and record the declared artifact:
+   `bin/harness artifact --name coverage-report
+   --value reports/coverage.md --run <run>`.
+5. Advance: `bin/harness cursor --to security --run <run>`.

package/.opencode/skills/dev-workflow/steps/intake.md

@@ -0,0 +1,52 @@
+# Step: intake (planner shape)
+
+Spawn the planner to turn the normalized work item into a requirements
+summary. It reads `<run>/work-item.json` — it has no provider access.
+
+Spawn `planner` with prompt headers:
+
+```
+harness-mode: intake
+harness-run: <run>
+harness-repo: <primary-repo-path>
+```
+
+…plus the ask: read `work-item.json` (+ the repo-map at
+`.claude/context/repo-map/<repo-name>/` if present — index first, then
+only the area files the work item touches), produce
+`<run>/requirements.md` — restated requirements, acceptance criteria,
+ambiguities/clarifying questions for the human.
+
+The repo-map is generated at `/init-workspace` and its freshness is
+(re)checked and stamped at **plan step 0** (the single owner). Here, just
+READ what's present — do NOT generate it, run `repo-map-check`, or stamp
+`.meta.json`; a missing or stale map is plan's job to refresh, not
+intake's. (If it's absent, intake still proceeds on `work-item.json`
+alone.) Don't investigate its status — plan handles it.
+
+If the status block reports clarifying questions, surface them to the user
+and relay answers (append to `requirements.md` via a re-spawn if substantial).
+When surfacing them, **separate the two kinds** rather than presenting one
+undifferentiated list:
+
+- **confirm-a-default** — a question with a safe, stated default (you can
+  proceed if the human doesn't object). Batch these together and present the
+  default you'll take; a non-answer resolves cleanly.
+- **resolve-a-real-fork** — a genuine either/or with no grounded default
+  (both branches are live). Present each on its own and wait for an explicit
+  pick; never bundle one of these behind a default, and never imply a fork is
+  settled when it isn't.
+
+Mixing the two produces partial-answer states (the human ratifies the easy
+defaults and the real fork silently rides along unanswered).
+
+Note the run's seeded task list (`T1`) is a **provisional placeholder** —
+fetch's positional default (`repos[0]`), flagged `provisional: true` in
+state, not a scope decision. Do not present it to the human as one; the real
+task list is set at plan-register and replaces it wholesale.
+
+Record the declared artifact once requirements.md is final:
+`bin/harness artifact --name requirements-summary
+--value requirements.md --run <run>`.
+
+Then advance: `bin/harness cursor --to plan --run <run>`.

package/.opencode/skills/dev-workflow/steps/metrics.md

@@ -0,0 +1,21 @@
+# Step: metrics (orchestrator-owned, fully mechanical)
+
+```
+bin/harness metrics --run <run>
+```
+
+Deterministic aggregation — timings from state, tokens from the ledger,
+flagged events — into `<run>/reports/metrics.md`. No agent reasoning. Show
+the user the summary. Final mirror **once per preflighted repo** (SKILL.md's
+Publish rule — never the workspace), `--push` required so this closing
+snapshot (metrics report included) actually reaches each PR's remote
+branch instead of stranding locally:
+`bin/harness publish-mirror --repo <preflighted-repo-path> --push --run <run>`.
+Then declare the run finished — the successful sibling of abort, terminal
+by declaration (mutations refuse from here on; the audit trail stays):
+
+```
+bin/harness complete --run <run>
+```
+
+The run is done.

package/.opencode/skills/dev-workflow/steps/plan-task.md

@@ -0,0 +1,108 @@
+# Instruction: produce the plan (planner shape, mode `plan`)
+
+Produce `<run>/plan.md`: the human-facing design for this story. Both
+altitudes of approach decision below are approved at the single
+`approve-plan` gate (design.md:495 — one gate, two altitudes).
+
+## 0. Ground in the repo map
+
+Before decomposing, read the auto-generated map at
+`.claude/context/repo-map/<repo-name>/` for each repo the story touches —
+the index first, then only the area detail files this story is likely to
+touch (each is loadable standalone; never load the whole map). This is
+where "the team uses <pattern>" comes from — cite it instead of
+re-deriving the codebase. Two boundaries: the map speeds targeting, it
+never replaces reading the real code for areas you plan to change; and its
+freshness was already settled by the orchestrator before your spawn — READ
+what's there, never run `repo-map-check`/`repo-map-stamp` or write
+`.meta.json`. A missing map is not a blocker: proceed on code reading
+alone and note the absence in your self-adversarial pass.
+
+## 1. Decomposition
+
+Tasks keyed by id (`T1`, `T2`…), each with: description, repo, edge-case
+enumeration, risk tier, dependencies. One task = one reviewable unit.
+
+**`depends_on` is HARD technical blockers ONLY — it is mechanically
+enforced and gates cross-repo parallelism.** A task can't start until every
+task it `depends_on` is done (the `dependencies-done` guard refuses), and
+you can't loosen the graph past the plan gate (registration is plan-step-
+only) — so an over-declared edge permanently *serializes work that could
+run concurrently*. Declare an edge only when B literally cannot begin until
+A completes (B compiles against a symbol A introduces, B's tests need code
+A writes first, B mutates state A sets up). Do NOT encode as `depends_on`:
+a cross-repo consumer whose contract is already ratified in
+`requirements.md` (it doesn't depend on the producer's *implementation* —
+build it in parallel against the fixed contract, stub the response; the
+**ratified contract is the sync point, model it as a Cross-repo contract
+below, not an edge** — e.g. a frontend task consuming a ratified backend
+API is `depends_on: []`, not `[<backend tasks>]`); or mere merge/read order.
+If your self-adversarial pass flags an edge as "soft / for clarity / not a
+hard blocker," **remove it** (note sequencing in prose if useful) — the
+enforced graph doesn't read your annotation. Keep the dependency diagram
+faithful to the hard edges only: the graph the human approves is the one
+that runs.
+
+## 2. Solution Approaches (top-level altitude — only when a fork exists)
+
+When a genuine architectural fork exists for the **whole story** (not a
+per-task implementation detail), write a `## Solution Approaches` section:
+2–3 whole-solution options (name, summary, trade-offs) + a recommendation.
+**Skip this section when no real fork exists** — a single obvious approach
+forces no filler comparison; over-triggering is worse than omitting it. Skip
+silently, though, and the human at the gate can't tell "no fork" from
+"missed one" — so when you skip it, add one line instead: `No architectural
+fork identified: <why>` under the task table, visible either way.
+
+## 3. Per-task detail
+
+- **Test-intents**: named tests + one-line intent each, per task, as a
+  literal block under that task's section:
+  ```
+  Test-intents:
+  - test_name_one — one-line intent
+  - test_name_two — one-line intent
+  ```
+  Name each test exactly as the developer should write it (function/method
+  name) — `verify-red` mechanically checks these literal names appear in
+  the actual test files (coverage B1); the orchestrator carries the name
+  list, not the intent prose, into `plan-register`'s `test_intents` field.
+- **`[API: <lib> v<X>]`** annotations where a task prescribes a library API
+  — the developer verifies the real signature before writing call sites.
+- **≤2 pattern hints** per task: existing test files via bounded globbing
+  (≤5 globs), ranked by mtime, filename match only (no reading contents).
+  "No match" is a valid answer — don't widen the search.
+- **Per-task approach options** where a single task (not the whole story)
+  has more than one reasonable implementation — distinct from the
+  story-level altitude in step 2.
+- **Cross-repo contracts**, multi-repo stories only: name the producer repo,
+  consumer repo(s), and signature fragment(s) for anything one repo's task
+  emits and another's depends on — the enriched shape in `steps/plan.md`'s
+  registration example.
+
+## 4. Diagrams
+
+Four Mermaid diagrams, styled per `shared/diagram-styling.md`:
+
+1. **Class/type diagram** (`classDiagram`) — new/modified types,
+   relationships, key methods. Mark scope with `:::new` / `:::modified` on a
+   dedicated `class <Name>:::<style>` statement — NOT on a relationship
+   endpoint or bare reference (classDiagram grammar rejects those; see
+   `shared/diagram-styling.md`).
+2. **Runtime flowchart** (`flowchart TD`) — the feature's runtime flow,
+   decision points, external interactions, error paths.
+3. **Sequence diagram** (`sequenceDiagram`, `autonumber`) — actor
+   interactions, call order, sync vs async, key payloads.
+4. **Task dependency graph** (`flowchart LR`) — one node per task id, edges
+   from `depends_on`. Required for every story, even single-task ones.
+
+## 5. Self-adversarial pass
+
+Before finalizing: list ambiguities, risks, and unchecked assumptions in the
+draft. Revise or flag them — don't ship a plan you haven't tried to break.
+
+## 6. Register + advance
+
+Mechanics (the `plan-register` call, gate advance) live in
+`steps/plan.md` — this file is the content contract, that file is the
+registration procedure. Don't duplicate one into the other.

package/.opencode/skills/dev-workflow/steps/plan.md

@@ -0,0 +1,80 @@
+# Step: plan (planner shape)
+
+0. **Repo-map freshness — this step is its SINGLE owner.** The repo-map is
+   first generated at `/init-workspace`; nothing between there and here
+   touches it (intake only reads it), so this is the one place in the
+   pipeline that confirms it's current. Its status is filesystem-only
+   (`.claude/context/repo-map/<name>/.meta.json`) — not in `state.yaml`, so
+   the `show` verb won't surface it; check it explicitly, per registered
+   repo:
+   `bin/harness repo-map-check --repo-name <name>
+   --repo <path>`.
+   - `fresh` → nothing to do (init already generated + stamped it; do NOT
+     re-stamp).
+   - `missing`/`stale` → regenerate (spawn `planner` with
+     `harness-mode: repo-map`, a declared out-of-run-legal pair) and stamp
+     via `bin/harness repo-map-stamp` after it
+     returns — a plan grounded in a stale map cites patterns that no longer
+     exist.
+0b. **Re-entering plan** (gate rejection / approved mid-run amendment)?
+   Snapshot the current plan first — copy `<run>/plan.md` to
+   `<run>/plan-r<n>.md` — so the previously-approved text stays
+   recoverable. Never rewrite it silently.
+
+Spawn `planner` with headers (`harness-mode: plan`, `harness-run`,
+`harness-repo`) to produce `<run>/plan.md`. It follows `steps/plan-task.md`
+(the content contract). The plan's REQUIRED content (coverage decisions
+B1/B2/B7/B8 — the gate presents all of it):
+
+- Tasks keyed by id (`T1`, `T2`…), each with: description, repo, edge-case
+  enumeration, risk tier, dependencies.
+- **Per-task test-intents** (named tests + one-line intent each) — approved
+  at the plan gate; carry the NAMES (not the intent prose) into
+  `plan-register`'s `test_intents` field per task — `verify-red` mechanically
+  checks each declared name is written, no re-declaration needed later.
+- **Approach options, two altitudes**: a top-level `## Solution Approaches`
+  section (2–3 whole-solution options + recommendation) only when a genuine
+  architectural fork exists, distinct from per-task options — both approved
+  at this one gate. Skipped → one line saying why, never silent.
+- `[API: <lib> v<X>]` annotations where a task prescribes a library API.
+- ≤2 existing-test-file **pattern hints** per task (bounded discovery).
+- **Four diagrams** — class/type, runtime flowchart, sequence, task
+  dependency graph — per `shared/diagram-styling.md` (full spec in
+  `steps/plan-task.md`).
+- A **self-adversarial pass**: ambiguities, risks, unchecked assumptions.
+
+When the planner's status block reports the plan ready:
+
+1. Register the tasks it declared (replaces the single fetch-seeded task):
+   `bin/harness plan-register --run <run> --tasks-json
+   '[{"id":"T1","repo":"<path>","risk":"low","test_intents":["test_name_one",
+   "test_name_two"]}, …]'` — `repo` must be the exact path string from this
+   workspace's `repos.yaml` (i.e. `config["repos"]`'s VALUE, e.g.
+   `/abs/path/to/backend`), never the short registered NAME (`backend`) —
+   a name instead of a path resolves to no registered repo and fails
+   silently until a later step (`verify-red`/task completion) reports a
+   confusing "no test command" error instead of a clear one here.
+   `risk` is free-form (defaults to `low` if omitted) — no enum is
+   enforced, but use `low`/`medium`/`high` for consistency with what the
+   plan itself declares. (`test_intents` is the plan's declared test
+   NAMES for that task, empty if none) — declare cross-repo contracts too if
+   the plan named any: `--contracts-json '[{"id":"C1","type":"http",
+   "producer":"a","consumers":["b"],"signature":["POST /v2/items",
+   "field: item_id"]}]'` (`type` is `http | service-bus | dto`, descriptive
+   only; `signature` is one string or a list of fragments, and **each must be
+   a grep-able code token/signature that appears verbatim in source** —
+   `archived`, `filter_notes(notes, tag)`, `POST /v2/items` — NOT an English
+   description: reconcile-contracts matches by literal source search, so a
+   prose fragment is rejected at plan-register and would false-report drift.
+   All fragments must be present; the flat legacy `"repos":["a","b"]` form
+   still works in place of `producer`/`consumers`. Legal only at cursor `plan`.
+2. Check the diagrams: `bin/harness validate-mermaid
+   --file <run>/plan.md`. A non-zero exit names structural rule violations
+   (`failures` in the JSON) — send the planner back to fix them, never
+   advance past a failure. Purely structural (well-formed Mermaid that
+   exists); it doesn't check the four diagrams are actually present — that
+   stays plan-task.md's content-contract job.
+3. Record the declared artifact: `bin/harness
+   artifact --name plan --value plan.md --run <run>` (the gate presents it
+   by this name).
+4. Advance to the gate: `bin/harness cursor --to approve-plan --run <run>`.

package/.opencode/skills/dev-workflow/steps/pre-pr-fixes.md

@@ -0,0 +1,16 @@
+# Step: pre-pr-fixes (developer shape, mode `fixup`; reached on gate rejection)
+
+Task commits are already squashed — fixes need the fixup path (never new
+loose commits, never history edits by hand):
+
+1. Spawn `developer` with `harness-mode: fixup` + the gate's findings.
+   It follows `steps/fixup-task.md`.
+2. After its fixup commits land:
+   `bin/harness merge-task --repo <repo> --autosquash --base <default-branch>
+   --run <run>` — folds them into their task commits and re-derives the
+   tracker SHAs.
+3. Record the declared artifact: `bin/harness
+   artifact --name fixup-commits --value "<findings addressed> @ <new HEAD
+   sha>" --run <run>`.
+4. Return via the declared edge: `bin/harness cursor --to pre-pr --run <run>`
+   (the pre-PR review re-runs on the corrected branch).

package/.opencode/skills/dev-workflow/steps/pre-pr-review.md

@@ -0,0 +1,14 @@
+# Instruction: holistic pre-PR review (reviewer shape, mode `pre-pr`)
+
+Review the ENTIRE feature branch (all squashed task commits) as one change:
+
+- Re-run build + full test suite yourself — never trust reported results.
+- Check each review-policy rule from config (assertion-depth,
+  patch-dto-wrapper, team rules) and cite violations by file:line.
+- Check plan-vs-implementation drift: does what shipped match what was
+  approved? Are the declared test-intents all realized?
+- Hunt the TDD residuals: semantically-empty tests (red for the wrong
+  reason), impl overfit to the test, weakened shared fixtures.
+- Findings numbered `[R<n>]` with severity CRITICAL | WARNING | SUGGESTION.
+- Deliver the full report text in your status block `details` (the
+  orchestrator persists it — you cannot write files).

package/.opencode/skills/dev-workflow/steps/pre-pr.md

@@ -0,0 +1,14 @@
+# Step: pre-pr (reviewer shape, mode `pre-pr`)
+
+1. Multi-repo runs first: `bin/harness reconcile-contracts --run <run>` — drift
+   goes in front of the human at the gate, never auto-fixed.
+2. Spawn `reviewer` with `harness-mode: pre-pr` (+ run/repo headers): a
+   holistic review of the full feature branch — cohesion across tasks,
+   review-policy rules, plan-vs-implementation drift, the residuals the TDD
+   lock can't catch (semantically-empty tests, impl-overfit).
+3. The reviewer is read-only: it reports the review in its status block; YOU
+   persist it to `<run>/reports/pre-pr.md` verbatim and record the declared
+   artifact: `bin/harness artifact --name pre-pr-report
+   --value reports/pre-pr.md --run <run>`.
+4. Advance to ⟨approve-pre-pr⟩ (`gate.md`); present the report AND the
+   contracts verdict. Rejection routes to `pre-pr-fixes` (declared edge).

package/.opencode/skills/dev-workflow/steps/preflight.md

@@ -0,0 +1,32 @@
+# Step: preflight (orchestrator-owned, fully mechanical)
+
+Create the feature branch in each affected repo from the declared naming
+template — one owned command per repo:
+
+```
+bin/harness preflight --repo <repo-path> --run <run>
+```
+
+First ensures the repo is clean and on its default branch (the reusable
+precondition `discover` also uses at `/init-workspace` time, standalone as
+`bin/harness ensure-default-branch --repo <repo-path>
+[--branch <name>]` for any future step that needs it) — a dirty repo, or
+one mid-rebase/merge, refuses
+(surface to the human, never auto-stash/discard/continue); a clean repo on
+a different branch is switched, no confirmation needed. Pass `--branch
+<name>` to override the auto-resolved guess. Idempotent on retry, per
+repo: a `branches` entry already recorded for *this* repo is returned
+directly rather than re-derived — a second repo's preflight is never
+satisfied by the first repo's record (each repo gets its own entry). **Known risk:** two runs started concurrently
+against the *same* repo path can race here (no repo-level lock exists yet)
+— use a separate clone/checkout per concurrent run against the same repo.
+Then it renders `naming.branch` (`{type}/{id}-{slug}`) from state, creates
+the branch, and records the `branches` artifact. It also pins
+`.harness-key` into the repo's `.git/info/exclude` (shared with its task
+worktrees), so a stray integrity key can never be swept into git history
+by the commit verbs' `git add -A`; the commit verbs refuse-and-unstage as
+backstop. Then:
+
+```
+bin/harness cursor --to develop --run <run>
+```

package/.opencode/skills/dev-workflow/steps/quick-recheck.md

@@ -0,0 +1,14 @@
+# Step: quick-recheck (orchestrator-owned; quick mode only)
+
+The ex-ante classifier saw only work-item text; this step checks the REAL
+diff against the declared disqualify patterns:
+
+```
+bin/harness quick-recheck --repo <repo> --base <default-branch> --run <run>
+```
+
+- `clean` → advance to `pre-pr`.
+- `dirty` → the escalation edge is MANDATORY: `pre-pr` is now illegal;
+  advance to `security` (`bin/harness cursor --to security`) — the run switches
+  to full mode and continues from there. Tell the user why (the hits are in
+  the events ledger).

package/.opencode/skills/dev-workflow/steps/reconcile.md

@@ -0,0 +1,27 @@
+# Step: reconcile (orchestrator-owned, fully mechanical)
+
+## MCP-transport work-item providers (ado-mcp / jira / zoho)
+
+A script can't call an MCP tool, so plain `bin/harness reconcile` would try to
+dispatch `work_item.transition` itself and refuse every time write-back is on
+(the default). Run the transition in the orchestrator instead, same pattern
+as `fetch.md`:
+
+1. If `write_back.on_done` (or the milestone in play) is enabled, invoke the
+   mapped `work_item.transition` tool (`bin/harness
+   provider --op work_item.transition --id <id> --to <status>` prints the
+   exact tool + args to call).
+2. Then run reconcile with the transition skipped (already done above):
+   ```
+   bin/harness reconcile --skip-transition --run <run>
+   ```
+
+## CLI-transport providers (github / gitlab / ado / local-markdown)
+
+```
+bin/harness reconcile --run <run>
+```
+
+Provider status write-back (conservative default: done), archives completed
+tasks (declared FSM edge), sweeps leftover worktrees. Then advance to
+`metrics`.

package/.opencode/skills/dev-workflow/steps/review-task.md

@@ -0,0 +1,32 @@
+# Instruction: per-task review (reviewer shape, mode `review`)
+
+Review ONE task's diff (its worktree branch vs the feature branch), inside
+the develop loop:
+
+- Re-run the task's tests yourself (`harness-test-cmd`) — independent
+  verification, never trust the developer's claim. Long output? Capture it
+  under /tmp (`… 2>&1 | tee /tmp/review.log`) — /tmp and /dev/null are
+  your only legal write targets; any other shell write is blocked. Spell
+  the path LITERALLY: a variable-held target (`$SCRATCH/x`, `$(mktemp -d)`)
+  can't be verified by the guard and blocks even when it points at /tmp.
+- Check the diff against: the task's plan section (scope drift?), the
+  config review-policy rules, and the engineering baseline
+  (`shared/engineering.md`). For test-intents: run
+  `bin/harness show-redproof --task <T> --run <run>`
+  (chain-verified; a raw `.redproof/` read skips integrity verification
+  and is guard-BLOCKED — and type that full invocation exactly: the bare
+  `harness` spelling is neither on PATH nor allow-listed, so it dies as a
+  permission denial) and check its `missing_intents` field
+  (already mechanically checked, not yours to recompute) — any entry is a
+  finding. A present name isn't automatically a pass, though: judge whether
+  it genuinely tests its declared intent (design.md:392 — presence is
+  mechanical, semantic match stays yours).
+- Findings numbered `[R<n>]` with severity CRITICAL | WARNING | SUGGESTION;
+  `verdict: APPROVED` only when nothing CRITICAL/WARNING remains. The
+  verdict is its OWN block line, before `outcome`/`details` (the template's
+  third line — never inside another field's prose): one run into the end
+  of a sentence is deliberately not captured (fail-closed) and costs a
+  full re-review by a fresh reviewer.
+- Full findings in the status block `details` — the orchestrator routes
+  them; rejection costs a bounded review round (round N+ escalates to the
+  human), so make every finding actionable.

package/.opencode/skills/dev-workflow/steps/security.md

@@ -0,0 +1,18 @@
+# Step: security (orchestrator-owned, fully mechanical)
+
+```
+bin/harness security-scan --run <run>
+```
+
+One call scans every registered repo (`security.scan_cmd` is per repo,
+language-config convention — different repos may need different scanners;
+"no scanner" for a repo records informational). Runs concurrently, parses
+each repo's max severity via the declared regex, aggregates to ONE true max
+across all repos (never a per-call overwrite — a clean repo must not mask
+another's critical finding), writes `<run>/reports/security.md`, records
+the `security.max_severity` artifact.
+
+Then advance. The manifest's `when` predicate decides the rest mechanically:
+severity ≥ threshold → ⟨approve-security⟩ is REQUIRED next (fix-now / waive /
+defer, see `gate.md`); below threshold → the gate is skipped and `pre-pr` is
+next. `bin/harness show` + a refused advance tell you which.

package/.opencode/skills/dev-workflow/steps/triage-request.md

@@ -0,0 +1,15 @@
+# Instruction: ad-hoc request triage (reviewer shape, mode `request-triage`)
+
+A human made a request mid-run. Classify it against the APPROVED plan:
+
+- `IN_SCOPE_BUG` — defect in work this run already did → route to the
+  develop/fixup loop.
+- `IN_SCOPE_AC_MISS` — an approved acceptance criterion isn't met → same.
+- `OUT_OF_SCOPE` — new scope → propose a follow-up work item; NEVER
+  silently merge it into this run.
+- `PLAN_CONFLICT` — contradicts an approved decision → surface both sides
+  to the human; never resolve unilaterally.
+- `DUPLICATE` / `INVALID` — with the evidence.
+
+Verdict + reasoning in the status block; the orchestrator presents it to the
+human — triage never mutates anything.