From review to repair

Repair needs better inputs than a comment.

A vague finding forces the engineer or agent to rediscover the issue before fixing it. A grounded finding carries the file, line, reason, evidence, and expected behavior.

That is the difference between a comment that sounds smart and a review that can become useful repair work.

The repair path needs the claim and the proof. It needs to know whether the issue is a failing invariant, a missing tenant check, a stale assumption, a race, a forgotten test, or a product rule that lives outside the changed file.

Without that structure, the repair model is pushed toward generic code editing. It may make the diff smaller, but it can also erase the constraint that made the original finding important.

The model needs the same evidence the reviewer used.

A repair agent should not receive only the final review sentence. It should receive the anchor, the relevant surrounding code, the execution or static evidence, and the memory that explains why the issue matters in this repository.

That is especially important when the repository context conflicts with a model's general prior. A generic model may expect one architecture, one naming convention, or one normal way to handle an error. The local system may intentionally do something else.

The repair path has to preserve that local meaning. Sigilix's own models are tuned to treat repository memory and code evidence as part of the repair contract, not as decorative context.

Memory should narrow the repair.

Memory is useful when it removes ambiguity. It can tell the repair path that a helper is shared across worker routes, that a test fixture mirrors production behavior, or that a prior reviewer dismissed a similar pattern because the code was unreachable.

It is not useful when it becomes a pile of context the model can cherry-pick from. The system has to retrieve the memory that matters, connect it to the current code, and make the model justify the repair against that evidence.

That is why Bring Your Own Key (BYOK) is not a complete substitute here. A local external model can edit code, but it may not obey Sigilix memory the same way a Sigilix route does when memory and parametric knowledge disagree.

Verification belongs before confidence.

When Sigilix can verify a claim, the repair path is clearer. When it cannot, the system should say so. The point is not to sound certain. The point is to earn certainty where the evidence supports it.

That means the repair loop needs a way to check itself: tests, static analysis, deterministic receipts, or narrow reasoning tied to the actual code path. A model should not call a patch safe because it reads cleanly.

The better the original review evidence, the easier this becomes. A finding that names the failing behavior can produce a regression test. A finding that names the invariant can guide the patch. A finding that names uncertainty can stop the repair from pretending it is proven.

Repair is a workflow, not a generated patch.

The product line from review to repair is not one button. It is a sequence: find, prove, route, repair, verify, and explain. Each step should reduce uncertainty rather than move it to the next person.

That is why Sigilix is built across review, triage, CLI, chat, and memory. The review needs to become an action without losing the proof that made it believable.