Qualify opt-in CLI task routing on one working provider

Decision

Keep this as a narrow provider-qualification follow-up for the existing opt-in CLI feature. Do not build another router, enable automatic defaults, or add web controls under this CLI issue.

Implemented on main

• scan --task-model ROLE=MODEL assigns discovery, attack, verification, and reporting models; --single-model overrides all task pins.
• Reviewed --routing-report recommendations require explicit model approvals, a workflow/provider review reference, matching workflow and evaluator identity, complete positive/negative task controls, and known usage.
• Guided CLI planning shows assignments/reasons before confirmation; stage progress names the selected model.
• Runtime forks preserve approved routing and share the scan's usage ledger, cancellation, and overall plan limits. Tool/evidence handoffs retain authorization scope and validation state.
• Ordinary scans do not run qualification or silently enable this policy. Retiring the terminal UI did not remove the headless CLI or ordinary guided CLI prompts.

Evidence and limits

The real CLI fixture adapter completes 64 mock calls / 32 trials and detects the deliberately regressing model label. Runtime, qualification, and scan-plan regression suites pass (23 focused tests in this audit). Fixtures establish protocol/accounting behavior only.

All 24 retained genuine local-model requests were protocol-inconclusive: none completed the required structured tool roundtrip. They do not establish task quality, a best model, or a deployable recommendation. No provider-backed multi-task qualification or invoice reconciliation is available.

Remaining acceptance

• Use one already approved working provider and explicitly approved accessible models in a controlled, authorized multi-task CLI scenario.
• Retain the actual task-to-model route, a structured tool-call/result handoff, unchanged scope/evidence/validation state, and one shared usage ledger.
• Exercise operator task overrides, single-model override, unavailable/incompatible model rejection, and stop behavior when usage is unknown or limits are reached.
• Record resolved provider/model labels and version limitations, all measured latency/token usage, catalog estimates, and any independently reconciled charges separately. Unknown charges are not zero; current spend limits remain estimated stopping thresholds.
• Keep default behavior unchanged. A small protocol panel cannot support general task-specific model-superiority claims; any future default/ranking expansion needs representative task-quality evidence.

Provider-backed execution is not authorized by this issue rewrite alone; it requires an explicit operator-approved plan and cap. No paid calls ran during this audit.

Backlog review and validation: #212, docs/qualification/issue-triage-2026-10-27.md.