Controlled disagreement: the minimal recipe.

A round is proposed when the work unit crosses the high-impact bar, defined by at least one of five criteria:

• Contract or API change between components.
• Database schema change or migration.
• Security, authentication or authorization.
• Concurrency, race conditions or transactions.
• Logic that is hard to revert or business-critical.

Also when there is real uncertainty: viable approaches with no clear winner, low confidence reading the code, or an ambiguous requirement that is expensive to get wrong.

It is skipped for local, reversible, trivial or template changes. And every run requires the developer's explicit approval: never automatic.

The header used in the reported operation, translated. The original runs in Spanish and deliberately without accents, for encoding robustness through the shell:

Then come the system context, the complete plan or diff, the domain-specific attack requests, and the output format: a numbered list with severity, file:line evidence, and what the reviewer would change. The diff prompt is the same one, applied to the working tree's change set.

The reviewer sees the repository but not the main assistant's conversation: all context reaches it, and only reaches it, through the prompt. So it has to be regenerated after every intermediate product decision, or it will object against a version that already changed.

The event ends when each finding, individually, has reached one of these three states. Never by consensus: agreement between two assistants that share training data does not make a conclusion true.

• Resolved — fixed, with verifiable evidence of the closure.
• Refuted or discarded — with verifiable evidence: a code citation, a measurement, or documented environment behaviour.
• Transferred to the developer — closes the event, but leaves the finding open and owned.

The transfer has four terminal states of its own: accepted debt (recorded with an identifier and a justification), accepted risk (an explicit decision), partial mitigation (part applied, the rest to debt), and pending escalation (transferred with no decision recorded, which is not a closure).

A text file versioned next to the code, one entry per round. The minimal record per finding:

• Identifier and severity.
• Cited evidence.
• The main assistant's verdict after verifying against the repository.
• Disposition state (block 03).
• The authority that resolved or accepted the risk, and the date.
• For an open transfer, the responsible recipient.

That log is what survives session-history retention, which expires on its own. In the reported operation, eleven events that were not recorded at the time had to be reconstructed later.

• Product decisions. They require human authority and responsibility; they are not a defect a reviewer can find.
• Discarding without evidence. If there is nothing to refute it with, the finding is transferred, not discarded.
• Anything without an executable oracle. Findings that depend on external contracts or the real environment go to the developer.
• The last word. Even against the reviewer: the corpus contains a global negative verdict the developer kept for product reasons, on the record.

And a warning that came out of the most instructive case: a fix derived from a finding is also new code without coverage, and deserves its own event or its own tests before being closed.