Status leaves the compared set, so the snapshot is now just the two body
fields. The comparison answers one question — must the agent re-read the issue
BODY? — and status never helped answer it: its current value ships on every
claim, so the agent learns it without a read.
Worse, comparing it worked against the feature. The workflow has the agent set
in_progress when it starts and in_review when it delivers, so the agent's OWN
bookkeeping came back the next turn as "changed: status" and demanded a body
re-read that nothing in the body justified. Replaying this issue's 21
follow-ups, that alone cut "unchanged" from 17 to 4. The earlier rationale for
keeping it — a free signal that somebody intervened — was wrong on both counts:
it is not free, and the agent can see an intervention by comparing the shipped
status against the value it last set itself.
issueSnapshotVersion stays 1, and this time rows in the old shape DO exist.
That is still correct: removing a field is backward compatible, because every
field the new code reads is present in an old row and still means the same
thing, and the stale "status" key is ignored. The comment now states the actual
bump rule rather than "the set changed" — bump when an old row can no longer
answer the current question, which means adding a field or changing how a value
is derived, not removing one. A test pins the legacy shape comparing correctly
in both the unchanged and the changed direction, so that claim is checked rather
than asserted.
No migration: the column is JSONB and the schema is unchanged.
TestClaimTaskByRuntime_AssigneeAndPriorityAreOutOfScope becomes
NonBodyFieldsAreOutOfScope and now moves status alongside assignee and
priority, asserting the current status still ships with its NEW value — without
that, the fixture's UPDATE could silently not apply and the empty changed-list
would prove nothing.
Co-authored-by: multica-agent <[email protected]>
