@glrs-dev/harness-plugin-opencode 1.1.0 → 2.0.0

package/dist/{install-5JKWK6Z4.js → install-6775ZBDG.js}

@@ -3,7 +3,7 @@ import {
   install,
   writeMcpToggles,
   writePluginOption
-} from "./chunk-BWERBERN.js";
+} from "./chunk-6CZPRUMJ.js";
 import "./chunk-VJUETC6A.js";
 export {
   MODEL_PRESETS,

package/dist/paths-WZ23ZQOV.js

@@ -0,0 +1,18 @@
+import {
+  getCurrentScopePath,
+  getPilotConfigPath,
+  getPilotDir,
+  getPlanArtifactPath,
+  getRepoFolder,
+  getScopeArtifactPath,
+  getStateDbPath
+} from "./chunk-OYRKOEXK.js";
+export {
+  getCurrentScopePath,
+  getPilotConfigPath,
+  getPilotDir,
+  getPlanArtifactPath,
+  getRepoFolder,
+  getScopeArtifactPath,
+  getStateDbPath
+};

package/dist/skills/code-quality/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: code-quality
+description: Four principles for autonomous code quality — think before coding, simplicity first, surgical changes, goal-driven execution. Load this skill when planning, building, or reviewing any non-trivial change. Derived from observed patterns in AI-agent-authored PRs where review feedback clustered around wrong assumptions, overcomplication, scope creep, and missing failure-mode coverage.
+---
+
+# Code Quality Principles
+
+Four principles that prevent the most common classes of defects in AI-agent-authored code. Each principle applies at every pipeline phase, but the enforcement actions differ by phase. Load the rule file for your current role.
+
+These principles are derived from empirical analysis of recurring review feedback on agent-authored PRs. The top defect categories — wrong assumptions at system boundaries, overcomplicated implementations, unplanned side-effects, and happy-path-only coverage — are all preventable by applying the right check at the right phase.
+
+## The four principles
+
+1. **Think Before Coding** — Don't assume. Surface ambiguity, verify cross-boundary names, present tradeoffs, stop when confused.
+2. **Simplicity First** — Minimum code that solves the problem. No speculative features, no single-use abstractions, no "flexibility" that wasn't requested.
+3. **Surgical Changes** — Touch only what you must. Every changed line traces to the plan. Minimize blast radius on security-sensitive files.
+4. **Goal-Driven Execution** — Define success criteria with real verify commands. Enumerate failure modes. Test the error paths, not just the happy path.
+
+## Phase-specific rules
+
+Each rule file applies all four principles through the lens of a specific pipeline phase. Load the one that matches your current role:
+
+1. [`rules/gap-analysis.md`](rules/gap-analysis.md) — For `@gap-analyzer`. Surface hidden assumptions, missing failure modes, naming mismatches, and overscoped plans before the draft is written.
+
+2. [`rules/planning.md`](rules/planning.md) — For `@plan` and `@plan-reviewer`. Verify every cross-boundary identifier. Reject plans that exceed what the goal requires. Require failure-mode coverage in acceptance criteria.
+
+3. [`rules/building.md`](rules/building.md) — For `@build`. Enforce surgical changes. Verify names before using them. Flag unplanned edits. Write failure-path tests before happy-path code.
+
+4. [`rules/review.md`](rules/review.md) — For `@qa-reviewer` and `@qa-thorough`. Verify failure-path coverage in the diff. Grep-confirm cross-boundary string literals. Reject diffs with unplanned scope.
+
+## When to load this skill
+
+Any non-trivial change — defined as any plan with 3+ file-level changes, or any change touching a system boundary (API contract, database schema, config/security file, cross-service integration).
+
+Do NOT load for trivial work (typo fixes, single-file renames, doc-only changes). The overhead isn't worth it.
+
+## Observable outcomes
+
+These are the signals that the principles are working:
+
+- Fewer naming mismatches at system boundaries (cross-boundary identifiers are grep-confirmed before use)
+- Smaller, more focused PRs (plans that exceed ~15 files get split or justified)
+- Zero unplanned changes in diffs (every changed line traces to the plan)
+- Failure-mode coverage in acceptance criteria (negative tests exist for medium+ risk changes)
+- Narrower security-config changes (specific paths instead of broad globs)

package/dist/skills/code-quality/rules/building.md

@@ -0,0 +1,125 @@
+# Code Quality — Building Phase
+
+You are the build agent. Your job is to execute the plan without introducing the defect classes that dominate agent-authored PRs. These four principles tell you what to enforce during execution.
+
+## Principle 1: Think Before Coding
+
+At the building phase, this means verifying every assumption the plan makes before writing code against it. The plan is your spec, but specs can be wrong.
+
+### Before editing each file
+
+- **Verify cross-boundary identifiers.** Before using any identifier from the plan that references an existing system concept (database column, enum value, API field, Temporal signal name, config key, registry target), grep the codebase for the canonical form. If the plan says `"eligibility_request"` but the codebase uses `"eligibilityRequest"`, the plan is wrong — STOP and report.
+- **Verify behavioral assumptions.** If the plan says "this function returns X" or "this endpoint accepts Y," read the actual implementation before writing code that depends on it. Don't trust the plan's description of existing behavior — verify it.
+- **Check for domain-specific safety constraints.** Before modifying a Temporal workflow, check whether the change requires a `patched()` guard. Before modifying a database migration, check whether a down() path is needed. Before modifying an auth flow, check whether the change affects token scoping. These constraints aren't always in the plan — they're in the codebase's conventions.
+
+### When you find a mismatch
+
+Don't silently work around it. STOP and report:
+
+> Plan says `<identifier>` but codebase uses `<canonical form>`. Which is correct?
+
+This is a design-change signal, not a cosmetic threshold. The plan needs to be updated before you proceed.
+
+### Anti-pattern: the trusting builder
+
+Plan says: register target as `"eligibility_request"`. Builder writes code and tests using that name. Tests pass (builder wrote the fixtures). Production breaks because the registry uses `"eligibilityRequest"`. The builder trusted the plan instead of verifying.
+
+**Your action:** Grep for every cross-boundary identifier before first use. One grep per identifier. This takes seconds and prevents the most common class of runtime failure.
+
+## Principle 2: Simplicity First
+
+At the building phase, this means writing the minimum code that satisfies each plan item — not the most comprehensive code you can generate.
+
+### During implementation
+
+- **Fight the generation instinct.** Your training data is full of comprehensive, well-documented, heavily-abstracted code. That's not what the plan asked for. Write the specific thing the plan describes, in the fewest lines that are correct and readable.
+- **No speculative error handling.** Handle the error cases the plan specifies. Don't add error handling for scenarios the plan doesn't mention — that's scope creep disguised as robustness.
+- **No premature abstraction.** If the plan says "add a function that does X," write a function that does X. Don't write a class hierarchy, a factory, or a strategy pattern unless the plan explicitly calls for it.
+- **Prefer inline over extracted.** If a helper function would be called once, inline it. If a constant would be referenced once, inline it. Extraction is warranted at 2+ call sites.
+- **Match the plan's complexity level.** If the plan describes a 50-line change, don't produce 200 lines. If you find yourself writing significantly more code than the plan implies, that's a signal to STOP and check whether you're overcomplicating.
+
+### Anti-pattern: the comprehensive implementation
+
+Plan says: "add env-var toggle for mock client." Builder produces: a resolver pattern with dynamic imports, a factory function, a type-safe config schema, and conditional module loading — 200 lines for what could be a 20-line `if (process.env.USE_MOCK)` check. The extra complexity introduces a bug where mock data is unconditionally imported in production.
+
+**Your action:** Before writing, estimate the line count the plan implies. If your implementation exceeds 2x that estimate, pause and simplify.
+
+## Principle 3: Surgical Changes
+
+This is your primary principle. The build agent's #1 failure mode is unplanned side-effects.
+
+### After every file edit, check
+
+1. **Is this file in `## File-level changes`?** If not → STOP and report. Do not silently expand scope. Do not add files to the plan yourself unless the expansion is ≤2 files and directly required by a planned change.
+
+2. **Does every changed line trace to a plan item?** Review your own diff mentally. If any line is "while I'm here" cleanup, adjacent-code improvement, or style normalization — revert it. Your diff should contain zero surprises.
+
+3. **Did I modify a security-sensitive file?** Scanner allowlists, auth configs, CORS settings, `.env` templates, CI workflow files, permission manifests. If yes:
+   - Is the change the narrowest possible? Could I use a specific file path instead of a glob pattern?
+   - Does the plan explicitly mention this change? If not → STOP and report.
+   - Would a reviewer looking at this diff ask "why was this changed?" If yes, the change needs justification.
+
+4. **Did I touch imports/exports in a file I'm editing?** Only remove imports YOUR changes made unused. If a pre-existing import was already unused, leave it. Only add exports the plan requires. Don't "clean up" the import block.
+
+5. **Am I matching existing style?** Read the surrounding code before writing. Match indentation, naming conventions, comment style, error handling patterns, and test structure — even if you'd do it differently. Consistency within a file matters more than your preference.
+
+### Security-sensitive file patterns
+
+These files require extra scrutiny. Any change must be the narrowest possible and explicitly justified by the plan:
+
+- `**/.*rc*`, `**/.eslintrc*`, `**/.secretlintrc*` — linter/scanner configs
+- `**/allowlist*`, `**/whitelist*`, `**/ignore*` — exclusion lists
+- `**/.env*`, `**/env.*.ts` — environment configs
+- `**/auth/**`, `**/security/**`, `**/crypto/**` — auth/security modules
+- `**/*.workflow.ts`, `**/workflows/**` — Temporal workflows (replay safety)
+- `**/migrations/**`, `**/*.sql` — database migrations
+- `**/.github/workflows/**` — CI pipelines
+
+### Anti-pattern: the expedient side-effect
+
+The builder needs mock data for tests. The PHI scanner flags the mock file. Instead of adding the specific file path (`test/mocks/mock-pms-client.ts`) to the allowlist, the builder adds `**/mock-*.ts` — disabling PHI detection for any matching file across the entire repo. The test passes. The security hole ships.
+
+**Your action:** When you need to modify a security-sensitive file, use the most specific pattern possible. If the plan doesn't specify the exact pattern, STOP and ask — don't improvise with a broad glob.
+
+### Anti-pattern: the stale-data forward
+
+Plan says: "forward the RCM enabled setting to the API." Builder forwards the entire `settings.solutions` object instead of the single `rcmEnabled` field. A concurrent write to any other field in the object gets overwritten by the stale snapshot.
+
+**Your action:** When the plan says "forward X," forward exactly X — not the parent object, not a snapshot, not a superset. Read the existing forwarding pattern in the codebase and match it.
+
+## Principle 4: Goal-Driven Execution
+
+At the building phase, this means working in TDD order and verifying each step — including failure paths.
+
+### Execution order
+
+For each acceptance criterion in the plan-state fence:
+
+1. **Write the test(s) first.** The `tests:` field names the test cases. Write them. They should fail (the implementation doesn't exist yet).
+2. **Write the implementation.** Make the tests pass.
+3. **Run the verify command.** The `verify:` field is the acceptance gate. If it exits non-zero, fix and re-run.
+4. **Check for failure-path coverage.** If the plan includes negative tests (it should for medium+ risk changes), write those too. If the plan doesn't include negative tests but the change has obvious failure modes, write them anyway and note the addition in your return payload.
+
+### Cross-boundary verification
+
+After implementing code that uses a string literal referencing a domain concept:
+
+- **Grep for the canonical form.** `grep -r "eligibilityRequest" src/` to confirm the registry key exists.
+- **Check casing.** If your code uses `"eligibility_request"` and the grep returns `"eligibilityRequest"`, you have a bug — even though TypeScript is happy.
+- **Check plurality.** `"credentials"` vs `"credential"`, `"member"` vs `"members"` — these mismatches pass type checks and fail at runtime.
+
+### Anti-pattern: the happy-path-only builder
+
+Plan says: "add route validation for Tailscale subnet routes." Builder implements validation for `dev`, `sbx`, and `prod`. For an unknown stack value, the validation returns an empty set — which the approval logic interprets as "all routes approved." The builder didn't write a test for the unknown-stack case because the plan's acceptance criteria only covered known stacks.
+
+**Your action:** If the plan's acceptance criteria are all positive and the change has obvious failure modes, write the negative test anyway. Note it in your return payload as a plan expansion. Better to over-test than to ship a fail-open bug.
+
+### Temporal workflow safety (domain-specific)
+
+If you're modifying a Temporal workflow function body:
+
+- **Never delete a workflow branch.** Only add new ones behind `patched()` guards.
+- **The old code path stays behind `!patched(patchId)`.** In-flight executions replay against the old history. Removing the old branch causes a determinism violation.
+- **Test with replay fixtures.** If the plan includes workflow changes, verify that existing replay tests still pass.
+
+This is the single highest-severity domain-specific constraint. A determinism violation breaks in-flight production workflows silently.

package/dist/skills/code-quality/rules/gap-analysis.md

@@ -0,0 +1,92 @@
+# Code Quality — Gap Analysis Phase
+
+You are the gap-analyzer. Your job is to find what's missing before the plan is written. These four principles tell you what to look for.
+
+## Principle 1: Think Before Coding
+
+This is your primary principle. The gap-analyzer exists to catch wrong assumptions before they propagate into the plan.
+
+### What to check
+
+- **Cross-boundary identifiers.** For every identifier the planner references — database column, enum value, API field, Temporal signal name, config key, registry target — grep the codebase for the canonical form. The #1 source of runtime failures that pass type checks is a naming mismatch at a system boundary. Snake_case vs camelCase is the most common variant.
+- **Assumed behaviors.** When the planner says "X will call Y" or "Z returns a list of W," verify by reading the actual code. Don't trust documentation — it drifts. Read the implementation.
+- **Silent interpretation choices.** If the user's request is ambiguous and the planner picked one interpretation without stating the alternative, surface the alternative. "The planner assumed X, but Y is also a valid reading."
+- **Missing context.** If the planner references a system the gap-analyzer hasn't seen evidence of (a service, a table, a config file), flag it. "Planner references `eligibility_request` table but I found `eligibilityRequest` in the registry — which is canonical?"
+
+### Anti-pattern to catch
+
+The planner reads a doc that says "eligibility requests use snake_case keys." The planner writes a plan using snake_case. The actual runtime registry uses camelCase. If you don't catch this, the builder will write code and tests that both use the wrong name — tests pass, production breaks.
+
+**Your action:** For every cross-boundary name in the plan draft, report whether you confirmed it or couldn't. Use `serena_find_symbol` for code symbols, `grep` for string literals and config keys.
+
+## Principle 2: Simplicity First
+
+Surface overscoping before the plan is written. It's cheaper to cut scope now than to review a 13,000-line PR later.
+
+### What to check
+
+- **Goal-to-file ratio.** If the planner's understanding implies 15+ files for a goal that could be achieved with 5, flag it. "The goal is 'add a config toggle' but the current understanding implies an admin UI, audit logging, and settings forwarding — are all of these in scope?"
+- **Single-use abstractions.** If the planner is proposing a generic framework (registry, engine, factory) and there's only one consumer, flag it. "A generic analytics engine is proposed but only one report type exists — consider a specific implementation."
+- **Speculative features.** If the planner's understanding includes features the user didn't ask for, flag them. "User asked for a mock client; planner's understanding includes an env-var toggle and a resolver pattern — confirm these are needed."
+
+### Anti-pattern to catch
+
+The planner receives "add per-org RCM toggle" and scopes it as: migration + model + API endpoint + admin UI + audit logging + settings forwarding + 16 files. The narrower scope — toggle + migration + one API field — would ship the feature with fewer defects.
+
+**Your action:** If the scope seems wider than the goal requires, list the minimum set of changes that would satisfy the goal and ask whether the additional scope is intentional.
+
+## Principle 3: Surgical Changes
+
+At the gap-analysis phase, surgical changes means identifying which existing files will be affected and flagging unintended side-effects before they happen.
+
+### What to check
+
+- **Adjacent code impact.** For each file the planner intends to change, check what else imports from or depends on that file. If a change to `settings.ts` will affect 12 consumers, that's a gap worth surfacing.
+- **Security-sensitive files.** If the planner's scope implies touching a scanner allowlist, auth config, CORS setting, or similar security file, flag it explicitly. "This change will require modifying the PHI scanner allowlist — ensure the plan specifies the narrowest possible pattern."
+- **Config/schema ripple effects.** If the change adds a database column, enum value, or config key, check whether other systems read from the same source. A new column in `member` might need to be excluded from API responses, added to admin endpoints, or handled in export logic.
+
+**Your action:** For each file in the planner's scope, report its inbound dependencies (who imports it) and outbound dependencies (what it imports). Flag any dependency that the planner hasn't accounted for.
+
+## Principle 4: Goal-Driven Execution
+
+At the gap-analysis phase, goal-driven execution means ensuring the plan will have testable success criteria — including failure modes.
+
+### What to check
+
+- **Missing failure modes.** For each file-level change the planner is considering, ask:
+  - What happens on invalid input?
+  - What happens on concurrent access?
+  - What happens when a dependency is unavailable?
+  - What happens when the input data doesn't match the expected schema/casing/format?
+  If the planner hasn't considered these, surface them as gaps.
+- **Happy-path-only acceptance criteria.** If the planner's acceptance criteria are all positive ("X works when Y"), flag the missing negatives. "No acceptance criterion covers what happens when the stack value is unknown — this is how fail-open bugs ship."
+- **Unverifiable criteria.** If a criterion can't be checked by running a command, it's not a real criterion. "Criterion says 'settings are persisted correctly' — what command verifies this?"
+
+### Anti-pattern to catch
+
+The planner writes acceptance criteria for Tailscale route auto-approval: "routes are approved for dev, sbx, and prod stacks." Missing: "unknown stack values produce an error, not an empty approval." The feature works in testing and fails open in production.
+
+**Your action:** For every acceptance criterion, propose the corresponding negative test. "If the positive criterion is 'routes approved for known stacks,' the negative criterion should be 'unknown stacks produce an error.'"
+
+## Output format
+
+Your output should integrate these checks into your standard gap-analysis format:
+
+```
+## Gaps
+
+1. <Gap from any principle>. Why it matters: <one sentence>. Suggested clarifying question: <one sentence>.
+2. ...
+
+## Cross-boundary name verification
+
+| Identifier | Source (plan/doc) | Canonical form (codebase) | Match? |
+|---|---|---|---|
+| ... | ... | ... | ✓ / ✗ / not found |
+
+## Confirmed assumptions
+
+- <Things you checked that DO hold true>
+```
+
+The cross-boundary name table is new — add it whenever the plan references existing system identifiers. This is the single highest-leverage check you perform.

package/dist/skills/code-quality/rules/planning.md

@@ -0,0 +1,96 @@
+# Code Quality — Planning Phase
+
+You are the plan agent or plan-reviewer. Your job is to produce (or validate) a plan that the builder can execute without introducing the defect classes that dominate agent-authored PRs. These four principles tell you what to enforce.
+
+## Principle 1: Think Before Coding
+
+At the planning phase, this means every claim in the plan is grounded in the codebase — not in assumptions, not in documentation that may have drifted, not in pattern-matching from training data.
+
+### For the plan agent
+
+- **Grep-confirm every cross-boundary identifier before writing it into the plan.** Database columns, enum values, API fields, Temporal signal/query names, config keys, registry targets. Use `serena_find_symbol` for code symbols, `grep` for string literals. If you can't confirm the canonical form, put it in `## Open questions` — don't guess.
+- **Cite the source file for every behavioral assumption.** "The webhook fires after finalize" — cite the file and line where that happens. "The settings object is forwarded to the API" — cite the forwarding code. Uncited assumptions become bugs.
+- **Name alternatives you rejected.** If you considered two approaches and picked one, state both in `## Constraints` or inline in the relevant `## File-level changes` entry. The plan-reviewer and builder need to know what you ruled out and why.
+
+### For the plan-reviewer
+
+- **Spot-check at least one cross-boundary identifier per plan.** Pick the identifier that crosses the most boundaries (e.g., a registry key used by both the API and the worker). Grep for it. If the plan uses a different casing or spelling than the codebase, REJECT.
+- **Flag uncited behavioral assumptions.** If the plan says "X calls Y" without citing a file path, that's a gap. The builder will trust the plan and write code against a behavior that may not exist.
+
+### Anti-pattern: the naming mismatch cascade
+
+Plan says: target name is `"eligibility_request"` (snake_case, from a doc). Codebase registry uses `"eligibilityRequest"` (camelCase). Builder writes code and tests using the plan's name. Tests pass (builder wrote the fixtures too). Production breaks because the registry key doesn't match.
+
+**Prevention:** The plan must contain the canonical form, confirmed by grep. The plan-reviewer must spot-check it.
+
+## Principle 2: Simplicity First
+
+At the planning phase, this means the plan's scope matches the goal — no more, no less.
+
+### For the plan agent
+
+- **Every file in `## File-level changes` must trace to `## Goal`.** If you can't explain why a file is there in one sentence that references the goal, it doesn't belong.
+- **No single-use abstractions.** If the plan introduces a generic interface, base class, factory, or registry pattern, there must be 2+ concrete implementations in the plan. One implementation = write the specific thing, not the abstraction.
+- **No speculative features.** Env-var toggles, feature flags, admin UIs, and strategy patterns are scope unless the goal explicitly calls for them. "While we're at it" is not a justification.
+- **Consider splitting.** If the plan exceeds ~15 files or ~1000 lines of estimated changes, ask whether it can be two independently-shippable PRs. Each PR should leave the system in a working state.
+- **Prefer the shorter implementation.** If 200 lines could be 50, the plan should describe the 50-line version. The agent's instinct is to generate comprehensive code — the plan should constrain that instinct.
+
+### For the plan-reviewer
+
+- **Count files vs. goal complexity.** A "add a config toggle" goal with 16 files is a red flag. A "build a new service" goal with 16 files may be appropriate. The ratio matters.
+- **Flag single-use abstractions.** If `## File-level changes` introduces an interface/factory/registry and only one implementation, REJECT with: "Single-use abstraction: `<name>` has only one implementation. Write the specific thing."
+- **Flag "while we're at it" scope.** If a file-level change says "also update X for consistency" or "clean up Y while editing," that's scope creep. REJECT unless `## Goal` explicitly includes it.
+
+### Anti-pattern: the full vertical slice
+
+Goal: "add per-org RCM toggle." Plan: migration + model change + API endpoint + admin UI + audit logging + settings forwarding = 16 files. The settings-forwarding logic snapshots the entire settings object instead of the single field, creating a stale-data overwrite bug. A narrower plan — toggle + migration + one API field — would have shipped the feature with fewer defects.
+
+**Prevention:** The plan-reviewer should ask: "What is the minimum set of files that satisfies the goal?" If the plan has more, each extra file needs explicit justification.
+
+## Principle 3: Surgical Changes
+
+At the planning phase, surgical changes means scoping the plan tightly and flagging files that need careful handling.
+
+### For the plan agent
+
+- **Mark security-sensitive files explicitly.** If the plan touches a scanner allowlist, auth config, CORS setting, `.env` template, or similar security file, set `Risk: high` on that entry and add a note: "Security-sensitive file — builder must use the narrowest possible change."
+- **Specify what NOT to change.** Use `## Non-goals` aggressively. "Do NOT modify `src/auth/session.ts`." "Do NOT refactor the existing report runner." Explicit exclusions prevent the builder from "improving" adjacent code.
+- **Scope config changes precisely.** If the plan requires adding a path to an allowlist, specify the exact path in the plan — not "add the mock file to the allowlist" but "add `test/mocks/mock-pms-client.ts` to `.secretlintrc` allowlist." The builder should not have to decide the pattern.
+
+### For the plan-reviewer
+
+- **Check `## Non-goals` exists and is specific.** A plan without non-goals is a plan that hasn't thought about boundaries. REJECT if missing on any plan with 5+ file-level changes.
+- **Flag missing `Risk:` annotations on security-sensitive files.** If the plan touches an auth, config, or security file and doesn't mark it `Risk: medium` or higher, REJECT.
+
+### Anti-pattern: the broad allowlist
+
+Plan says "add mock file to PHI scanner allowlist." Builder adds `**/mock-*.ts` instead of the specific file path. The broad glob disables PHI detection for any file matching that pattern across the entire repo.
+
+**Prevention:** The plan must specify the exact allowlist entry. The plan-reviewer must verify the entry is specific, not a glob.
+
+## Principle 4: Goal-Driven Execution
+
+At the planning phase, goal-driven execution means writing acceptance criteria that catch failure modes — not just happy paths.
+
+### For the plan agent
+
+- **Every acceptance criterion needs a negative test.** For each `- [ ]` item in the plan-state fence, ask: "What's the corresponding failure case?" If the positive criterion is "routes approved for known stacks," the negative criterion should be "unknown stacks produce an error, not an empty approval."
+- **Enumerate failure modes for `Risk: medium+` changes.** In the `## File-level changes` entry or in `## Test plan`, answer:
+  - What happens on invalid input?
+  - What happens on concurrent access?
+  - What happens when a dependency is unavailable?
+  - What happens when the input data doesn't match the expected schema/casing/format?
+- **Verify commands must be real assertions.** Not `echo done`. Not `test -f file.ts`. A command that fails when the criterion isn't met. The plan-state fence enforces this structurally, but the plan agent must write meaningful commands.
+- **Include cross-boundary verification.** If the plan introduces a string literal that references a domain concept (table name, enum value, signal name), add a verify step that greps for the canonical form. TypeScript catches type mismatches but not string-literal mismatches.
+
+### For the plan-reviewer
+
+- **Check for negative tests.** If every acceptance criterion is positive ("X works when Y") and none are negative ("X fails when Z"), REJECT. Happy-path-only criteria produce happy-path-only implementations.
+- **Check verify commands are meaningful.** If a verify command is `echo done`, `test -f`, or `true`, REJECT. The verify must exercise behavior, not existence.
+- **Check failure-mode coverage on `Risk: medium+` entries.** If a high-risk file-level change has no corresponding failure-mode test in `## Test plan` or `## Acceptance criteria`, REJECT.
+
+### Anti-pattern: the happy-path-only plan
+
+Acceptance criteria: "Tailscale routes are approved for dev, sbx, and prod stacks." Missing: "Unknown stack values produce an error." The builder implements exactly what the plan says. The feature works in testing (which only uses known stacks) and fails open in production.
+
+**Prevention:** The plan must include negative acceptance criteria for every medium+ risk change. The plan-reviewer must verify they exist.

package/dist/skills/code-quality/rules/review.md

@@ -0,0 +1,104 @@
+# Code Quality — Review Phase
+
+You are the QA reviewer (fast or thorough variant). Your job is to catch the defect classes that survive planning and building. These four principles tell you what to look for in the diff.
+
+## Principle 1: Think Before Coding (verify assumptions survived)
+
+The plan made assumptions. The builder may have trusted them without verifying. Your job is to catch the ones that slipped through.
+
+### What to check
+
+- **Cross-boundary string literals.** For every new string literal in the diff that references a domain concept (table name, enum value, signal name, config key, registry target, Temporal workflow/signal/query name), grep the codebase for the canonical form. If the diff uses `"eligibility_request"` but the codebase uses `"eligibilityRequest"`, that's a FAIL — even if tests pass (the tests probably use the same wrong name).
+- **Casing and plurality mismatches.** Specifically check:
+  - snake_case vs camelCase vs PascalCase
+  - Singular vs plural (`"credential"` vs `"credentials"`, `"member"` vs `"members"`)
+  - Abbreviated vs full (`"req"` vs `"request"`, `"org"` vs `"organization"`)
+- **Behavioral assumptions in the code.** If the diff contains a comment like "// this returns X" or "// called after Y," spot-check one or two of these by reading the referenced code. If the comment is wrong, the code is probably wrong too.
+- **Temporal workflow changes.** If the diff modifies any file matching `**/*.workflow.ts` or `**/workflows/**`:
+  - Check for `patched()` guards on any removed or modified branch.
+  - Verify the old code path is preserved behind `!patched(patchId)`.
+  - If a workflow branch was deleted without a patch guard, that's a FAIL — determinism violation.
+
+### Output format for naming mismatches
+
+```
+FAIL
+
+1. src/analytics/engine.ts:42 — String literal "eligibility_request" does not match canonical form "eligibilityRequest" (found in src/registry/targets.ts:15). Runtime key mismatch.
+```
+
+## Principle 2: Simplicity First (verify scope matches goal)
+
+The plan may have been well-scoped, but the builder may have expanded it. Or the plan itself may have been overscoped and the plan-reviewer missed it. You're the last line of defense.
+
+### What to check
+
+- **File count vs. goal complexity.** Read the plan's `## Goal`. Count the files in the diff. Does the ratio make sense? A "add a config toggle" goal with 16 changed files is suspicious. A "build a new service" goal with 16 files may be appropriate.
+- **Single-use abstractions in the diff.** If the diff introduces an interface, base class, factory, or registry pattern, check whether it has more than one implementation in the diff. If not, FAIL with: "Single-use abstraction: `<name>` has only one implementation in this diff. Simplify to the concrete implementation."
+- **Speculative code.** If the diff contains code paths that aren't exercised by any test in the diff and aren't required by the plan, that's dead-on-arrival code. FAIL with the specific file and line.
+- **Unnecessary complexity.** If a function in the diff could be written in significantly fewer lines without losing correctness or readability, note it. This isn't an auto-FAIL, but it's worth flagging: "src/resolver.ts:15-80 — 65-line resolver pattern could be a 10-line conditional import. Consider simplifying."
+
+## Principle 3: Surgical Changes (verify diff discipline)
+
+This is your primary enforcement principle. The QA reviewer exists to catch unplanned changes.
+
+### What to check
+
+- **Plan drift (AUTO-FAIL).** For each modified file in the diff, verify it appears in the plan's `## File-level changes`. A modified file NOT listed in the plan is AUTO-FAIL. Report as: `Plan drift: <path> modified but not in ## File-level changes`.
+- **Scope creep (AUTO-FAIL).** For each untracked file (from `git status`) not in the plan, run `git log --oneline -- <file>` to check if it's pre-existing. No prior commits AND not in the plan → FAIL with: `Scope creep: <path> untracked and not in plan`.
+- **Security-sensitive file changes.** If the diff modifies any of these file patterns, apply extra scrutiny:
+  - Scanner/linter configs (`.*rc*`, `allowlist*`, `ignore*`)
+  - Auth/security modules (`auth/**`, `security/**`, `crypto/**`)
+  - Environment configs (`.env*`, `env.*.ts`)
+  - CI pipelines (`.github/workflows/**`)
+  - Database migrations (`migrations/**`, `*.sql`)
+  - Temporal workflows (`*.workflow.ts`, `workflows/**`)
+
+  For each, check:
+  - Does the plan explicitly mention this file? If not → FAIL.
+  - Is the change the narrowest possible? If a glob pattern was added where a specific path would do → FAIL with: `Overly broad pattern in <file>: "<glob>" should be "<specific-path>"`.
+- **"While I'm here" changes.** If the diff contains style fixes, import reordering, comment updates, or dead-code removal in lines adjacent to (but not part of) the planned change, FAIL with: `Unplanned adjacent change in <file>:<line> — not in plan`.
+- **Pre-existing code modifications.** If the diff removes or modifies code that existed before this branch and the plan doesn't mention it, FAIL. The builder should only remove orphans its own changes created.
+
+## Principle 4: Goal-Driven Execution (verify failure-path coverage)
+
+The builder may have implemented the happy path perfectly and skipped every failure mode. Your job is to catch that.
+
+### What to check
+
+- **Failure-path test coverage.** For each file-level change with `Risk: medium` or higher in the plan:
+  - Does the diff include at least one test for an error/failure case? Not just "valid input produces correct output" but "invalid input produces an error."
+  - If the change adds a new API endpoint, does the diff include a test for an error response (400, 404, 500)?
+  - If the change adds validation logic, does the diff include a test for invalid input?
+  - If the change modifies a config/security file, does the diff include a test that verifies the restriction works?
+  If no failure-path tests exist for a medium+ risk change → FAIL with: `Missing failure-path test for <file> (Risk: <level>). No error/edge-case test found in diff.`
+
+- **Fail-open patterns.** Specifically look for:
+  - Validation functions that return empty/default on unknown input instead of throwing
+  - Switch/if-else chains with no default/else that handles unexpected values
+  - Try-catch blocks that swallow errors silently (empty catch, catch that only logs)
+  - Config lookups that fall back to permissive defaults on missing keys
+  Report each as: `Potential fail-open: <file>:<line> — <description>. Unknown input falls through to <permissive behavior>.`
+
+- **Verify command execution.** Run every verify command from the plan-state fence. Trust nothing — not the `[x]` checkboxes, not the builder's narrative. If a verify command exits non-zero → FAIL.
+
+- **Cross-boundary contract verification.** For every new string literal in the diff that references a domain concept, grep for the canonical form. This overlaps with Principle 1's check — do it anyway. It's the single highest-leverage check and takes seconds.
+
+### Anti-pattern: the invisible fail-open
+
+Diff adds a function `validateStack(stack: string)` that returns `approvedRoutes` for known stacks and `[]` (empty array) for unknown stacks. The caller interprets `[]` as "no routes to reject" → approves everything. No test covers the unknown-stack case. The QA reviewer who doesn't check for fail-open patterns misses it.
+
+**Your action:** For every validation/filtering function in the diff, trace what happens when the input doesn't match any expected value. If the result is permissive (empty set, null, undefined, default-allow), that's a fail-open candidate. FAIL unless a test explicitly covers that case.
+
+## Summary: the four checks in execution order
+
+Run these in order during your review:
+
+1. **Plan drift + scope creep** (Principle 3) — fast, mechanical, AUTO-FAIL
+2. **Security-sensitive file scrutiny** (Principle 3) — check narrowness of patterns
+3. **Cross-boundary name verification** (Principle 1) — grep string literals against canonical forms
+4. **Failure-path coverage** (Principle 4) — check for negative tests on medium+ risk changes
+5. **Simplicity check** (Principle 2) — flag single-use abstractions and speculative code
+6. **Verify command execution** (Principle 4) — run every verify command from the fence
+
+Items 1-2 are AUTO-FAIL. Items 3-4 are FAIL if the issue is confirmed. Items 5 are advisory (flag but don't auto-fail unless egregious). Item 6 is FAIL on non-zero exit.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@glrs-dev/harness-plugin-opencode",
-  "version": "1.1.0",
+  "version": "2.0.0",
   "description": "Opinionated OpenCode agent harness — PRIME, plan, build, QA, skills, MCP wiring, hashline editing.",
   "type": "module",
   "main": "./dist/index.js",