-
Notifications
You must be signed in to change notification settings - Fork 2
plat 239
PLAT-239 — changed_unverified's contradictory next_check requirement: already resolved independently
| Coordination | Value |
|---|---|
| Assigned agent | Claude Code |
| Ticket state | resolved |
| Last synchronized | 2026-08-29 |
- Priority: harness_issue, severity high.
-
Findings: Twitter/social-media
PUL-DA42695E— a reviewer could not successfully submit achanged_unverifieddisposition: passingnext_checknested underdisposition.orverification.was rejected asunknown field next_checkby the decoder, and omitting it entirely was rejected by lifecycle validation with"finding ... changed_unverified requires next_check naming the run, table, or artifact"— no placement of the field could ever satisfy both the decoder and the validator at once.
git log -S "changed_unverified requires next_check" on
pulse_finding_lifecycle.go finds commit c60f1f830 ("Simplify Pulse
review, repair, and workflow run lifecycle", 2026-08-28 22:09
+0530) — one day before this session — which removed the exact
requirement block the finding's evidence quotes near-verbatim:
if disposition.NextCheck == "" {
add("changed_unverified requires next_check naming the run, table, or artifact whose arrival proves or disproves this fix")
}The current validateFindingDisposition's FindingDispositionChangedUnverified
case has no NextCheck check at all — only ChangedFiles, matching
before_refs/after_refs lengths, and no failed immediate check are
required. Confirmed the two later commits touching this file
(d9223aa61, 636fb6e0a) did not reintroduce it. next_check remains a
correctly-decoded top-level field on each finding_dispositions[] element
(pulseFindingDispositionToolArg.NextCheck, both in the Go struct and the
tool's JSON schema) for the dispositions that do still require it
(awaiting_run, queued_for_engineering) — the finding's decoder-rejection
evidence (disposition.next_check, verification.next_check) reflects
wrong nesting attempts, not a decoder defect; the schema has always
correctly placed next_check as a direct sibling of disposition/summary
within each array element.
Same "real when filed, already fixed via a same-era commit, never re-verified in the finding" shape as PLAT-228/230/237.
Confirmed via git log/git show against the actual commit history, not
inferred from the finding text alone. No code changed this session — the
fix already shipped in c60f1f830.
Not applicable to this session's work. If changed_unverified still
appears to require next_check in a live run, that would indicate a
regression since c60f1f830, not this finding recurring.
Auto-synced from docs/ on main. Edit there, not here.