Problem
review-branch's specification-compliance template emits a ⚠️ divergence callout whenever the two auto-resolved ticket candidates carry different last_updated values. The trigger is a bare timestamp comparison that never reads either source's content, so the callout cannot distinguish a real divergence from a benign one, and any nonzero delta fires it.
It fires hardest on the healthy path. Saving a local ticket snapshot and then pushing the same refined text to the remote are two steps of one operation, minutes apart, so the timestamps differ while the content is identical. The reviewer then reports freshness as a caution, and a downstream agent relaying it typically adds that the two sources agree anyway -- reporting the desired outcome as a caveat and inverting the signal a second time.
Context
The instruction is in the output template of packages/agents/content/skills/review-branch/SKILL.md, in the "Specification compliance" section.
Observed on a review of williamthorsen/toolbelt#129, where the snapshot trailed the remote by three minutes with identical acceptance criteria. Captured as feedback event 01KZWVWRY6FDXW629F0ZJ2XTZP (personal store, tags feedback,mistake, impact high).
The callout protects nothing the selection rule does not already handle. Step 3 picks the candidate with the newer last_updated, so the review already measures against the fresher contract; the callout only narrates that choice. --spec-source=remote|local stays documented in the skill, so a reader wanting the other side is not stranded if the callout goes away.
Proposed solution
Replace the timestamp trigger with a one-directional content check, fired only where the reader has something to act on.
When the chosen candidate is the local snapshot and a remote candidate existed, compare the two candidates' acceptance criteria and emit the callout only when they differ materially -- a criterion on one side with no counterpart on the other, or worded so the verdict could differ. The callout names the difference, states that the review measured against the snapshot rather than the published ticket, and points to --spec-source=remote. This is the case with a reader-facing consequence: the contract the review judged is not on the remote, so anyone reading the issue sees different criteria. It is the standing outcome of design-and-plan's leave-the-remote-as-is option, and the permanent shape of the not-owned-ticket workflow.
When the remote candidate wins, say nothing, whatever the criteria show. The snapshot is a plan-time artifact superseded by the selection rule, and flagging its divergence from current state is what the artifacts-record-a-moment doctrine tells us not to do.
Keep this as its own callout rather than folding it into ## Specification consistency. That section compares two contracts that both remain in force and offers to reconcile them; this is one contract in two versions, where the newer wins by rule and nothing is rewritten.
Acceptance criteria
Must have
Problem
review-branch's specification-compliance template emits alast_updatedvalues. The trigger is a bare timestamp comparison that never reads either source's content, so the callout cannot distinguish a real divergence from a benign one, and any nonzero delta fires it.It fires hardest on the healthy path. Saving a local ticket snapshot and then pushing the same refined text to the remote are two steps of one operation, minutes apart, so the timestamps differ while the content is identical. The reviewer then reports freshness as a caution, and a downstream agent relaying it typically adds that the two sources agree anyway -- reporting the desired outcome as a caveat and inverting the signal a second time.
Context
The instruction is in the output template of
packages/agents/content/skills/review-branch/SKILL.md, in the "Specification compliance" section.Observed on a review of
williamthorsen/toolbelt#129, where the snapshot trailed the remote by three minutes with identical acceptance criteria. Captured as feedback event01KZWVWRY6FDXW629F0ZJ2XTZP(personalstore, tagsfeedback,mistake, impacthigh).The callout protects nothing the selection rule does not already handle. Step 3 picks the candidate with the newer
last_updated, so the review already measures against the fresher contract; the callout only narrates that choice.--spec-source=remote|localstays documented in the skill, so a reader wanting the other side is not stranded if the callout goes away.Proposed solution
Replace the timestamp trigger with a one-directional content check, fired only where the reader has something to act on.
When the chosen candidate is the local snapshot and a remote candidate existed, compare the two candidates' acceptance criteria and emit the callout only when they differ materially -- a criterion on one side with no counterpart on the other, or worded so the verdict could differ. The callout names the difference, states that the review measured against the snapshot rather than the published ticket, and points to
--spec-source=remote. This is the case with a reader-facing consequence: the contract the review judged is not on the remote, so anyone reading the issue sees different criteria. It is the standing outcome of design-and-plan's leave-the-remote-as-is option, and the permanent shape of the not-owned-ticket workflow.When the remote candidate wins, say nothing, whatever the criteria show. The snapshot is a plan-time artifact superseded by the selection rule, and flagging its divergence from current state is what the artifacts-record-a-moment doctrine tells us not to do.
Keep this as its own callout rather than folding it into
## Specification consistency. That section compares two contracts that both remain in force and offers to reconcile them; this is one contract in two versions, where the newer wins by rule and nothing is rewritten.Acceptance criteria
Must have