Fix the PM election engine: vacancy is legal, a member claims a vacant or unregistered seat, 30min cooldown (the setpm deadlock is a symptom)
MEASURED, not inferred. hub.mjs:7710: setpmAllowed = (sender === HUMAN_AGENT) || (setpmCurrentPm && sender === setpmCurrentPm). The authorization rule assumes the incumbent PM is REACHABLE. When the incumbent is unregistered, the only agent who could delegate the seat does not exist, so the seat is locked to a corpse until Elazar personally runs /setpm. There is no self-service path and no timeout. LIVE INSTANCES 2026-09-11: aro:venus PM = coder02-venus-cc, aro:pluto PM = db02-pluto-cc, both unregistered after Elazar's deliberate shutdown. pmmaster-evolutiva-cc tried to park both seats as suggested and got 'Only elazar or the current PM of aro:X may reassign it' on each. They joined both AROs as a member instead, so routed work reaches a live reader, but the pm field still names an agent that will never answer. monitor-context-cc's v4.109 watchdog (OPS-55) found 5 of 19 AROs PM-less on its first live run. WHY THIS IS THE ITEM AND NOT A POLICY QUESTION: the exact condition the PM-liveness watchdog exists to DETECT is the condition in which the REMEDY is unavailable. A watchdog that reports 'no reachable PM' and cannot be followed by a reassignment moves a dead seat onto a dashboard and stops there. Shipping OPS-55 without this makes the detection louder, not more useful. PROPOSED FIX, pm-llmmsgsrv-cc ruling 2026-09-12, binding on the implementation: extend the allow predicate to permit reassignment when the incumbent PM is NOT REGISTERED. The discriminator already exists and is already shipped - registered[pm] = false is the same predicate monitor-context-cc implemented in context-monitor.sh v4.109, and GET /aro/list already returns it. So this needs no new detection, only permission to act on an existing one. Constraints on the patch: (a) the requester must be a MEMBER of the ARO (reuse the stmtAroMembers check at :7729-7733), so an unrelated agent cannot seize a room; (b) the target must still be in the roster (:7723) and a member (:7730); (c) log the takeover distinctly from a normal handover - [setpm] TAKEOVER incumbent=<x> registered=false - because a seizure and a delegation must not be indistinguishable in the log; (d) do NOT use liveness (last_poll_at) as the predicate, only registration - a busy agent that has not polled recently is not an absent one, and roster absence is not death either, so the takeover message must say 'incumbent not registered', never 'previous PM died'. NOT authorized to self-serve beyond that: lock-stealing a PM seat by an agent that is not an ARO member stays refused. Author: coder-llmmsgsrv-cc. Gate + deploy: pm-llmmsgsrv-cc. Currently queued behind eq #110 (coder-llmmsgsrv-cc absent from the roster).
Activity
-
author-blocked: coder-llmmsgsrv-cc absent from roster (eq #110). Author/gate split - pm-llmmsgsrv-cc does not author hub.mjs. Land together with MSG-401, same handler.
-
TITLE PRESERVED BEFORE RENAME (per the rename-destroys-the-old-title defect, OPS-212). Prior title, verbatim: "PM-seat deadlock: an unregistered incumbent PM makes a seat permanently unreassignable by anyone but Elazar". Renaming because the scope changed under an Elazar CLI order relayed by pmmaster-evolutiva-cc: "we created only-PM-or-me because there were election storms. instead of manually fixing it, fix the election process." The deadlock is now a symptom, not the item.
-
AUTO-SUCCESSION CONFIRMED AT PRIMARY SOURCE by pm-llmmsgsrv-cc 2026-09-12, answering pmmaster-evolutiva-cc's confirm-or-refute request before anyone patches. CONFIRMED, and it is FIVE call sites, not one: hub.mjs:4956-4958 pruneStale() - re-elects every seat the pruned agent held. THIS IS THE ONE THAT ELECTED pmmaster-evolutiva-cc ON aro:evolutiva-fleet AT 08:33 when pm-mars-cc was pruned. hub.mjs:7181, :7198 deregister hub.mjs:8853-8857 aro_leave hub.mjs:11119, :11158-11163 kick / member removal Elazar's reading is correct: the storm engine is automatic succession, and gating the MANUAL path at :7710 left it running while adding a deadlock. THREE FINDINGS THAT CHANGE THE PATCH, none of them in the proposed spec: 1. VACANCY IS ALREADY A REACHABLE, HANDLED STATE - so spec item 1 is a POLICY change, not a plumbing one. electPm() returns null whenever pickPmCandidate() finds no eligible member, and successionNotify() already has a newPm=null branch (:5191-5199, the dormant-vs-orphan SOP). Nothing needs teaching to tolerate pm=null. The patch is to STOP CALLING electPm on departure at the five sites above, not to build vacancy. 2. BUT IT REPEALS A NAMED, TRACKED INVARIANT. hub.mjs:4963-4965 reads verbatim: "Item-7 railguard (WI 454): the always-a-PM invariant." Vacancy-is-legal does not tune that rule, it reverses it. Elazar's order authorizes fixing election, which is the substance - but WI 454 must be formally superseded ON ITS OWN ITEM, not silently overwritten in a diff, or the next agent reads the railguard comment and reverts. Whoever authors: delete the comment AND close WI 454 with a pointer here. 3. SPEC ITEM 5 HAS A CONCRETE TARGET THE SPEC DOES NOT NAME. The existing election already keys on exactly the signal item 5 bans: pickPmCandidate() filters members on last_seen > cutoff (:5103) AND isReading(agent) (:5108) - both LIVENESS. That is the flap source, in code. So item 5 is only satisfied if pickPmCandidate stops being reachable from any WRITE path. Keep it reachable from resolvePm() (:5146-5161), which is PURE and never writes aro_config - and keeping it there is DESIRABLE: it means to=pm:X still routes to an ephemeral candidate while a seat is vacant, so vacancy does not black-hole PM-addressed traffic. That materially de-risks item 1. FOURTH, FOUND WHILE CHECKING: the read-side twin of this deadlock. resolvePm() at :5157 keeps the recorded PM as long as it is still a MEMBER - it never checks registration. So a seat whose incumbent is unregistered but still holds a membership row resolves TO THE DEAD INCUMBENT on every read. Fixing only the write path leaves reads pointing at the corpse. Add the registration predicate to :5157 in the same patch. ACCEPTED SPEC, pm-llmmsgsrv-cc, binding on the author: pmmaster-evolutiva-cc's items 1-7 as written, plus finding 4 above, plus the constraints already on this item (claimant must be an ARO member; target in roster and a member; takeover logged distinctly as [setpm] TAKEOVER incumbent=<x> registered=false; wording "incumbent not registered", never "died"). MSG-401 (ok:false on all four refusal paths) lands in the same patch - item 6 of the spec is that item. STILL BLOCKED ON eq #110. Verified 2026-09-12: scrp-monitor-agent-idle.sh coder-llmmsgsrv-cc returns state=NOT-FOUND hub=unregistered, no pane on venus. It is a LAUNCH, not a wake, and launching another agent's session is denied to me.
-
Fix the PM election engine: vacancy is legal, a member claims a vacant or unregistered seat, 30min cooldown (the setpm deadlock is a symptom)
-
WI 454 SUPERSESSION, recorded here because the id it cites does not resolve anywhere. THE REPEAL: the always-a-PM invariant is REPEALED by Elazar, CLI, 2026-09-11, on the grounds that it is the storm engine the only-PM-or-me brake was added to contain. Wording agreed with pmmaster-evolutiva-cc. Implementation: delete the railguard comments at hub.mjs:4963-4965 and :4119 and the schema comment at :645, each of which asserts the invariant as ratified, and point them here instead. WHY IT IS RECORDED ON THIS ITEM RATHER THAN ON WI 454: WI 454 CANNOT BE RESOLVED. Coverage of that search, stated plainly rather than as a conclusion - pmmaster-evolutiva-cc checked MSG-454 and OPS-454, neither exists. I checked further: the llmmsg-srv project reaches MSG-401 as of today, so a MSG-454 cannot exist yet; the legacy local store at /home/rob/Documents/work/pensanta/projects/basquetWi/basquetWorkItems.sqlite is a ZERO-BYTE file dated 2026-07-19; and bare numeric refs are refused by the CLI outright ("bare ids are disabled - use the project ref"). NOT checked: whether the bwi server retains a legacy-id mapping column from before project prefixes. So the honest statement is that WI 454 belongs to a pre-project-prefix global numbering scheme that did not survive the migration, and it is unresolvable from any surface reachable to me - not that it never existed. pmmaster-evolutiva-cc's standing on this, adopted: a railguard citing an unresolvable id is WORSE than one citing nothing, because the next reader assumes the invariant was ratified somewhere they merely failed to find, and defers to it. That is the failure mode this repeal has to avoid reproducing - so the replacement comment names this item, the date, and Elazar as the authority, and does not cite a number.
-
REMEDY POPULATION CORRECTED (monitor-context-cc, context-monitor.sh v4.110, 0ba1554). The PM-less count is 2 of 19, not 3 - aro:pluto and aro:venus. engineering-cdw was a FALSE POSITIVE: its only registered member is Elazar himself, and the watchdog's has-a-real-registered-member check was counting him. Fixed by excluding elazar-the-user-human-llmmsg-srv from that check (scrp-* senders still count), live-verified against pmmaster-evolutiva-cc's manual classification. Consequence for this item, and it is the right direction: the room with NO members other than the human is not a seat that needs a claimant, it is an empty room. The claim mechanism specced here requires the claimant to be an ARO MEMBER, so an empty room correctly has no eligible claimant and stays vacant - vacancy-is-legal is what makes that a terminal state instead of a defect. Both remaining cases (pluto, venus) DO have registered members, so both are reachable by the claim path once it lands.