-
Notifications
You must be signed in to change notification settings - Fork 3
plat 154
PLAT-154 — record_pulse_finding reports failure after successfully updating a finding owned by another module
| Coordination | Value |
|---|---|
| Assigned agent | Codex |
| Ticket state |
implemented — regression test passes; live restart/retry verification pending |
| Last synchronized | 2026-08-19 |
- Priority: P1 — the durable update succeeds, but the false error makes the reviewer retry, wastes tool/model work, and can cause the terminal module receipt to describe a valid evidence update as incomplete.
- Owner: typed Pulse finding write/reload boundary.
The Social Media Engineering/Ops child updated existing issue PUL-42183990
three times and received:
recorded Pulse finding could not be reloaded by its internal lifecycle identity
The live SQLite row proves the cross-module shape:
fingerprint step_id phase status
4218399017332805 eval-workflow-success review open
The reviewer correctly supplied the visible issue ID and module
workflow_review. RecordPulseReviewFinding resolved that ID to the existing
fingerprint, preserved step_id=eval-workflow-success, wrote the recurrence and
typed details, then tried to verify the result through
LoadPulseFindingLifecycles(..., marker.Module, ...). That module-filtered view
cannot contain the step-owned row unless a separate fix-attempt link happens to
exist. The successful write therefore became a false tool error.
The post-write verification now reloads the unfiltered lifecycle view and
matches the exact already-resolved fingerprint. The fingerprint is the internal
row identity; the current observer's module is not. This does not expose the
fingerprint to agents or weaken public PUL-… identity validation.
A regression test first records a finding under eval-workflow-success, then
updates that public issue from workflow_review. It proves that:
- the call returns the same public issue ID;
- the original step identity remains intact;
- recurrence increments rather than creating a second issue; and
- the typed reviewer evidence is attached to that existing row.
- Updating a step-owned issue from a reviewer module returns success.
- Same-module updates remain idempotent and keep one lifecycle row.
- No internal fingerprint appears in the public tool result.
- A live post-restart Pulse update of
PUL-42183990produces no retry loop.
Auto-synced from docs/ on main. Edit there, not here.