blackboard costs 4 turns where 2 would do - the 300-char question truncation forces a read, and blackboard_write should return the others
A blackboard answer currently costs a respondent FOUR turns: the alert arrives, blackboard_read for the full question, blackboard_write, blackboard_read again for the others. Measured cost driver (pmmaster-evolutiva-cc's board A, mars): 608k cache_read over 4 turns = ~152k per turn against ~16k net-new, i.e. 97.4% of the cost was the agent re-reading its own standing context, content-blind. Cost = turns x standing context. The question body, the responses and the hub round trips are rounding error. So the lever is TURN COUNT, and two of those four turns are pure ceremony. (a) STOP TRUNCATING THE QUESTION AT 300 CHARS IN THE NOTIFICATION. The notification body truncates and then instructs the recipient to call blackboard_read for the full text. That truncation saves ~300 tokens of net-new and COSTS a full turn, ~152k cache_read - a 500x net loss, and it is the exact failure class already recorded fleet-side: optimizing the visible number and paying the invisible one. Deliver the whole question. If a cap is wanted at all it belongs at the payload sizes where it would actually bite (the ~600KB break-even where a file carrier starts to win), not at 300 chars. (b) blackboard_write RETURNS THE OTHER RESPONSES IN ITS OWN RESULT. The write-first gate is satisfied at the instant of the write, so the hub already knows the caller is now entitled to read - making them spend a separate blackboard_read turn to be handed data the hub held in that same call is ceremony. Return the same payload blackboard_read would have returned; responses arriving later stay fetchable as today. Net: 4 turns -> 2, ~1.2M cache_read saved per 4-agent board. WATCH-OUTS for the gate: - (b) must NOT change who may see what. The opener still sees bodies only on close, and a DECLINED agent still never sees them - the existing exceptions in blackboard_read. Re-use the same authorization path rather than re-deriving it at the write site. - A write refused with bb_already_written must NOT return responses as a consolation - that would make a second write a cheaper read than the read. - Do not make the empty case ambiguous: writing as the FIRST respondent must return an explicit empty-responses marker, not an absent field, so 'nobody has written yet' is distinguishable from 'the field was not populated'. - (a) touches the notification text only; do not widen it into a change of what blackboard_read returns. Lane: author the diff with proof, hand to pm-llmmsgsrv-cc to gate and deploy. Never applied by the coder.
Activity
-
PARKED, NOT STALLED - installed and running on the live hub since 17:02 ART, unpushed, blocked on venus-host.push-gate (coder-pluto-cc holds it 3600s from 1789147209). Nothing is half-applied: both files are fully installed, node --check clean, db.prepare count 277 unchanged, and the running hub is serving this code. Live hub md5s hub/hub.mjs 7ea9d9a26d54ec59a13428849ee7f3b5, hub/llmmsg-srv-mcp.mjs 3801567dd9e2af7bc960cab1a03b669c, over baselines ba2389ab119e96e1f2bffd1f8446ab4d / 330042d567c248d96c45eeb61e951ac6 at 248cd3b v2.59.10. The only outstanding step is publication. RESUME EXACTLY HERE - the push command is durable and needs no retyping: cd /opt/llmmsg-srv && gitpush.sh --patch --only hub/hub.mjs,hub/llmmsg-srv-mcp.mjs,package.json,.gitpush-pre.sh "$(cat /tmp/claude-1000/-home-rob-agents-pm-llmmsgsrv/1cb70ae2-bff6-4cfc-8119-9e3c7f928a72/scratchpad/msg391/commitmsg.txt)" Take venus-host.push-gate by hand through the hub lock tool FIRST - gitpush acquires last, after its handshake and preamble, and loses the window. .gitpush-pre.sh must stay in --only or the shared tree stays dirty for every other agent. THEN, in order: second restart (gitpush bumps package.json, so the first restart's announced version is already stale) -> confirm the journal prints [source-integrity] state=clean tree=clean -> unlock hub/hub.mjs -> unlock venus-host.push-gate -> wi status MSG-391 done -> report to coder-llmmsgsrv-cc and pmmaster-evolutiva-cc that it is pushed and working, per Elazar's order. If the scratchpad is gone by then, the commit message is reconstructable from this row plus the gate doc at /data-venus/llmmsg-srv/diffs/2026-09-11-msg-391-blackboard-turn-collapse.md; the md5s above are the part that is not. MSG-380 verified in production while parked: the 900s dirty-boot deferral fired at 14:17 hub-clock and DM'd exactly once, naming tree=DIRTY(.gitpush-pre.sh,hub/hub.mjs,hub/llmmsg-srv-mcp.mjs). That is the feature behaving as shipped against a real dirty tree, not a test fixture.
-
INDEPENDENT BYTE-FOR-BYTE CONFIRMATION of what is running live, from coder-llmmsgsrv-cc at 14:22, unprompted and not a re-run of my own check. They applied the 391 patch to a CLEAN 248cd3b clone and got hub/hub.mjs 7ea9d9a26d54ec59a13428849ee7f3b5 and hub/llmmsg-srv-mcp.mjs 3801567dd9e2af7bc960cab1a03b669c - the exact md5s of the files installed and serving on venus. That closes the one gap in this gate: the artifact they tested and the artifact I applied are the same bytes, established from two independent trees rather than asserted. It is also the cross-check I asked them to make standard in future gate docs, and they have applied it to the MSG-393 and MSG-394 docs already. Post-apply ladder for the stacked diffs, measured by coder-llmmsgsrv-cc, order-independent within a set (394->391->393 lands on the same bytes as 391->393->394) - use this to gate 393 and 394 against MY tree, never against their .md baseline stamps: 248cd3b+391 7ea9d9a26d54ec59a13428849ee7f3b5 / 3801567dd9e2af7bc960cab1a03b669c <- live now 248cd3b+391+393 3e74005b6286cf61c648edf4b397dbcf / 3801567dd9e2af7bc960cab1a03b669c 248cd3b+391+393+394 6e73ec3276ae1836e270cc966e752ab4 / 3c18e1b3a8e6c0532ef376b7f0157ad6 MSG-393's own doc still carries the pre-391 stamp ba2389ab; that is a WRONG STAMP, not a broken patch - it was confirmed to apply clean onto the current tree.
-
SHIPPED. Pushed 2026-09-11 22:05 as commit 4e9814f, hub v2.59.11. Second restart done; journal prints [source-integrity] state=clean head=4e9814f branch=main version=2.59.11 ahead=0 behind=0 tree=clean. Live md5 at push: hub.mjs 7ea9d9a26d54ec59a13428849ee7f3b5, llmmsg-srv-mcp.mjs 3801567dd9e2af7bc960cab1a03b669c - identical to the bytes gated and to coder-llmmsgsrv-cc's independent apply from a clean 248cd3b clone. Push gate taken by hand first, so gitpush printed 'NOT releasing ... held it before this run'; both locks released after. Shim tool-description half stays inert until each session restarts; the hub half is live now. Post-apply md5 ladder for MSG-393/394 is in the earlier note on this row - gate those against the ladder, not their .md baseline stamps, which predate 391.