adversarial-refinement-loop

Adversarial Refinement Loop

Treat refinement as an open-ended search, not a checklist that converges after one green build. Once invoked, keep starting new passes until the user explicitly pauses or stops, a genuine external blocker prevents useful work, or the host ends the run. A pass with no high-confidence defects is evidence to change the review lens; it is not a completion condition.

An ordinary response boundary, context compaction, temporary tool failure, exhausted lens, or clean result is a checkpoint, not completion. When the host supports persistent goals or automatic continuation, use it. If a hard host stop is unavoidable, label the run incomplete, preserve the exact ledger and next lens, and resume on the next supported continuation. A blocker ends the active run only when no safe, useful pass remains under any lens after reasonable alternatives have been tried.

Away-mode context

Users commonly invoke this loop immediately before going to sleep or becoming busy with something else. Treat their expected silence as permission to keep working within the already authorized scope, not as a request for frequent decisions or a signal to stop. Prefer evidence-backed, reversible assumptions; move to another useful lens when one lane genuinely needs user input. Absence does not expand permission to publish, push, release, contact people, delete data, expose private material, or make other external mutations.

If the user returns and says they are awake, available again, or wants to stop the loop, exit persistent loop mode promptly. Stop scheduling automatic new passes, preserve the current ledger and active findings, and continue any remaining requested work under ordinary collaboration rules unless the user also asks to pause or stop the project itself. Leaving loop mode is not the same as discarding the backlog.

Pass loop

Maintain a lightweight pass ledger containing the lens, evidence, changes, verification, and unresolved hypotheses. For every pass: