/challenge-resolve

name: challenge-resolve
description: Independently review and fix a bounded task through convergence rounds, with evidence-backed closure and explicit stop/remediation decisions. Use for an explicitly invoked adversarial review-and-fix loop over an existing implementation, feature, problem, or diff, including repeated review/fix requests or a second independent review of the same change; not for ordinary review (code-review) or single-pass finding remediation (code-remediate).

> Before asking, read [User Questions](../../shared/codex-user-questions.md).

Challenge and Resolve

> Task-size routing follows [Proportional Execution](../../shared/native-skill-contract.md#proportional-execution); this skill's specialized lifecycle and acceptance checks remain authoritative.

Read, apply `../../shared/adversarial-loop.md` before dispatch or edits. That shared procedure owns the algorithm; this entrypoint owns Codex artifacts, the closing gate. Read `evidence-contract.md` before source capture or reviewer dispatch. Also read [Authorized Workflow Execution](../../shared/native-skill-contract.md#authorized-workflow-execution) for authority; [Acceptance and recovery](../../shared/native-skill-contract.md#acceptance-and-recovery) and [Evidence Rules](../../shared/native-skill-contract.md#evidence-rules) for evidence limits; [Bounded Dispatch Wave](../../shared/specialist-orchestration.md#bounded-dispatch-wave), [Read-only work and executable probes](../../shared/specialist-orchestration.md#read-only-work-and-executable-probes), [Portable Role Routing](../../shared/specialist-orchestration.md#portable-role-routing) and [Retry And Checkpoint Policy](../../shared/specialist-orchestration.md#retry-and-checkpoint-policy) for reviewer admission. Recurrence follows the stop rules in `../../shared/adversarial-loop.md`.

Input Schema

{
  "goal": "required review-and-fix objective",
  "scope_files": ["bounded source paths relevant to the task; discover them when initially unknown"],
  "specification": "required behavior or acceptance criteria",
  "symptom": "reported problem, feature objective, or preventive review",
  "caller_run": "optional existing workflow run to resume",
  "done_when": "independent final review is clean and normal checks pass"
}

Begin with independent baseline `W_0`, then continue only while the unchanged-scope nonnegative integer total score strictly decreases; no arbitrary three-review cap applies. Stricter caller reviewer and retry budgets remain binding. For a problem or feature without named files, inspect the repository to identify and bound the relevant source before freezing a review; a pre-existing implementation can have an empty diff. In-scope feasible fixes are authorized by a review-and-fix request; a structural finding does not authorize scope expansion, public API changes, commits, installs, network access or publication. A caller's stricter scope or admission still applies. The retained request proves delivery of the parent's declared criteria to the challenger; report any uncertainty about interpreting the user's scope instead of claiming machine authentication of natural language.

> Review each frozen scope with a fresh independent challenger process. Give it source, diff, criteria, and original finding counterexamples needed for verification; never give it resolver handoffs, explanations of changes, or parent closure claims. The main process owns old/new identity, severity, the weighted ledger, resolver assignments, and stop decisions. New challenge results use the same strict artifact checks under candidate and canonical filenames; archived JSON remains readable as data but cannot certify current completion.

Workflow

01: Establish scope and evidence ownership

Read `../../shared/helper-cli-contract.md`; create a run with `create_run.py --skill challenge-resolve`. Record `caller_run` when supplied, without overwriting its artifacts. Retain baseline source and acceptance evidence. Write `loop-report.md` with `Scope`, `Rounds`, `Findings`, `Remediation`, and `Verification` sections. Identify implementation author and allowed reviewer route before dispatch.

Before freezing a Python review scope, follow `../../shared/codemap-contract.md` to settle unresolved caller, dependency and test-impact facts. Reuse still-current caller evidence that covers the same source and question; otherwise run `PLUGIN_ROOT/bin/python PLUGIN_ROOT/shared/codemap_adapter.py context --category implementation --query-kind <skip|central|callers|blast|dependencies|test-impact|coupling|standard> --root <verified-source-root> --out <run-directory>/codemap-context.json`, adding `--target <resolved-qname>` when required. Select the smallest sufficient route; an explicit structural request overrides `skip`. The parent prepares the index serially through the provider's ordinary query, then includes the retained evidence and its limitations in reviewer context. Missing provider or incomplete static coverage requires bounded source inspection, not fabricated graph evidence; never mechanically invoke `scan-codebase` or substitute a different checkout's index.

Before any remediation, list every requested path, relevant unchanged consumer, and known interaction in `loop-report.md` under `Scope`; assign each to the first challenger scope or mark it unreviewed with a reason. Finish the first challenge over every admitted part before treating the gathered findings as the discovery baseline. A complete-file chunk plan proves byte delivery only; the parent must inspect each reviewer's stated coverage and keep an uninspected path or interaction visible. If full initial coverage is unavailable, stop an overall clean claim rather than spending repeated fix rounds on a partial baseline.

For each workflow branch in scope, record one source route before dispatch: entrypoint, producer, next ordinary consumer, distinct sibling path where one exists, and the acceptance test that exerc