[trissim]

P904 and P942 carry #3566, which is P883's. The bus can't remove it today: the only link editor is AssignTodo, and IncomingWork.require_free refuses it because queue-core-fix holds P904. This PR adds the fix: 1 new correction member, 1 new verb, 0 new tools, and the duplicated link filter goes from 2 copies to 1.

How the link got there (read-only query of the live stored_order_story): P904 story seq 8259 and P942 seq 8864 are reviewing events with claim.pull_request.number = 3566. ClaimedProblemOrder carries the claim's link (todos.py carrying((claim.pull_request,))). Later sends (P904 seq 8897, 9008) kept it through ListedProblems.carried.

Changes

• CorrectLinkTodo(CorrectOrderTodo) (todos.py): part = order.pull_requests, replaced = order.unlinked(link). Like every member of the correction family, the order keeps its id, state, holder, review timer and strikes. A stale previous is refused by the family's existing check, and an order that doesn't hold the link is refused too. A merged order refuses it through require_linkable, because taking back a merge belongs to CorrectMergedLinkTodo. There is no occupancy check, no release, no fold and no strike.
• CheckedProblemOrder.unlinked is now the only place that removes a link. MergedProblemOrder.merged_link and unmerged used to filter the tuple themselves; both now call it.
• order unlink PID OWNER/NAME N --why ... (UnlinkVerb, commander/order.py) sends the operation through the existing comms_todo tool (CommsChangeProblemTool). The comms_todo schema picks the new member up from the family: correct_link_todo appears 4 times in FieldCodec.record_schema(CommsChangeProblemTool).
• No change to order.py carry logic, on purpose. ListedProblems.carried already reads each listed problem's current order. It only "re-carried" the link because nothing could remove it from that order. Once the order is corrected, a resend carries only the links that are left; the test asserts this.

Test (tests/test_holder_standing_rules.py::test_unlink_takes_another_orders_pull_request_off_a_held_order): P1 is held by a running worker, which is exactly where AssignTodo would be refused. It covers: CLI refusal for a link the order doesn't hold, with the store unchanged; CLI success removing #3566 while toad#1319 stays; the recorded correction; order, holder, review_at and strike count unchanged; and ListedProblems.carried carrying only toad#1319 afterwards.

PYTHONPATH=$WT/src:$WT/tools timeout -s INT 300 .venv/bin/python -m pytest -p no:xdist -q \
  tests/test_holder_standing_rules.py -k "unlink_takes or merge_through_a_prerequisite or send_and_check_accept"
3 passed, 46 deselected in 4.79s

After merge and install (not run here):

agent-comms-commander order unlink P904 openhcsdev/agent-comms 3566 --why "a claim recorded P883's PR on this order"
agent-comms-commander order unlink P942 openhcsdev/agent-comms 3566 --why "a claim recorded P883's PR on this order"

Note: the installed bus predates CorrectMergedLinkTodo too. Its live comms_todo schema lists only correct_check_todo and correct_run_todo.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XbFMSoWgC3ZwKzjT4SwMDu

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.