basquetWi + New ticket
llmmsg-srv MSG-353

blackboard: add-respondent op, newcomer joins the withheld gate

Done normal clcoder-llmmsgsrv-cc

Elazar directive relayed by coder-mars-cc 2026-09-05: blackboard_open fixes `expected` at creation and nothing can amend it. Real case: bb-coder-mars-cc-mtnvjn1c-4ykt7w opened with 4 respondents; audit-mars-cc registered 2 min later and had to be DM'd the question by hand, so its answer sits outside the entry, outside the completion set, and outside the write-before-read gate that makes the answers independent. Requirement: an add-respondent op. Design constraint: the newcomer joins the gate in the same withheld state as any respondent who has not written - it must never see already-written bodies. Note the existing predicate mayReadAll = status != 'open' || (hasWritten && !isOpener) already yields that for a fresh respondent, so no special case is needed and NO late-add cutoff is required. Second-order asks from coder-mars-cc: (a) opener cannot see WHO has written vs who is outstanding without closing the entry, so a stalled respondent is indistinguishable from a slow one; (b) expected names must exist in the roster AT OPEN, which blocked naming an agent Elazar had asked for by name before it launched. Work division: coder-llmmsgsrv-cc authors, pm-llmmsgsrv-cc gates+applies+deploys.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • wi-cli-venus created · 5w ago
  • wi-cli-venus verified · 5w ago
    Applied and deployed. Hub 2.56.0 live (restart 04:31Z), commit 3e275ca. Scratch hub on 19703 against a VACUUM copy, 9/9: add returns expected=[A,B,C]/notified=1; LEAK ASSERTION passed with a body already on the entry (C sees withheld:true, responses:[], question present); A's own-body view unchanged; opener sees written:[A] pending:[B,C] while a non-opener gets neither key; completion moved 2->3 and fired only on C's write; all six refusals returned their stated codes (bb_already_expected, bb_not_opener, bb_entry_closed, bb_unknown_respondent, missing_field, bb_no_entry); invite on an entry with 20s left quoted 20s, not 60; timeout notice counted the late-added C among the missing (0/3, names all three); CONTROL: the same POST against the then-unpatched production listener returned 404, so the suite exercised patched code. Coder's two spec corrections accepted and confirmed in situ - bbMaybeComplete needed no change, and the invite quotes remaining seconds. Not exercised: concurrent adds racing the CAS (single-threaded better-sqlite3 makes it unreachable in-process), and the shim tool is only reachable by sessions started after this deploy.
  • wi-cli-venus completed · 5w ago
    Deployed hub 2.56.0, commit 3e275ca.
feature
5w ago by wi-cli-venus
5w ago
2026-09-05 04:32