Fixes

A finding tells you something is wrong. A fix proposes the correction.

What happens

You click Fix with Deltz on a finding, sign in if you are not already, and confirm on the page that opens — the link itself does nothing, so a link preview or a crawler cannot start a fix, and only a member of the organisation that owns the review can. A model then drafts a corrected version of the file. The draft is put through the gate. If it passes, Deltz posts it on the pull request as suggested changes — the host’s own applyable blocks, anchored to the exact lines, one block per place the fix touches. You read each block in the diff, apply the ones you want (GitHub lets you batch several into one commit), or ignore them.

Nothing lands on your branch until you apply a block. When you do, that is a push by you — and every push is reviewed again, so the fix you accepted goes through the gate a second time as part of the new head.

Your branch, your pull request, your choice, your merge.

When it commits instead

Some fixes cannot be expressed as suggestions: the hunk lands on a line the pull request’s diff does not show (both hosts refuse a suggestion there), the model reflowed the file so the change is spread over more than six places, or the branch moved while the fix was being drafted. Deltz then posts a note saying which, posts nothing else, and offers a Commit this fix link that delivers the same gate-passing file as a single commit on the pull request’s head branch — one you can review and revert like any other.

An organisation that prefers commits as the first choice sets the policy key fix.commit_directly to true in Settings → Policy (admin only). Either way the file is identical and the gate ran first.

The constraint that matters

A generated fix goes through review.RunChecks — the same function an external pull request goes through. Not a parallel implementation intended to match: the same code path.

Tests including TestRun_GateBlocksPR and TestRun_GatePassesWhenFixed fail if generated output can bypass it, and TestAdoptedRuleReachesTheFixRegate asserts that a rule your organisation adopted applies to Deltz’s own output too.

Deltz cannot approve its own homework. A fix that would trip a rule is not offered: a correction is accepted only if the targeted finding stops firing and the change introduces no finding that was not there before — a draft that encrypted a database while making it public is refused, and the note on the pull request names the rule it would have tripped. A draft that does not parse, or that removes the resources it was meant to fix, is a failed generation, never a pass.

It needs an API key. The gate does not.

Fixes require an Anthropic API key, because a model writes them. The deterministic gate is entirely unaffected without one — parsing, conventions, findings, evidence, blocking all work with no key, on every plan. Without a key you get findings and no proposed fixes.

That split is the product: the model writes, the parser judges.

Forge

Forge is the same idea for new infrastructure: describe what you want, get a draft. It commits files and opens a pull request a human reads. It is gated identically — TestForgeDraftIsGatedByAdoptedRules — so a Forge draft that violates your own adopted rules never becomes a pull request.

Both Fix and Forge are the only paths that write repository content at all. See what Deltz writes.