work-items(attend-queue): no row-level claim — concurrent attended sessions collide on the same rows

[kyle-sexton]

This was generated by AI during a loop-lane launch-prompt design session.

Context

/work-items:attend-queue builds one attention view merging [ratify], [escalated], and
[intake] rows, then works them. It has no claim or lease protocol for a row.

/work-items:work has one — the seam claim (assignee + lease), where exit 7 means "another
session won: advance to the next candidate." attend-queue has no equivalent, so two concurrent
attended sessions on the same repository will both surface the same row and can both act on it:
duplicate interview questions posted as comments, conflicting label flips, or two operators
answering the same escalation differently.

This blocks a real workflow: running several attended terminals against one repository to raise
human-in-the-loop throughput on a large backlog. The only mitigation today is manual sharding —
by row kind, by issue-number parity, or by label — coordinated verbally between terminals.

Proposed work

Give attend-queue a row-level claim consistent with the tracker seam's existing protocol, or an
explicit sharding argument so concurrent sessions partition deterministically rather than by
operator discipline.

Sharding-argument shape is the cheaper option and may be sufficient: an argument naming the row
kinds or a modulus this session owns, with the view filtered accordingly.

Acceptance criteria

• Two concurrent attend-queue sessions on one repository cannot both work the same row
• The mechanism is stated in the skill, not left to operator convention
• A single-session run is unaffected — no new required argument

References

• plugins/work-items/skills/attend-queue/SKILL.md (attention view; no claim protocol)
• plugins/work-items/skills/work/SKILL.md (seam claim, exit 7)
• plugins/work-items/reference/tracker-seam.md
• Related: work-items(attend-queue): execution drift — judgment lane pushes branches/PRs and offers fixes; harden never-execute from item-scoped to mutation-class-scoped #1222 (attend-queue execution drift)

Metadata

Surfaced while planning five concurrent attended terminals against a 260-issue backlog.

[kyle-sexton]

This was generated by AI during triage.

Verified

Confirmed against plugins/work-items/skills/attend-queue/SKILL.md at this commit: the file has no row claim or lease protocol. The four occurrences of "claim"/"lease" are unrelated — lines 151 and 164 are the rate-limit guard's "stop claiming new work" drain-then-pause language, and line 178 references the topology's single-authority rule. No seam claim verb is invoked for a row.

By contrast /work-items:work does claim via the seam (assignee + lease, exit 7 on a lost race). The asymmetry is exactly as filed.

Classification

• Work class: C3 scoped — a claim protocol or sharding argument confined to one skill, reusing the seam's existing lease mechanics.
• Priority: medium. Real, but the mitigation (manual sharding between terminals) exists today and the failure is visible rather than silent — unlike work-items(work-loop): fixed telemetry title and sentinel make two lanes on one repo clobber durable state, including first_drain_complete #1295's state corruption.

Blocked by #1295 — cluster member, not separately human-gated

Carries a blocked-by edge to #1295 and deliberately no human-gated label.

The shared decision: whether concurrent multi-session operation against one repository is supported at all. This item's own body offers the same fork #1295 does — a real claim protocol versus "an explicit sharding argument so concurrent sessions partition deterministically" — and the choice between them is the carrier's decision, not this item's. If multi-session-per-repository is declared unsupported, this item's acceptance criteria are satisfied by stating that constraint in the skill rather than by building a claim.

Worth noting for whoever resolves the carrier: this item is the one cluster member whose collision does not require two machines. Two attended terminals on a single machine collide the same way, so a resolution scoped only to cross-machine identity would leave this case open.