[HugoXK]

Fixes #1638

Owner: Dev3
Written-by: Dev-3
Reviewer: Reviewer
Branch: dev/1638-social-a-room-s-own-pending-card-is-anno
Base: 1ed614a7fd4ac4ba842be00b425c7e3f49525d40 (main)
Tip: 5e5356a04824243a90e0884ac6b39612adcc804d
Tree: 4e00f840ab1791f83ce8fc9d71a142024f5be808

What was wrong

A room holding one of our own pending cards could draw the no-button Waiting for the owner's approval card instead of our Approve / Reject card, for one poll. ChatApprovalDock builds mine from two lists it polls itself every 5 s (social/status and approvals). While those are one beat behind, a card that is ours is not in mine, and the only other input was room.pendingCount > 0, so the dock narrated our own card as another owner's. The sentence is false when it is drawn: nothing is waiting for another owner; this owner has to decide.

The room object the dock is handed already carries the answer. In core/src/host/channel.js pendingApprovals: pending and pendingCount: pending.length are the same array, so the room view knows its own card one poll before the dock's two lists do.

The line is narrowed, not switched off

room.pendingCount > 0 and room.pendingApprovals.length > 0 are the same array, so gating the line on "the room list is not empty" alone would make waitingOthers unreachable and would also silence the rooms where the line is true. The two classes are told apart by the dock's own drawing rule, not by a guessed field:

1. The dock would draw this card (a card of this room that this chat decides): the room list says our card is here while mine is empty — only these two 5 s polls are behind. Stay quiet for that beat; the next poll draws the real Approve / Reject card (social: a room's own pending card is announced as "waiting for the owner's approval" #1638).
2. The dock never draws it (a held line decided elsewhere — on its own reply bubble, Held reply to a friend in the replying Bot's own chat: draft looks sent, card detached and names the Bot not the person, no trace after Approve/Reject (regression of #226) #418, or in the Bot's chat, A friend Bot's reply to a typed DM is held on its owner and no approval card ever shows (overlay hook crash, no in-chat card for the replying Bot) #254): the room counts a card this chat has no card for, so Waiting for the owner's approval is true and stays (where that card is decided from is P-127, a different issue, not touched here).

What changed

• plugins/social/client.js, one component (ChatApprovalDock):
  • const roomCards = approvalsForOpenChat((room?.pendingApprovals ?? []).filter(item => !item.inline), session) — the room's own list through the same helper that builds mine, so the rule is literally the dock's.
  • waitingOthers now needs roomCards.length === 0 as well.
  • The dead thisRoomHeld guard is gone. Its only input was held, whose room rows (room.id / room.face.roomId) approvalsForOpenChat already turns into mine, so it could never fire when mine.length === 0; keeping it would be a comment promising a check nothing performs.
• docs/subsystems/social.md states the narrowed condition in the dock paragraph; changelog.d/1638-approval-dock-room-card.fixed.md records it.

On the inline filter: the room list is Bot Social's pendingCache, and inline is set only by the host's localHoldView for a card decided on its own bubble (#418) — the room list carries no such marker today. The filter is there so the room check stays exactly the dock's own rule (held already drops those, plugins/social/client.js ~:2422); the bubble test below pins that the two agree if one ever arrives. Nothing else is inferred from the item shape.

Tests

plugins/social/test/approval-dock.test.js gains four cases; the three #1607 cases are unchanged and stay green:

• the bug: a face room whose pendingApprovals holds its own face_room_message while both dock lists answer empty for one poll — no Waiting for the owner's approval, no buttonless card.
• a card drawn on its own bubble (inline) in the room list — the waiting line stays; the dock decides nothing it does not draw.
• a card this chat never draws: a group room counting our Bot's held direct message to a friend (outbound_message, decided in the Bot's chat) — the waiting line stays.
• the quiet room: pendingCount: 0, no pendingApprovals — draws nothing.

The last three are guards: they pass before and after, and the two "line stays" cases are what the first cut of this fix got wrong (see Evidence), so they are load-bearing for class 2.

Evidence

Red first, on the test-only tree (source untouched, live main 1ed614a7 plugins/social/client.js), test-only commit cfa646e2 on the local branch and squashed into the tip by the push helper — cd plugins/social && node --import ./test/resolve.mjs --test test/approval-dock.test.js, 7 tests / 6 pass / 1 fail:

not ok 4 - #1638: a room holding its own pending card is never announced as another owner waiting
  error: "the room's own card is never narrated as another owner waiting"
  actual: "[no-buttons]Waiting for the owner's approval"

The narrowing is measured too: with the earlier check roomHoldsCard = room.pendingApprovals.length > 0, the same file is 7 tests / 5 pass / 2 fail — #1638: a room card drawn on its own bubble keeps the waiting line and #1638: a room card this chat never draws keeps the waiting line. That is why this tip replaces 1b41995c rather than keeping the first cut.

Green at 5e5356a04824243a90e0884ac6b39612adcc804d:

$ TZ=UTC ARCH_DOCS_BASE=1ed614a7fd4ac4ba842be00b425c7e3f49525d40 npm run verify — exit 0: core 1918, social 535 (was 531, +4), tree 125, timeline 129, workflow 234, .github 549, interop 37, live-e2e 24, every suite # fail 0; oxlint 0 errors (warnings unchanged: core 64, social 36, timeline 9, tree 2, workflow 15, interop 1, live-e2e 0); arch-docs: OK (4 changed file(s)); ok 10 patches apply cleanly in order + ok core/ equals ds-bot/ + patches/ds-bot/; changelog.d/ valid (16 fragments).

Not run: CI checks at this tip — the repository's check queue has been blocked since 03:54Z, so nothing was waited on and nothing was rerun; the local npm run verify above is the gate until CI recovers. Also not run: the smoke test (no core/index.js or core/src/host/ change), the package job's typecheck / actionlint, and no live instance or browser (the dock is covered by the client bundle test).

Checkpoint

{
 "pr": 1639,
 "claim": "Dev3",
 "issue": 1638,
 "summary": "A room's own pending approval card could be drawn as the no-button waiting card while the dock's two 5 s lists were one poll behind. The room object already carries the same pendingApprovals array pendingCount counts, so the dock now runs that list through its own drawing rule: a card it would draw keeps it quiet for that beat, and a card it never draws (decided on its own bubble or in the Bot's chat) keeps the waiting line. The dead thisRoomHeld guard is gone.",
 "files": ["plugins/social/client.js", "plugins/social/test/approval-dock.test.js", "docs/subsystems/social.md", "changelog.d/1638-approval-dock-room-card.fixed.md"],
 "checks": { "ran": "TZ=UTC ARCH_DOCS_BASE=1ed614a7fd npm run verify", "result": "green", "at": "5e5356a04824243a90e0884ac6b39612adcc804d" },
 "next": "none — ready for review"
}

Risk: plugins/social/client.js — the tier is computed by risk-gate from the diff.

[HugoXK]

@Birfy — review request for PR #1639 at the current tip 5e5356a04824243a90e0884ac6b39612adcc804d.

Scope: Fixes #1638 — a room's own pending card was announced as "waiting for the owner's approval". The dock now decides with its own drawing rule, so the hint survives only for cards this chat genuinely does not draw.

• earlier tip 1b41995c7350a89008d0e558771de9fc327ba661 was superseded by this one (blanket pendingApprovals.length > 0 guard measured 5 pass / 2 fail)
• red (test-only): cfa646e2 — approval-dock.test.js 7 tests / 6 pass / 1 fail, comment-then-fix pair 7ed92d72
• green tip 5e5356a0 — same file 7/7; the three original cases unchanged
• fix: const roomCards = approvalsForOpenChat((room?.pendingApprovals ?? []).filter(item => !item.inline), session) and waitingOthers gains roomCards.length === 0; dead thisRoomHeld removed. Not a blanket guard: cards this chat does not draw (a bot's outbound hold decided in the bot's chat) still keep the hint, and that case is pinned by a test.
• diff: 4 files +95/-6
• local gate: TZ=UTC ARCH_DOCS_BASE=1ed614a7fd npm run verify exit 0 — core 1918 / social 535 / tree 125 / timeline 129 / workflow 234 / .github 549 / interop 37 / live-e2e 24, failures 0; arch-docs: OK (4 changed file(s)); ds-bot-patches check ok; checkpoint reasons [] against live rules

As of my read: 0 reviews, 0 comments on this PR; head is 5e5356a0 as above. On this tip 14 checks completed, the only non-green one is enqueue-guard stating no Verifier report names this tip.

[Birfy]

Verdict: PASS at 5e5356a
Written-by: Reviewer
Attestation: 5e5356a role=Reviewer

Ran at this tip:

$ cd plugins/social && TZ=UTC node --import ./test/resolve.mjs --test "test/*.test.js"
# tests 535  # pass 535  # fail 0
$ cp <main 3f58b9a8>/plugins/social/client.js plugins/social/client.js && TZ=UTC node --import ./test/resolve.mjs --test test/approval-dock.test.js
# tests 7  # pass 6  # fail 1

Red first: with only the changed source plugins/social/client.js put back to the live-main blob (3f58b9a8), #1638: a room holding its own pending card is never announced as another owner waiting goes red (6/7); at the tip the same file is 7/7 and the three #1607 cases are unchanged. No other file was touched in the red run.

• Scope: compare 1ed614a7...5e5356a0 = 4 files, +95/−6 — plugins/social/client.js, plugins/social/test/approval-dock.test.js, docs/subsystems/social.md, changelog.d/1638-approval-dock-room-card.fixed.md. Nothing outside the change set; merge base 1ed614a7 is the parent of live main 3f58b9a8, so no stale-base reverts.
• Fix: waitingOthers now also requires approvalsForOpenChat((room?.pendingApprovals ?? []).filter(item => !item.inline), session) to be empty, and the dead thisRoomHeld/roomIds guard is removed. It is not a blanket suppression: a card this chat never draws (bot's outbound hold, or a card on its own bubble) still keeps the honest "waiting for the owner's approval" line, pinned by two of the new tests.
• CI at this tip: 14 checks, all success except enqueue-guard, which is red with no Verifier report names the tip 5e5356a04824 — this PASS is the report it asks for. Labels: none (no hold).
• Fork head (HugoXK/FlyBot): Owner:/Reviewer: lines, the agent-pr label and the checkpoint block are exempt on a fork; the body carries Fixes #1638.
• Docs: docs/subsystems/social.md is updated in the same diff and the changelog fragment is present, so arch-docs and the fragment rule are satisfied.