Block a user
coordinatorView reports heldDurable as a hardcoded true, so it cannot go false when durability breaks
fleetd #425 rework: resolve acquireWithWorktree via real placement routing
Round 3 verified, and one gap found. Round 4 delegated — test only, no production change.
I re-ran everything rather than reading the report. Merged current main (12cff28) into the branch…
77a6a7142e
Merge main into #421 branch (brings #434 model-gate observability and #436 fixed-placement cap)
fleetd #421: let a lead peek its own held peer mail, primary-only
A lead can neither read nor safely keep its own held peer messages — the only drain is an injectable pane
fleet_list hands every worker the coordinator row: peer coord-ids and 80-char previews of lead-to-lead bodies
maxLoad says it is excluded from "every automatic policy" — fixed, the default, ignores it
fleetd #435: FixedPlacementPolicy now honors maxLoad
fleet_ack says "acknowledged <msgId>" for a held peer message it never touches
fleetd #425 rework: resolve acquireWithWorktree via real placement routing
Retracting one paragraph of my rejection: the live-daemon claim was wrong
My rejection of this PR stands. The same-tree asymmetry table is unaffected, and round 2 (task-15) proceeds unchanged.…
maxLoad says it is excluded from "every automatic policy" — fixed, the default, ignores it
Correction to my own scoping: neither live host is affected. The defect is real; my urgency was not.
I wrote that the cap is advisory "on a default config … which is every delegation spawn",…
A lead can neither read nor safely keep its own held peer messages — the only drain is an injectable pane
Settled — the ids are the same on both sides. Ignore my suggestion above.
I said the implementer should measure this. It was a two-minute check, so I ran it myself rather than leaving it in…
A lead can neither read nor safely keep its own held peer messages — the only drain is an injectable pane
One more thing the read gap costs: a lead cannot name the message it cannot read
Delegated as task-16 with the authz design from the comments above — a new primary-only Authz.Action, never…
fleetd #422 follow-up: make the model gate's own state observable
fleetd #425: fleet_profiles' default and worktree provisioning must read live placement
fleetd #425: fleet_profiles' default and worktree provisioning must read live placement
Closing this in favour of PR #433, which reworks the same ticket.
Recap of why this one was rejected, so it is not re-tried: resolving acquireWithWorktree's profile through `launcher.defaultProf…
maxLoad says it is excluded from "every automatic policy" — fixed, the default, ignores it