Replies and rechecks

Who can reply to a finding today

Replying inside a finding's own GitHub thread — to defer it or trigger a targeted recheck — is still owner-only: "Still owner-only in this slice: replies in finding threads (deferral and rechecks; decision 6 is deferred)." This is narrower than commenting /sigma review, which any repository writer can do (see modes-and-requests.md). Not yet available: a colleague replying in a finding thread. Today that reply is ordinary GitHub discussion and does not trigger any Sigma work; ask the connected maintainer to reply instead.

A summary-only finding (one that did not fit as an inline comment) has no GitHub thread of its own, so it cannot be replied to this way.

Deferring a finding

The maintainer replies /sigma defer <reason> — a reason is required for this exact form. The same intent is also recognized from plain phrases, where a reason is optional: "fix later" or "will fix later" (or their Russian equivalent), each optionally followed by :, — or - and a reason. This costs no model work: the finding's recorded disposition becomes deferred, and the reply explains that deferring does not mark it fixed.

Requesting a targeted recheck

Any other new reply from the maintainer in that thread — including something as short as a disagreement — can trigger a paid, targeted recheck of that one finding, by the exact reviewer/version that produced it. A recheck reuses the original finding, report and source context; independent producers and a fresh verifier reach one of: fixed, refuted, deferred, or open/inconclusive — an agent-adjudicated outcome, not a claim that the code is provably correct. Editing an old reply does not start a new recheck; only a genuinely new reply does.

If the finding's original reviewer/version has since been removed from the repository's roster, or is Off, the reply reports the recheck as unavailable — history and disposition are not silently reassigned to a sibling reviewer.

What a recheck costs versus a full review

A recheck is scoped to one finding: it reuses the original run's baseline, checks and limits, so it is bounded work, distinct from a full review. A full review (after a push, or a fresh /sigma review) re-reviews the whole current head and is priced like any other run. Today, a push does not automatically recheck a prior finding — that runs a new full review first; automatically following up on the original findings after that review is still project work (tracked as #110), not shipped behavior.