mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-05-20 09:23:27 +00:00
d02255907c
ResolveFinding adapter previously logged a warning and allowed the LLM's resolve to proceed when the deterministic verifier returned an error (timeout, executor unavailable, etc.). That's fail-open: any verifier failure let the auto_resolved → re-detected cycle continue, exactly the pattern the rest of this branch's patrol_resolve_finding work spent commits closing. The "Backup failed" finding on the live preview still cycled once post- migration because of this path — verifier returned an ErrVerificationUnknown and resolve was permitted. Resolution of an event/persistent category finding is effectively permanent (next detection registers as a regression and inflates counters and pollutes the trust strip). When the deterministic verifier cannot confidently say the failure signal is gone, we don't have grounds to honor the LLM's judgment — the LLM's "current investigation didn't surface a fresh failure" is exactly the unreliable signal that produced bogus cycles. Switches the inconclusive-verifier branch from log-and-allow to log-and-reject, returning an error to the tool so the LLM can retry or escalate to the operator. The verifier-still-detects- signal path stays as-is (it was already fail-closed). Test: TestPatrolFindingCreatorAdapter_ResolveFinding_RejectsWhenVerifierIsInconclusive exercises the path by calling ResolveFinding on a backup-failed finding through a PatrolService with no chat service wired (getExecutorForVerification returns ErrVerificationUnknown). Asserts the error mentions 'inconclusive' and that ResolvedAt remains nil. Contract: extends the deterministic-resolve-gate clause in the ai-runtime canonical-files completion-obligations to name the fail-closed-on-inconclusive policy explicitly. |
||
|---|---|---|
| .. | ||
| internal | ||
| v6 | ||
| control_plane.json | ||
| control_plane.schema.json | ||