Decide configurable campaign autonomy and approval boundaries

[justsml]

Question

What configurable autonomy modes should an OSS research campaign support, including a fully automated mode tested first, and how should planning, passive review, active probing, credential use, browser mutation, downloads, writes, shell commands, exploit validation, patching, and stop/resume behavior map to durable target authorization and exact-intent approvals? Decide what may be pre-authorized, what always requires a fresh decision, how denials and expired grants behave, how side effects are deduplicated across recovery, and what forensic evidence each autonomy transition must preserve.

[justsml]

Implemented and pushed a reversible campaign autonomy decision foundation in commit 7fa8579. Manual, bounded, and fully automated scheduling share the durable target and exact-intent approval boundaries. Fully automated mode never mints authority: it can consume an already matching exact preauthorization only for active probes, downloads, and shell commands; credential tests, browser mutation, writes, exploit validation, and patching require a fresh exact decision. Denied, expired, mismatched, and consumed decisions stop. Recovery reuses successful effects and reconciles unknown effects before replay. Conjunctive active/wall/cost/action ceilings and forensic fields are explicit. Focused integration contract: 5 passing tests. Full TypeScript check passes. Remaining HITL choices include which preauthorizable classes the product should expose and whether bounded mode should be narrower; keeping the ticket open.