status-ack

status-ack

The core cannot say "received" while it is deep in a long turn or while its session watcher is gone. This runner works outside the core's turn. On each pass it decides, per queued task, whether the requester is owed one status line. The decision comes from src/status_ack_policy.py and is made from observed facts only.

Scope

It speaks only for a task no session has picked up (no RUNNING phase, no worker holding it) that shows no activity card (no row projected or owed in state/activity/<task>.json) and no sent progress notice (task-progress records progress:<task>:sent after a send; its first-notify marker is bookkeeping only). The predicate is src/ack_overlap.py. The gateway asks it again just before it sends the ack, for that ack's own outbox item only, so a pickup after publication withdraws the line and nothing else. Anything else is the card's and the progress notifier's to report, so this runner stays silent. A task a session claimed and then went quiet on is out of scope here. The second thing it does is the owner DM when the watcher is down.

What it says, and where

• One initial line per task, at most. It is sent only after the task's first-ack deadline, which is measured from intake and set per priority. The text is one of the policy's fixed templates. There is no estimate and no invented progress.
• Only in the task's own conversation. The room and thread come from the bridge-attested task envelope (envelope_hmac must verify). If the envelope does not verify, the source is not Matrix, or the room or thread cannot be verified, nothing is sent. There is no fallback room and no DM. The line goes out as results/proactive-about-<task>--<ts>.to-ag2space.txt. The gateway's proactive outbox lane threads it on the task's message and checks the task again just before the send. This skill does not post, retry or claim delivery itself.
• The core's own "on it" and this line never both go out. Both take ack:<task>:initial in src/ack_claim.py, and whichever claims it first is the only one that speaks. The core's first notify.py --task-file call for a task is its initial ack. Its later calls are progress and are never suppressed, and neither is the task's real answer.
• Checked again before publish. Between deciding and publishing, the runner re-reads the result, the activity phase and any pending cancel. If any of them has changed, it releases its claim and publishes nothing.
• Counted as sent only with a receipt. An ack is confirmed only once the outbox item is DELIVERED with an event id. A send withdrawn at dispatch releases the claim. Any other park leaves the claim unknown, and that ack is never retried.
• Watcher down. When only a standby watcher has held the inbox for STATUS_ACK_WATCHER_DOWN_AFTER_S seconds, the owner gets one DM through the proactive path saying so and naming the remedy (restart the core). This happens once per outage. The outage ends when a session watcher holds the inbox again. Room lines say "the owner has been told" only after that DM has a delivery receipt.