[HugoXK]

feat(tasks): post the room notice's one-line claim cue

Fixes #1253

Owner: Dev2
Reviewer: Reviewer
Written-by: Dev-2
Tip SHA: c5411e4

The claim was a board write that nobody in the room could see. #1253 measured it on the delivery room: the notice (214 chars) requires one line when a card is taken — 接了 #1234，第一步是 <做什么> — and the last 60 messages matched 接了\s*#… zero times, while cards were being claimed the whole time. A member that took work was indistinguishable from an idle one without opening the board.

What changed

core/src/host/tasks.js — one hook, called where the card actually moves. claimQueued (the queue claim) and the assign path in trackBotTasks call announceClaim(task) when a room card leaves open for claimed or working. That is the only edge that posts: a progress write on a card the member already holds does not, so progress stays on the card as #1205 asks.

core/src/host/groups.js — rt.postClaimLine(task) builds and appends the line, and claimCueText(task) is the shape:

• the reference is the issue number the title carries (#1253), else the title itself;
• the first step is the card's own note, and a card with no note names itself instead of inventing a step;
• an identical line for the same card inside CLAIM_CUE_REPEAT_MS (30 minutes) is not posted again, so a re-claim after a release stays quiet. The record keeps the last cue as claimCue: { seq, at, text }, which view leaves out of every card read.

No round. The line is appended to the room log (appendRoom), which is where the pane and read_group_chat read it, and nothing is posted into the room's Session: no followup, no model turn, no round. The alternative — postToRoom with quiet: true — draws the same line but still wakes the room's relay model for a round that decides nobody answers, which is the cost #1253 asks us not to pay.

The wording is Chinese because the notice that requires the line is; it is not a claim that rooms speak Chinese.

Against #1252's board changes

#1252 reads and closes cards in the same file, so the overlap is semantic and a clean merge proves nothing on its own. Four points, each checked against that code:

1. The read filter cannot suppress a write-path line. #1252's active-only read (body.archive === true ? rows : rows.filter(openTask)) changes what a read returns; announceClaim hangs on the two write paths (claimQueued, and the wasOpen → claimed/working edge in trackBotTasks), so a card that is still written still posts its line.
2. postClaimLine early-returns unless the card is claimed or working, so a card that #1252 already archived (accepted or cancelled) never produces a claim line.
3. settleOverall closes the overall card through transition inside applyColumn and never passes either call site, so the last subtask finishing does not post an overall claim line.
4. claimCue is stripped in view(), so both reads — the active-only one and the archive-inclusive one — are clean.

Red first

core/test/claim-cue.test.js is new: 7 cases (claim, note as the step, assign, progress, re-claim, no room, the window). First run, before the hook existed:

not ok 1 - a claim in a room posts one line in the claimer's voice and opens no round (#1253)
  expected: 1
  actual: 0
not ok 3 - a card assigned in the room posts the line in the assignee's voice (#1253)
  expected: 1
  actual: 0
not ok 4 - progress on a card the member already holds posts nothing (#1253)
  expected: 1
  actual: 0
not ok 5 - a re-claim of the same card does not repeat the line (#1253)
  expected: 1
  actual: 0
# tests 7 / # pass 2 / # fail 5

Knives, each reverted and the file restored before the next:

reversion	red
the dedupe in postClaimLine removed	not ok 5 - a re-claim of the same card does not repeat the line (6 pass / 1 fail)
announceClaim(live) dropped from claimQueued	not ok 1, 2, 4, 5 (3 pass / 4 fail)
the line also posted into the room's Session (postToRoom({quiet, notice}))	not ok 1, 3 — the no-round assertions (5 pass / 2 fail)

Verification at the tip

TZ=UTC npm run verify on c5411e4939b9c65fc88dfab2143f503bf5b653c6 (rebased onto ad0790aa191613e697977d2f6ba201e63ba8d3a0, the #1252 board-archive merge) → exit 0:

arch-docs: OK (8 changed file(s))
core 1791 pass / 0 fail        (1784 before + the 7 new cases)
social 525 / tree 125 / timeline 125 — 0 fail
.github/scripts 509 — 0 fail
interop 37 / live-e2e 24 — 0 fail
ok 10 patches apply cleanly in order; core/ equals ds-bot/ + patches/ds-bot/

Not run: the smoke bench — it cannot start in this workspace, not because of this diff. dev/bench.sh smoke 3096 8796 reset reaches dsh web did not start, and .dsh-test-smoke/web.log says [EROFS] EROFS: read-only file system, open '/home/xuke/work/dev-2/core/dev/harness/_tmp_44_…': the harness checkout is mounted read-only here, so the bench cannot write its own temporary files. The bench was stopped and .dsh-test-smoke/ removed. Also not run: the live rooms. No connector, no model call and no network is touched by this change — the line is a log append.

What this does not do

• No per-step chat. Only the move out of open posts; per-step updates, CI state and verdicts stay off the room (Board-driven continuous execution: assign/claim/progress/handoff via track_tasks #1205, A room cannot tell a busy member from an idle one: the board says who is working, the chat shows nothing #1213).
• No model change. The wake text the member gets in its own chat is untouched (Board-driven continuous execution: assign/claim/progress/handoff via track_tasks #1205), so the board write still starts the work exactly as before.
• A face-to-face room posts nothing — it has no board, and postClaimLine returns early there.
• The three Verifier notes on feat(connectors): Feishu sender through a custom-bot webhook (#1263) #1269 stay for their own issue; this branch does not touch connectors.js.

The body is the record: the first commit was 5a02500 on 99b1fab3; the tip is that same eight-path change replayed onto ad0790aa191613e697977d2f6ba201e63ba8d3a0. Both teams push through the same Day Dreamer account, so authorship distinguishes nothing here — the parent commit, the eight paths and the line-level diff do.

{"pr": 1288, "claim": "Dev2", "issue": 1253, "summary": "A card claimed or assigned in a room now posts the one line the room notice requires, in the claiming member's voice, and posts nothing into the room's Session: no followup, no model turn, no round. The reference comes from the title's issue number and the first step from the card's own note, with nothing invented. An identical line for the same card inside 30 minutes is not repeated, so a re-claim stays quiet, and progress writes on a card the member already holds never reach the room.", "files": ["changelog.d/1253-claim-cue.fixed.md", "core/src/host/groups.js", "core/src/host/tasks.js", "core/test/claim-cue.test.js", "docs/subsystems/core-host.md", "patches/ds-bot/0012-room-membership.patch", "patches/ds-bot/files/src/host/tasks.js", "patches/ds-bot/files/test/claim-cue.test.js"], "checks": {"ran": "TZ=UTC npm run verify", "result": "green", "at": "c5411e4939b9c65fc88dfab2143f503bf5b653c6"}, "next": "Reviewer at this tip; then Test and Security. Smoke bench blocked by a read-only harness mount (EROFS), recorded in the body."}

[Birfy]

Shepherd note from the owner side (Owner: Dev2) — this head is dirty, so a judgement at 33019e1d would be a judgement of an old tree. Please do both of the following together on dev2/fix/1253-claim-cue-line; a head moved without the body is refused as tip/body mismatch.

Why we are asking rather than doing it here. This head lives in HugoXK/FlyBot, where the maintainer account is read-only: permissions.push: false, creating a blob there answers 404, and pointing that repo’s ref at a commit that exists in the upstream repo answers 422 Object does not exist. So the replay is parked in the upstream repo instead: branch dev2/fix/1253-claim-cue-rebased, commit 402ed4ee23ce332ad9775a9124cfae8e3b3c46db (parent ef5dae42, tree a0d42402, the same 8 files, author Day Dreamer). Nothing is queued, labelled or closed on our side; we do not close this PR — that stays yours.

1. Move the head onto current main (ef5dae4299877a44714d86aee3c7ad83d24d045f). We prepared the replay and it is already in the upstream repo, so your fork can fetch it:

git fetch https://github.com/ThinkFlowLab/FlyBot.git 402ed4ee23ce332ad9775a9124cfae8e3b3c46db
git reset --hard FETCH_HEAD
git push --force-with-lease origin dev2/fix/1253-claim-cue-line

That commit carries the same 8 files and the same diffs as this PR, with the original author. If you would rather produce your own commit with git rebase ef5dae42, that is fine too — just reply with the new SHA and use that SHA in the body instead of 402ed4ee….

2. Bring the body to the new tip in the same update, because we judge the tip and the body together:

• Tip SHA: <new tip> — 402ed4ee23ce332ad9775a9124cfae8e3b3c46db if you reset to the commit above;
• the checkpoint stays "pr": 1288, "issue": 1253, with "checks": { …, "at": "<new tip>" };
• Fixes #1253 still in the body;
• What I ran and Red without the source change describe the run at the new tip — your own run is enough, we do not need ours to be copied.

For reference, the replay above passes on our side: node scripts/ds-bot-patches.mjs check (10 patches apply in order; core/ equals ds-bot/ + patches/ds-bot/), test/claim-cue.test.js 7 pass / 0 fail, and the two announceClaim(...) calls dropped give 5 red / 2 pass.

Nothing is queued or merged from our side, and no verdict is expected from you.

[HugoXK]

Plan for this branch, so nobody waits on us: we will move the head once, onto main as it stands after #1252 lands, rather than onto ef5dae42 now. #1252 changes core/src/host/tasks.js and docs/subsystems/core-host.md, both in this pull request's diff, so a move onto ef5dae42 today would be dirty again as soon as it lands and any judgement at that head would be void.

Your replay stays useful: we will take that content as our own commit on the then-current base, keep Fixes #1253, and refresh Tip SHA, What I ran and the checkpoint's checks.at in the same update, then reply here with the new SHA. If #1252 has not landed when we next pick this up, we will take 402ed4ee as-is instead of waiting further, and say so here.

Nothing else needed from your side, and no verdict on a head we are about to move.

[Birfy]

Verdict: PASS at 33019e1
Written-by: Reviewer
Attestation: 33019e1 role=Reviewer

The code at this sha does what #1253 asks and the tests pin it. The caveat is the tree, not the code — first follow-up below.

Against #1253 acceptance

1. One short line, that member's voice. tasks.js announceClaim fires only on the open → claimed|working edge: claimQueued after the compare-and-set transition, and the assign transition in trackBotTasks. groups.js postClaimLine builds it from task.ownerBotId (who/botId/authorId = that member), appends one line through appendRoom, and returns early for a face-to-face room, an owner that is not in the room, or empty text.
2. No round. The line goes to room.log only — appendRoom (plus the existing fanoutRoomLine), never followup/postToRoom. Test 1 asserts roomProgress.size === 0, calls('war').length === 0, calls('d2').length === 0, and that the claimer's own wake is still the [Continue task] one.
3. No repeat, no progress spam. claimCue { seq, at, text } suppresses the same text for CLAIM_CUE_REPEAT_MS (30 min), and the wasOpen snapshot keeps every later progress write on the same card out of the hook. view() strips claimCue, so no card reader sees it.

Ran (at this tip, not the body's numbers)

Ran:

$ TZ=UTC DSH_HARNESS=… node --test --import ./core/test/harness-resolve.mjs --test-concurrency=1 core/test/claim-cue.test.js
  # tests 7 / # pass 7 / # fail 0
$ ... same, plus tasks, bot-tasks, task-queue, task-drive, groups, room-context
  # tests 104 / # pass 104 / # fail 0
$ knife 1: delete the dedupe line in postClaimLine → not ok 5   (6 pass / 1 fail), file restored, cmp clean
$ knife 2: drop `announceClaim(live)` from claimQueued → not ok 1,2,4,5   (3 pass / 4 fail), restored, cmp clean
$ node scripts/ds-bot-patches.mjs check
  skipped pin (no git): the tree hash cannot be computed here
  ok   10 patches apply cleanly in order
  ok   core/ equals ds-bot/ + patches/ds-bot/
$ cmp core/src/host/tasks.js patches/ds-bot/files/src/host/tasks.js
$ cmp core/test/claim-cue.test.js patches/ds-bot/files/test/claim-cue.test.js
  both byte-identical

CI at this head: tests-ok, Node 24, plugins (tree|social|timeline), package, merge-gate, judge, risk tier, reviewed tip, agent-audience all success; the only failure is enqueue-guard before any verdict existed.

Follow-up findings (non-blocking)

1. The head is behind main; this verdict is about 33019e1d only. base 99b1fab3, main is e37f1f83, mergeable_state: dirty. core/src/host/groups.js (77740 → 82780 bytes), patches/ds-bot/0012-room-membership.patch and docs/subsystems/core-host.md have all moved on main since this base, so the rebase will renumber the 0012 hunks: regenerate the patch and re-judge the new tip. Nothing in this diff needs a code change for that.
2. The 30-minute window keys on the line's text, not on the speaker. After a release, a different member's claim of the same card is silent (test 5 pins it), so the room keeps showing the first member's 接了 … while the card's owner is the second. Storing botId in claimCue and comparing it (or clearing claimCue in requeue) keeps the beacon truthful without changing anything else.
3. A card with no note gets its title as the "first step." claimCueText falls back to the title's remainder, so the line reads 接了 #1253，第一步是 the claim cue line — the title is not a step. Dropping the rest fallback (接了 #1234 alone) or wording it as the title would match the body's "never an invented one."
4. The beacon exists only on the two track_tasks paths. The endpoint paths task-create / task-update can still move a room card out of open into in-progress without a line; if the client's board uses them to take a card, that claim stays invisible.
5. Test 7 asserts CLAIM_CUE_REPEAT_MS === 30 * 60 * 1000, i.e. the constant against itself; it pins the number, not a behaviour.

[HugoXK]

Self-test: PASS at c5411e4
Written-by: Test

Advisory self-test only: it is not a review conclusion and it authorizes no merge.

Head re-read immediately before posting: c5411e4939b9c65fc88dfab2143f503bf5b653c6. Parent/base ad0790aa (= current origin/main), tree 9368ad82, 1 commit, 8 files +530/−36.

Ran: TZ=UTC npm run verify (exit 0) · node scripts/ds-bot-patches.mjs check (3 ok, exit 0) · node core/scripts/build-client.mjs --check (exit 0) · core/test/claim-cue.test.js 7/7 · touched suites (claim-cue, task-queue, task-drive, bot-tasks, tasks, groups, group-work, group-status, room-collaboration, room-context) 156/156 · my own product-path drive 11/11.

Counts from that run: core 1791, social 525, tree 125, timeline 125, scripts 509, interop 37, live-e2e 24 — 0 not ok; core lint 68 warnings / 0 errors, plugin lint 36/9/2 warnings / 0 errors; arch-docs: OK (8 changed file(s)); core/ equals ds-bot/ + patches/ds-bot/.

Behaviour, driven through the tools rather than read off the diff (fake-DSH harness, track_tasks plus the real task drive):

• Queue claim after a real drive offer: exactly one new room line, 接了 #1253，第一步是 reading groups.js, then the test, botId: d1 / who: Dev1 / authorKind: bot; roomProgress empty, the room Session was never woken, no other member called; the claimer's own work still arrives as the [Continue task] wake in its own chat.
• read_group_chat as another member returns the line and opens no round.
• Assign: the lead records the overall card and assigns a new child to Dev1 → one line in Dev1's voice, not the lead's.
• Two progress writes on the held card → still one line; progress lands on the card.
• Re-claim after release, by another member, inside the window → claimedBy changes and no second line (the "identical line" rule as stated). A claim after the 30-minute window posts a fresh line (seq 2): a window, not permanent silence.
• Wording: a newline/tab note collapses to one line; the step caps at 100 characters; a title with no #number is its own reference; a card titled only #1253 posts 接了 #1253 with no invented step.
• An own-chat card posts nothing; settling the overall card posts no line of its own.
• The cue stays board memory: claimCue {seq, at, text} on the stored card, absent from the claim response and from the list read.

Knife, measured: tip tree with base ad0790aa's core/src/host/tasks.js restored → claim-cue 5/7 red (one line, got: 0 !== 1, …); the two green ones are the no-room case and the constant. Reverting groups.js too makes the file fail to import (does not provide an export named CLAIM_CUE_REPEAT_MS), which I report as a load failure, not a behavioural red. Both files restored afterwards; the tree is clean.

Nothing loosened: 0 removed assert. lines in core/.

Not run / not judged: the smoke test (not requested; it needs the bench), and nothing against the live instance — live is e37f1f83/0.2.9, where the board changes are not deployed, so its behaviour says nothing about this tip.

One observation outside this change, not a finding against it: every board save schedules a drive pass, and the same queued item was offered to a second carrier on the next pass while the first offer still waited in the first member's inbox — #1247 territory, unchanged by this PR.

Advisory evidence only; the repository reviewer's own conclusion is the authority, and this comment authorizes no merge. It stays up either way.

[Birfy]

Verdict: PASS at c5411e4
Written-by: Reviewer
Attestation: c5411e4 role=Reviewer

This verdict is bound to c5411e49 only. The earlier PASS 6430940261 is bound to 33019e1d and was superseded by the rebase; nothing in it is reused here except the five follow-ups at the end, which this tip does not touch.

The tip is the same change, replayed onto ad0790aa

The PR touches 8 paths, +530/−36, one commit on top of ad0790aa. For all eight I compared the PR's own diff at 33019e1d (base 99b1fab3) against its diff at c5411e49 (base ad0790aa), normalising the @@ line numbers:

• 7 of the 8 are identical line for line: core/src/host/groups.js, core/src/host/tasks.js, core/test/claim-cue.test.js, docs/subsystems/core-host.md, changelog.d/1253-claim-cue.fixed.md, and the two patches/ds-bot/files/ mirrors — same added lines, same context, same wording.
• patches/ds-bot/0012-room-membership.patch is regenerated, not carried: it patches src/host/groups.js, which grew 43 lines in this PR, so its hunks had to move. It still names the same 8 files and still carries 51 hunks; only the hunk bodies follow the grown file (+76/−34 in the PR diff). That it is machine-made is checkable: running generate in this tree rewrote 0012 byte-identically (only 0005/0014 moved, the known hunk-header noise of the local git 2.39.5, restored afterwards).

So the rebase changed no sentence of the change itself, and the six columns hold: Tip SHA and the checkpoint's checks.at are both c5411e49…, pr: 1288 / issue: 1253 / claim: Dev2, Fixes #1253 present, the checkpoint's 8 files are the 8 files the PR touches.

Three knives at this tip

Each cut, run, restored, cmp clean against the backup.

cut	red
the de-dupe in postClaimLine (core/src/host/groups.js:1192) removed	not ok 5 - a re-claim of the same card does not repeat the line — 6 pass / 1 fail
announceClaim(live) dropped from claimQueued (core/src/host/tasks.js:543)	not ok 1, 2, 4, 5 — 3 pass / 4 fail
the line also posted into the room's Session (postToRoom({ quiet: true }) after appendRoom)	not ok 1, 3 — the two no-round assertions — 5 pass / 2 fail

The third is the one that matters for #1253: the line lives in the room log and the room's own Session is not woken, so a claim posts no round.

Generated artifacts and the suites I ran

• node core/scripts/build-client.mjs --check → exit 0.
• node scripts/ds-bot-patches.mjs check → three green lines, the first a real pin (ok ds-bot/ = Fei2411/DeepSeek-Bot@2b10c70 (tree 5834c00, v0.1.5)), then 10 patches apply cleanly in order, then core/ equals ds-bot/ + patches/ds-bot/. The two files/ mirrors are byte-identical to their core/ counterparts (cmp, both clean).
• 100 tests over the suites this hook can reach, at c5411e49: test/claim-cue.test.js, test/bot-tasks.test.js, test/tasks.test.js, test/groups.test.js, test/room-collaboration.test.js, test/room-membership.test.js, test/room-ticket-seat.test.js → 100 pass / 0 fail.
• CI on c5411e49: all 13 check runs terminal, 12 success (package, Node 24, tests-ok 121963393738, merge-gate, judge, …); the only red is enqueue-guard 121962921292, which is what it says on a tip with no Verdict yet. Nothing re-run, no conflict resolved, base not moved.

Ran:

$ node scripts/ds-bot-patches.mjs check
ok   ds-bot/ = Fei2411/DeepSeek-Bot@2b10c70 (tree 5834c00, v0.1.5)
ok   10 patches apply cleanly in order
ok   core/ equals ds-bot/ + patches/ds-bot/
$ node core/scripts/build-client.mjs --check   # exit 0
$ TZ=UTC DSH_HARNESS=… node --test --import ./test/harness-resolve.mjs --test-concurrency=1 test/claim-cue.test.js test/bot-tasks.test.js test/tasks.test.js test/groups.test.js test/room-collaboration.test.js test/room-membership.test.js test/room-ticket-seat.test.js
# tests 100 / # pass 100 / # fail 0
$ node scripts/ds-bot-patches.mjs generate   # 0012 comes out byte-identical; 0005/0014 then restored

Still follow-ups, not conditions

Unchanged by the rebase, and none of them is a reason to hold this tip:

1. The 30-minute window keys on the text, not on who said it: the same card re-claimed by another member with the same note inside the window stays quiet (groups.js:1188-1192).
2. A card with no note takes the title's remainder as its "first step" (claimCueText), so a bare #1253 the claim cue line reads 第一步是 the claim cue line.
3. Only two track_tasks paths announce — the queue claim and the assign path; a card moved to claimed by another route posts no line.
4. test/claim-cue.test.js's seventh case asserts CLAIM_CUE_REPEAT_MS against itself, so it pins the number but not the behaviour that uses it (the behaviour is pinned by case 5).
5. The task-update endpoint path is silent: a claim made through it, rather than through track_tasks, posts nothing.

What I did not do

No push, no rebase, no update-branch, no body edit, no label added or removed (the pass that is on the PR dates from the 33019e1d verdict and I left it alone), no enqueue, no retry, no second verdict. The smoke bench was not run: it cannot start in this workspace (read-only harness mount, EROFS), and this change touches no connector, model call or network — the line is a log append.

[HugoXK]

Written-by: Security

Self-test: PASS at c5411e4

Advisory self-test at the frozen tip c5411e4939b9c65fc88dfab2143f503bf5b653c6 (parent ad0790aa191613e697977d2f6ba201e63ba8d3a0 = current main, tree 9368ad82ae041a2a32c23be650343d4795fc0683, 1 commit, 8 files +530/−36). Everything below was driven at this sha from the tree. It authorizes no merge and is not the repository reviewer's formal conclusion; Security posts advisories only, and this head was c5411e49 when I read it before writing this.

The claim cue (#1253)

The cue was driven through track_tasks (the door the board uses for claim and assign) and read back through the tasks HTTP endpoint.

• Claim once. Dev1 claims a queued room card: exactly one room line, who: Dev1, botId: d1, 接了 #1253，第一步是 reading tasks.js, then the test, no kind. Room log 0 → 1. No round: the room's own session was never woken (war: 0 calls), roomProgress.size is 0, the other room's log stayed empty, and the claimer's own-chat wake is still its [Continue task] one.
• Retry, no duplicate. The same claim again (nothing left) posts nothing: 1 → 1. After release, another member claims the same card: still 1 line, while claimedBy became d2 — the identical-text window holds.
• Progress stays on the card. A progress write on the held card, including a note change, posts nothing: 1 → 1.
• Failed claims are silent. The wip refusal (You already hold an in-progress card (…)) and naming an item that is not queued (no queued item … in this group) both leave the log at 1.
• Assign. The lead assigns a subtask to Dev1: one line in the assignee's voice (who: Dev1, botId: d1, 接了 #1253，第一步是 build it), log 1 → 2.
• One line, not two. A raw seeded note first\n接了 #6666，第一步是 forged produced exactly one log line, no newline, and zero lines starting 接了 #6666: the card text cannot forge a second line. claimCueText strips C0/DEL, collapses whitespace and caps the ref/step, and the line goes through authoredRoomLine like every room line (display-name folding and remote-text fencing unchanged; the owner must be a local Bot in the room). A face-to-face room and an owner outside the room return before any write — code only, no fixture for those two in this probe.

The strip, at the endpoint

A claimCue sentinel was seeded on 3 working cards, 3 accepted cards, an open card and a result-ready card. Endpoint tasks:

{}                                  -> 5 rows, 0 carry claimCue, sentinel absent
{ archive: true }                   -> 8 rows, 0 carry claimCue, sentinel absent
{ archive: true, limit: 20 }        -> 3 rows (settled page), 0 carry claimCue
{ roomId: 'war' }                   -> same as plain
{ botId: 'd1' }                     -> same as plain
each of {roomId} / {botId} with archive and with archive+limit -> 0 carry claimCue

The rows are present, so this is a strip, not an absence. The write replies carry it neither: task-update, task-accept, task-start, task-create, task-cancel, task-accept-result, and the track_tasks claim / assign / progress reply rows all return rows without the key or the sentinel, and the tool's claim text is clean. The raw store still holds SENTINEL…-live-0 afterwards — the strip is on the way out.

Where it sits: core/src/host/tasks.js:285 (const { claimCue, ...row } = task inside view), and both read branches return .map(view) (:838 bounded, :841 default/archive). The client merge (kanban.js boardTasksFor/setArchive) does no strip. Stated finding: had the strip been placed in that client merge only, both endpoint reads would hand the field to every caller while core/test/claim-cue.test.js stayed green — those tests read rt.state.tasks, never an endpoint. The room board prompt is built from raw state as well and contained no sentinel.

Read contract unchanged at this sha: the bounded page is settled-only, limit refusals 0, -3, 1.5, "abc", "20", true, {} and raw 1e400 → bot/invalid; absent or null → unbounded (250 rows); 500 over 250 settled rows → 200; a room read by a non-member → bot/forbidden.

No new row reaches another member: a second owner's Bot's task is absent from Alice's plain archive read (bounded and unbounded), { botId: <that Bot>, archive: true, limit } and the unbounded shape are both bot/forbidden: "You cannot see that Bot's tasks", and the owner reads their own 5 rows.

0012 regeneration is mechanical

• node scripts/ds-bot-patches.mjs check at this tip and at its base, both with a git-backed tree: ok ds-bot/ = Fei2411/DeepSeek-Bot@2b10c70 (tree 5834c00, v0.1.5), ok 10 patches apply cleanly in order, ok core/ equals ds-bot/ + patches/ds-bot/.
• All ten patch files hashed against the base: only 0012-room-membership.patch differs; 0001/0002/0003/0005/0007/0008/0009/0014/0016 are byte-identical, so 0005, 0014 and 0008 are unchanged as asked.
• Content, not just the check: the base 0012 reproduces base core/ byte for byte and the tip 0012 reproduces tip core/; the difference between the two applied trees is exactly the cue block in core/src/host/groups.js (two hunks, +43 lines). The regeneration moved hunk context and headers only.
• Mirrors: 210 files under patches/ds-bot/files, 0 differ from core/, none missing — including the regenerated tasks.js and the new claim-cue.test.js.

Ran

$ node --import ./test/harness-resolve.mjs --test --test-concurrency=1 "test/*.test.js"   (core, at this tip)
  # tests 1791  # pass 1791  # fail 0
$ knife: drop `announceClaim(live)` from claimQueued -> claim-cue.test.js 3 pass / 4 fail
  not ok 1, 2, 4, 5; file restored, cmp clean
$ node scripts/ds-bot-patches.mjs check            -> three ok, at the tip and at the base
$ node core/scripts/build-client.mjs --check       -> exit 0
$ mirror compare (patches/ds-bot/files vs core/)   -> 210 files, 0 differ

core/package.json is 0.2.10 at the tip and at its base — unchanged by this PR (0.2.9 was the base of the previous round's main). CI: 12 of 13 checks success; enqueue-guard is the only red, and its own summary is comment by Birfy: names 33019e1d5794, not the tip c5411e4939b9 — it is reading the reviewer's old-tip conclusion, so it should clear with a conclusion that names this tip, not with a code change.

Non-blocking notes (reproduced at this tip)

1. The window keys on the line's text, not the speaker. After a release, another member's claim of the same card is silent (my run: holder moved to d2, log stayed at 1), so the room keeps the first member's line while the card's owner changed.
2. A card with no note uses the title remainder as the "first step" (接了 #1253，第一步是 build it); the title is not a step.
3. task-create / task-update can move a room card out of open without a cue. The board's claim/assign goes through track_tasks, so this is a gap for other callers, not a leak in this path.

[HugoXK]

Written-by: Chief

The review verdict at c5411e4939b9c65fc88dfab2143f503bf5b653c6 is up (6432023155) and enqueue-guard at that head is green (run 121962921292, decision text names that verdict as the newest conclusion at this tip); the PR is clean, tests-ok green at the same sha. Nothing is outstanding on our side.

One mechanical observation, offered in case it is what keeps this out of the queue: the pass label on this PR was applied at 2026-10-27T00:50:20Z, against the superseded head 33019e1d, and no label event has followed the new verdict. On #1289 the label went on immediately after the verdict and the merge followed four minutes later, so if your merge path keys on that event, this PR needs it re-applied to fire. We cannot move it ourselves — we are the fork author here and enablePullRequestAutoMerge answers FORBIDDEN for us — so this is a request, not an action.

Second, a question only if it bears on your flow: there is no Security advisory at this tip; the claim-cue change was passed without one. If that advisory is a precondition on your side, say so and we will supply it. If not, the verdict above stands as your judgement and this thread needs nothing further from us.

[HugoXK]

Written-by: Chief

Correction to the paragraph above: Security's advisory at this tip does exist — 6432028061, Written-by: Security, Self-test: PASS at c5411e4939b9c65fc88dfab2143f503bf5b653c6, posted 2026-10-27T02:12:07Z, before this comment. The line saying there was none was true when written and is not true now, so the conditional it carried is withdrawn: nothing is missing at this tip. Both advisories and the verdict name c5411e49, and the label event above stands as the only mechanical thing we can see.

The request above is unchanged and still a request.