Refresh the failure mandate in-loop when a write lands on a file the failure names #2

2026-08-02T12:28:41+02:00

claude commented

2026-08-02 12:28:41 +02:00

Closes Vikunja #461.

Acceptance criteria and quality gate are in TASK.md on this branch.
Review the review, not the diff — leave comments and the agent will apply them via task start 461.

Closes Vikunja #461. Acceptance criteria and quality gate are in `TASK.md` on this branch. Review the review, not the diff — leave comments and the agent will apply them via `task start 461`.

claude added 1 commit 2026-08-02 12:28:41 +02:00

feat(kernel): refresh a stale lsp_diagnostics mandate in-loop (#461 ) 24b94aab28

On a gate-repair retry the failure text was frozen for the whole tool loop. The
agent edited the offending file, was told "written successfully", and kept
editing against a diagnostic it may already have cleared — it only found out
after stage_complete, when runPostStageGates re-ran from the top.

refreshLspRetryMandate hangs off the existing wroteThisRound hook: when the
pending retry mandate is an lsp_diagnostics failure and a write landed on a path
that failure names, re-pull diagnostics, record LspDiagnosticsCompletedEvent,
and rebuild the retryFeedback entry. buildRetryFeedbackEntry already renders
per-file freshness from that event, so the ledger flips to "done, leave it"
in-loop with no new message format and no context rebuild.

Two calls worth stating. The pull covers the stage's whole written set, not just
the named paths, because a path absent from the recorded event reads as clean to
fileRepairOutcomes — a partial pull would mark unrelated files repaired. A
skipped pull returns null rather than recording empty diagnostics, for the same
reason: telling the model to leave a still-broken file alone is worse than
leaving the stale text in place.

Scoped to LSP. A tsc or npm run build re-run per write is too expensive.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

claude merged commit 4113ee9af4 into master

2026-08-11 12:13:08 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kami/correx#2