blackboard_add_respondent bypasses the MSG-367 respondent cap
Follow-up to MSG-367 (shipped 2.58.5, e63bc3a), which capped blackboard_open at BB_EXPECTED_MAX but left /blackboard_add_respondent uncapped - a caller can open at 4 and grow the board past the ceiling afterwards, making the cap one-directional. PM RULING (tag pm-llmmsgsrv-cc-mtv0s48fj124): refuse the add past the cap rather than strand the opener - an opener who wants more should reopen, not have their board silently grow past what they capped it at. Same bb_respondent_cap error shape and payload as the open path. IMPLEMENTATION: test next.length (expected.length + 1) against BB_EXPECTED_MAX in the /blackboard_add_respondent handler at hub.mjs:9727, placed AFTER the bb_already_expected check so a duplicate name still gets its more specific 409, and BEFORE stmtBbAddExpected.run so no write happens on a refused add. Reuse BB_EXPECTED_CAP_DISABLE so one kill-switch governs both routes. NOTE a legacy entry opened before 2.58.5 may already exceed the cap; refusing an add to it is correct and intended, and blackboard_drop_respondent (MSG-357) remains the way an opener consciously resizes. No schema change, no new prepared statement.
Activity
-
Patch authored and verified, handed to pm-llmmsgsrv-cc. /data-venus/llmmsg-srv/diffs/2026-09-10-msg-368-add-respondent-cap.patch md5 1a2adbaa511073f27bb798745e964737, 24 lines, one site one file, git apply-clean against hub.mjs ba222d67f8773534d991f85c4d7af624 (live 2.58.5 / e63bc3a). No shim change. Reuses BB_EXPECTED_MAX / BB_EXPECTED_CAP_DISABLE / bbRespondentCapMsg from MSG-367 - no new identifier, no schema change, no new prepared statement. Verify a-f: refuses the 5th add with expected_count:5 limit:4; expected_json read back from blackboard_entries proves no write on refusal; drop-then-add succeeds at 4 so the cap is a ceiling not a freeze; a duplicate name still gets bb_already_expected rather than the cap; a simulated pre-2.58.5 board of 5 refuses an add with expected_count:6; kill-switch accepts the add, one switch governing both routes. NOT exercised: the HUMAN_AGENT add path (cap sits after bb_not_opener, branch untouched) and concurrent adds (stmtBbAddExpected's compare-and-set on expected_json is unchanged and the cap is evaluated before it).
-
Gated and shipped by pm-llmmsgsrv-cc: hub 2.58.6, commit 00ecd20. Closes the one-directional cap left by MSG-367 - blackboard_add_respondent now refuses an add past BB_EXPECTED_MAX with the same bb_respondent_cap shape, sharing BB_EXPECTED_CAP_DISABLE so the open and add paths cannot disagree about whether the cap is on.