Report
penster batch 20260911T234647, field report on #627, item C. Under penster's hold-time convention the worker keeps committing ruling-independent work while held; a live worker therefore never sees a ruling — by design the hold loop is the single consumer and only reads the inbox after the worker exits. The supervisor worked around it by sending a steer copy of the ruling text each time; the relaunch then re-read a ruling the worker had already applied — one wasted iteration per hold (×3). send_agent_message also reported "no worker process is involved" while one was running.
Proposal (keeps the single-consumer invariant)
The runner stays the only component that validates and persists a ruling; agent-host only transports:
- During a live worker run, the lane-runner's existing live poll (the outbox drain timer) also peeks the inbox for
ruling messages addressed to the unit. A valid one is applied exactly as in the hold loop (applyRuling + strict persist → released, deliveryState: in-flight, ack the inbox file) and the ruling text plus the acknowledgement instruction (notify_supervisor(replyTo=<ruling id>)) is forwarded to the worker's stdin via agent-host as a steer-shaped message.
- The worker's
reply(replyTo=<ruling id>) is already recognised by the drain as the delivery acknowledgement → acknowledged; completion authority restored without a relaunch.
- If the worker exits before acknowledging, the existing relaunch-with-ruling-in-initial-input path replays it (at-least-once, unchanged).
send_agent_message result text distinguishes "delivered to the live worker" from "queued for the hold loop".
Invariants preserved: steer still never releases; agent-host still never consumes ruling; validation/authority stays in hold-state.ts.
Acceptance
- Behavioural runner test: escalation → hold opened while the worker is still alive → ruling arrives → hold
released + text forwarded to stdin (mock host asserts the message) → worker acks via outbox → acknowledged with one spawn total.
- Existing tests for the exit-then-ruling path unchanged.
Report
penster batch
20260911T234647, field report on #627, item C. Under penster's hold-time convention the worker keeps committing ruling-independent work while held; a live worker therefore never sees aruling— by design the hold loop is the single consumer and only reads the inbox after the worker exits. The supervisor worked around it by sending asteercopy of the ruling text each time; the relaunch then re-read a ruling the worker had already applied — one wasted iteration per hold (×3).send_agent_messagealso reported "no worker process is involved" while one was running.Proposal (keeps the single-consumer invariant)
The runner stays the only component that validates and persists a ruling; agent-host only transports:
rulingmessages addressed to the unit. A valid one is applied exactly as in the hold loop (applyRuling+ strict persist →released,deliveryState: in-flight, ack the inbox file) and the ruling text plus the acknowledgement instruction (notify_supervisor(replyTo=<ruling id>)) is forwarded to the worker's stdin via agent-host as asteer-shaped message.reply(replyTo=<ruling id>)is already recognised by the drain as the delivery acknowledgement →acknowledged; completion authority restored without a relaunch.send_agent_messageresult text distinguishes "delivered to the live worker" from "queued for the hold loop".Invariants preserved:
steerstill never releases; agent-host still never consumesruling; validation/authority stays inhold-state.ts.Acceptance
released+ text forwarded to stdin (mock host asserts the message) → worker acks via outbox →acknowledgedwith one spawn total.