Blackboard: hard 480s auto-close ceiling (default, max, extend)
Elazar (CLI 2026-09-19, via audit-mba-l-cc): boards must auto-close after ~7-8 minutes tops. Today BB_TIMEOUT_DEFAULT_S=900 and BB_TIMEOUT_MAX_S=3600 (hub.mjs:1703-1705), open clamps to 60..3600 (:10154), and blackboard_extend may raise the deadline to that same 3600 ceiling measured from opened_at (:10492). Change = default and ceiling to 480s, and extend cannot reach past it. PREMISE CHECKED: close-at-deadline DOES fire when a respondent never writes - runBlackboardSweep (:11828) runs every BB_SWEEP_S=30s, and :11921 claims the timeout, DMs the opener with the missing agents and notifies writers; so the past problem was the LENGTH of the wait, not a sweeper that never fires. MEASURED on the live DB 2026-09-19, 78 boards all closed: complete n=63 avg 153s, max 776s, only 2 over 480s; timeout n=12 avg 974s, max 1816s, 9 over 480s; canceled n=3 avg 8s. So a 480s ceiling costs 2 of 63 successful boards a forced close and roughly halves the dead wait on every board nobody answers. Decide whether those 2 get a one-step extend or just lose.
Activity
-
audit-mba-l-cc ruling 2026-09-19 (Elazar delegated: 'do as you see fit'): option B, hard close at 480s, NO extend step. Cost 2 of 63 completed boards ever (3%). Condition attached: if MSG-408 (append-only writes) slips far behind this, revisit - hard close before append exists is the only combination where a late respondent loses its answer outright.
-
Diff authored, tested, NOT applied (waiting on an audit pass; audit-general-cc/-ca and audit-llmmsgsrv-cc all offline). /data-venus/llmmsg-srv/diffs/2026-09-19-msg411-blackboard-480s-ceiling.diff md5 516e754923be413b12add7e972d470f4, baseline @e1ebf3a hub.mjs 15ef653f21d38662dfc77c1a8103b3b2 + llmmsg-srv-mcp.mjs b4e136966513ff26dfd979abaddb511c. Harness: 2026-09-19-msg411-harness.mjs (same dir), 6 probes on a scratch hub. Patched: 6/6 pass. Control (unmodified e1ebf3a, second scratch hub): p1 3600 not clamped, p2 default 900, p3 wrong error code, p3b no at-ceiling text = 4 red, so those four discriminate; p4 (shrink guard) and p5 (120s board extends to 480) pass on BOTH and prove nothing about this change - they are regression cover only. NOT exercised: no board actually reached the 480s deadline in the harness (sweep close at the new ceiling is unproven, though the sweeper path itself is untouched); no open board existed on prod at authoring time, so the old-deadline-survives-restart case was not driven. APPLY ORDER: this diff must land AFTER /data-venus/llmmsg-srv/diffs/2026-09-18-shim-two-doc-guards.diff (both touch llmmsg-srv-mcp.mjs off the same baseline); if the other lands first, re-stamp this one before applying. hub.mjs change needs a hub restart, which stays pm-llmmsgsrv-cc's to sequence.
-
Diff 1 (2026-09-18-shim-two-doc-guards.diff, md5 9df6b550336b87fbf6333d46d1757a41) APPLIED to /opt/llmmsg-srv at 2026-09-19. Shim baseline moved: llmmsg-srv-mcp.mjs b4e136966513ff26dfd979abaddb511c -> 6717556f8c45c69a98537cc9a8c1c4b7. hub.mjs unchanged at 15ef653f21d38662dfc77c1a8103b3b2. MSG-411 diff (516e754923be413b12add7e972d470f4) re-verified with git apply --check against the new tree: clean, exit 0, hunks disjoint as audited. Diff stays UNAPPLIED - its hub.mjs half needs a restart and the shim half must not land alone (advertising a 480 ceiling the hub does not yet enforce). Rollback for diff 1: git show e1ebf3a:hub/llmmsg-srv-mcp.mjs
-
SHIPPED. Commit e3f07b9 on main, version 2.59.26 (read back from the running hub via register, not asserted). Files: hub/hub.mjs, hub/llmmsg-srv-mcp.mjs, package.json. Hub restarted twice: 06:34:55 (code) and 06:36:51 (to align the reported version with the bump, since the first restart preceded the commit) - pid now 2523428, active, 0 open boards at both restarts. audit-general-cc PASS on live state: working-tree diff vs e1ebf3a was line-for-line the union of the two audited diffs, node --check clean, no journal errors since 06:34. NOT exercised on prod: a live blackboard open/extend against the restarted hub, and name_warning from a fresh MCP session (shim changes load per-session).
-
completed