--- name: verified-development description: Run a risk-adaptive, evidence-backed implementation workflow that automatically captures, deduplicates, repairs, and regression-tests discovered problems until a fresh dual review certifies the current diff. Use when the user explicitly invokes $verified-development in Codex, /verified-development in OpenCode, or requests requirement-driven implementation with verification. Do not use for read-only reviews, explanations, or simple factual questions. metadata: opencode/autoinvoke: "false" --- # Verified Development Implement the requested change and automatically repair every in-scope problem discovered along the way. Converge through a cumulative finding ledger, root-cause closure, focused evidence reuse, two fresh final reviewers, and a deterministic evaluator. Never create, replace, or edit a target project's `AGENTS.md` unless the user separately requests that exact change. ## Release and rollout status Plugin release `0.6.0` uses schemaVersion `3` as the production main path. The bundled evaluator exports `WORKFLOW_VERSION` `0.6.0`. Every production manifest must set `workflow.pluginVersion` to that exported value and `schemaVersion` to `3`. Schema `2` remains readable only as a migrate-from skeleton. Do not certify a schema `2` manifest as the production result of a `0.6.0` run. ## Non-negotiable contract - Preserve the original user request verbatim in a temporary evidence artifact outside the target repository. - Read and obey all applicable repository instructions without modifying them. - Keep one primary writer. Reviewers and failure-diagnosis agents are read-only. - Preserve unrelated user changes and avoid external or destructive actions beyond the user's authority. - Pin `workflow.pluginVersion` to the bundled production evaluator's exported `WORKFLOW_VERSION` (`0.6.0` in this release) for the whole run. Never silently switch workflow or schema versions mid-run. - Keep every discovered finding, generalized invariant, root cause, and regression check in the cumulative ledger. A stale verdict may be discarded; learned evidence may not. - Use exactly one final status: `PASS`, `FAIL`, or `UNVERIFIED`. - Use `PASS` only when the bundled evidence evaluator returns `PASS` for the current diff snapshot. - Use `FAIL` for a failed requirement/check that is still effective, or an open blocking/important defect confirmed by target-bound evidence. A raw defect claim or an un-attributed check failure is not permission to repair blindly. - Use `UNVERIFIED` when critical evidence is missing, a reviewer inherited implementation context, the diff changed after review, or an external dependency prevents proof. - A skipped critical check is `UNVERIFIED`, never `PASS`. - Never describe `UNVERIFIED` work as complete, fully fixed, safe to merge, or equivalent wording. ## 1. Establish the evidence contract 1. Inspect repository instructions, status, structure, build metadata, CI, nearby tests, and the complete base diff. 2. Read [references/risk-and-evidence.md](references/risk-and-evidence.md) completely. 3. Classify the change as `normal` or `high`. Treat migrations, destructive lifecycle transitions, billing, authorization, external provider state, database writes, concurrency/leases, queues/retries/timers, multi-tenant data, and production rollout as high risk. 4. Create a numbered acceptance ledger containing: - the user's observable requirements; - behavior that must remain unchanged; - explicit non-goals and compatibility constraints; - risk-derived safety, liveness, isolation, and consistency invariants within the selected risk classes; - planned evidence for every item. 5. Create the production evidence manifest as schemaVersion `3` outside the target repository. Probe the environment, capture a snapshot, write the acceptance ledger, then migrate any schema-2 skeleton into schema 3 and keep only the schema 3 file: ```text node /scripts/evidence-gate.mjs probe-environment node /scripts/evidence-gate.mjs snapshot --repo --base --environment-descriptor node /scripts/evidence-gate.mjs migrate --manifest --environment-descriptor --output ``` Set `autoRepair: true`, start cycle `0`, and record `workflow.pluginVersion: "0.6.0"` on the schema 3 manifest. Do not use a schema 2 file as the production artifact. Keep the probe descriptor and a trusted registry (reviewer sessions, later evidence bindings) beside the manifest, and pass both on every later `next` and `evaluate`. 6. Capture the initial Git snapshot: ```text node /scripts/evidence-gate.mjs snapshot --repo --base --environment-descriptor ``` Do not reduce a system invariant to one example. “Page 2 contains a running record” is one counterexample class for, not a substitute for, “any authoritative positive liveness evidence prevents destructive cleanup.” ## 2. Analyze and implement 1. Trace entry points, callers, state transitions, persistence, retries, failure handling, and tests before editing. 2. For high-risk changes, build a counterexample matrix covering applicable combinations of normal responses, stale evidence, malformed responses, transient errors, retries/backoff, restart windows, concurrency, pagination, and partial persistence. 3. Add a failing test for each changed observable behavior when a usable test surface exists; confirm it fails for the expected reason. 4. Implement the smallest coherent change satisfying the acceptance ledger and risk invariants. 5. Inspect the full diff for accidental edits, generated noise, secrets, debug code, skipped checks, test weakening, and scope expansion. ## 3. Run the test gate Read [references/test-gate.md](references/test-gate.md) completely before the first test run. - Run focused tests before broader project-native checks. - Record exact commands, outcomes, criticality, risk tags, useful evidence, and the evidence diff digest. - Prove database-test isolation before running a test that can write shared state. - Classify every failure before editing. - Turn each blocking or important finding into a generalized invariant, sibling-counterexample matrix, and passing critical regression check before resolving it. - After a change, rerun focused and affected checks. Reuse unaffected passing evidence only with concrete impact analysis recorded in `reuse`. - Recapture the snapshot after every code or test change. Mark both audit verdicts stale, but retain their findings and derived knowledge. ## 4. Run both evidence gates Read [references/requirement-gate.md](references/requirement-gate.md) completely before auditing. Only start certification when the snapshot is stable, all blocking/important ledger findings are resolved, and critical checks pass. Run exactly two review agents against the same digest: 1. **Contract gate** — proves the acceptance ledger and preservation constraints. 2. **Adversarial gate** — independently searches changed call paths for counterexamples, regressions, unsafe assumptions, and missing tests. When subagent tools are available, this skill explicitly authorizes exactly two review agents. Read [references/runtime-adapters.md](references/runtime-adapters.md), create two new clean reviewer sessions using the applicable runtime mapping, and send only the sanitized evidence packet required by the gate. In Codex, use a clean context such as `fork_turns: "none"`; in OpenCode, use new Task child sessions and record their returned session identifiers as `reviewerThreadId`. Start them concurrently when supported, or sequentially without sharing results when the runtime exposes only blocking Task calls. Never send implementation commentary, the implementer's verdict, the other reviewer's output, prior suspected findings, or the expected verdict. Wait for both raw outputs before repairing anything. For high-risk work, two distinct fresh isolated reviewers are required for `PASS`. If isolation or a second reviewer is unavailable, continue useful testing but finish as `UNVERIFIED`. After any correction, create two new reviewer agents; do not continue prior audit threads. ## 5. Capture findings and choose the next action Before repair, normalize every gate finding into the cumulative ledger. Fresh reviewers may use different names for the same defect; identity is a parent-owned semantic decision, not raw-string equality: - assign a stable `id`, canonical semantic `fingerprint`, and canonical `rootCauseId`; - deduplicate by violated property, decision boundary, trigger class, and reproduced consequence—not merely reviewer wording; - preserve every differing raw name in `sourceFingerprints`, `rootCauseAliases`, or `sourceInvariantIds`, with concrete `dedupeEvidence` explaining the merge; - record the linked canonical `invariantId`, generalized invariant, union of sibling counterexamples/evidence, occurrence count, first/last cycle, and regression check IDs; - mark an earlier resolved finding as reopened instead of creating a duplicate; - preserve raw gate output separately and verbatim. The schemaVersion 3 path classifies each finding as exactly one of: - `confirmed-defect`: a defect confirmed by a current, target-bound dynamic execution or authoritative static adjudication; - `needs-validation`: a concrete defect claim whose evidence is not yet sufficient; - `coverage-gap`: a selected risk class is missing a required passing evidence tag; - `scope-candidate`: a new property on a current changed call path that requires a scope decision; - `residual-risk`: a disclosed risk already proven outside this task by a current rejected scope decision or matching exclude policy. For raw `confirmed-defect`, `needs-validation`, and `scope-candidate` claims, require `claimAdmission` with a current `requirement | risk-class | changed-call-path` surface, resolvable non-empty `sourceRefs`, a concrete trigger, and at least one proposed validation method. Admission makes the claim specific and schedulable; it does not prove the claim. Invalid admission is a gate protocol error. Evidence insufficiency never becomes residual risk. Residual basis is independently validated. A raw residual must reference either an existing rejected `scopeDecisionId` whose subject/property/policy/path match, or a current `exclusionPolicyId` whose `effect: exclude` and `appliesTo` match the finding. Invalid raw basis requires `REQUEST_GATE_CORRECTION`; invalid ledger basis is `INTERNAL_INCONSISTENCY`. A new unlisted property is always a `scope-candidate`, not a residual shortcut. Then run: ```text node /scripts/evidence-gate.mjs next --manifest --environment-descriptor --registry ``` Follow the returned production action exactly. The deterministic action is `{kind, targetIds}` and priority is strict: parent integrity and terminal short-circuits, snapshot refresh, one field correction, finding capture, static adjudication, validation, recurrence redesign, repair, evidence gathering, scope decision, authorization/terminal handling, contextual recertification, certification, then completion. The complete action meanings are: - `REFRESH_SNAPSHOT` — recapture the live snapshot and invalidate stale gate verdicts. - `INTERNAL_INCONSISTENCY` — fail closed on parent-owned schema, reference, binding, attempt-chain, transaction, or terminal corruption. - `REQUEST_GATE_CORRECTION` — give the source gate/static slot its one original-thread field-correction opportunity. - `CAPTURE_FINDINGS` — normalize and deduplicate all raw gate findings before editing. - `ADJUDICATE_STATIC_PROOF` — obtain two independent `static-a`/`static-b` decisions for an eligible static artifact. - `VALIDATE_FINDING` — execute the finite evidence plan for a concrete claim or attribute a bare requirement/check failure. - `ROOT_CAUSE_REDESIGN` — replace the repeated repair strategy with a coherent boundary/state-model redesign, extend the counterexample matrix, and continue automatically. - `REPAIR` — batch all currently open in-scope findings by root cause, repair them, and add regression evidence. - `GATHER_EVIDENCE` — run missing, affected, or risk-required checks. - `SCOPE_DECISION` — resolve one scope candidate against the frozen task policy or explicit user decision. - `NEED_AUTHORIZATION` — request only an allowed, fully bound user choice after evidence is exhausted. - `REPORT_UNVERIFIED` — persist or idempotently return a structured `TerminalResult`; it is not `COMPLETE`. - `RECERTIFY_WITH_CONTEXT` — replace only the context-insufficient gate with a fresh attempt using structured missing-context references. - `CERTIFY` — move to a stable digest and run two fresh blind gates. - `COMPLETE` — report the evaluator-certified result. For schemaVersion 3, `targetIds` are sorted UTF-8 locator strings. Run-level `REFRESH_SNAPSHOT`, `REPORT_UNVERIFIED`, and `COMPLETE` use `[]`; the fail-closed fallback may also return empty targets. Other actions must identify their objects: `gate:`, `attempt:`, `raw-finding:#`, `finding:`, `requirement:`, `check:`, `plan:`, or `transaction:`. Static adjudication, scope decision, root-cause redesign, and contextual recertification process only the sorted first target; `REPAIR` and finding capture return all matching targets. Never guess targets from prose. The dispatcher must bind every current snapshot, execution, EvidenceBinding, gate, waiver, decision, transaction, and terminal result to both `diffDigest` and `environmentFingerprint`. The latter is the `env-v1:` RFC 8785 JCS/SHA-256 hash of the trusted runner's normalized `EnvironmentDescriptorV1`; reviewer/LLM self-reports are not trusted. Execution proves a command ran; only a controller-created EvidenceBinding proves what finding, plan/check, digest, and environment it supports. ## 6. Cumulative repair loop The repair loop has no arbitrary cycle or time cap. Its progress measure is the cumulative ledger and its strategy changes. A cycle is one stable candidate digest plus the findings/review state for that candidate; it is not a log entry for every transient red-test edit. After a repair batch changes code or tests, recapture the snapshot, advance to a new cycle before fresh review, and retain earlier cycle records. 1. Wait for all active checks/reviewers in the cycle. 2. Capture and deduplicate all findings before choosing repairs. 3. Repair root causes in batches; do not patch one review message while another reviewer is still running. 4. Convert every repair into generalized regression evidence that covers sibling counterexamples. 5. Record the new stable digest and cycle transition: new, resolved, reopened, and still-open canonical finding IDs. 6. If a finding reopens or the same important root cause appears in another cycle, automatically switch to `root-cause-redesign`; record the canonical root causes in `redesignRootCauseIds` and the changed model/boundary plus expanded counterexample evidence in `strategyEvidence`. 7. Run `next` again and continue until it returns `COMPLETE` or a structured `REPORT_UNVERIFIED` terminal. A v3 external/authority blocker must be consumed by the authorization or TerminalResult path, not left as an informal stop. Ask the user only when a product decision is missing, new authority is required, a destructive/external action is needed, or the same external condition blocks meaningful progress for three consecutive cycles. Never stop merely because review found another in-scope bug. Never obtain green evidence by deleting, skipping, weakening, or broadly mocking a valid test. ## 7. Evaluate deterministically For certification, set `workflow.phase` to `certification`, record both fresh gate outputs for the current digest, set `codeChangedAfterGates: false`, and run: ```text node /scripts/evidence-gate.mjs evaluate --manifest --environment-descriptor --registry ``` The production evaluator checks the live digest, pinned `WORKFLOW_VERSION`, cumulative finding and cycle consistency, root-cause strategy escalation, requirement states, failed or skipped checks, impact-based evidence reuse, risk-required tags, reviewer isolation, distinct high-risk reviewers, stale gates, uncertainties, and unresolved findings. - Exit `0`: `PASS`. - Exit `1`: `FAIL`. - Exit `2`: `UNVERIFIED`. - Exit `3`: invalid evidence or invocation. Do not manually upgrade the evaluator result. Any code or test change after review invalidates both verdicts and requires a new cycle, affected evidence, and two fresh reviews. It does not erase prior findings, invariants, regression checks, or root-cause history. ## 8. Report the result Return: 1. `STATUS: PASS | FAIL | UNVERIFIED` exactly matching the evaluator. 2. What changed. 3. Acceptance and invariant evidence. 4. Exact tests/checks and any justified evidence reuse. 5. Final gate verdicts and evaluated digest. 6. Convergence history: cycles, new/resolved/reopened findings, root-cause redesigns, and remaining open IDs. 7. Remaining uncertainties, unrun checks, and residual risks. 8. Rollout mode: `production schema 3`. Only `PASS` means the requested implementation is complete for the verified snapshot. `UNVERIFIED` means the implementation may be ready but available evidence cannot justify that claim.