[marklysze]

Stacked on #5913 (which is stacked on #5885 and #5883). Merge order: #5883 → #5885 → #5913 → this. This PR's own change is 04f524a8a plus its changelog line ef73d3413. After #5913 lands, I'll merge main into this PR and rerun its full checks.

Through its parents it carries #5885's wake-turn-only Stop-hook handling and #5913's SUTANDO_STOP_INTERRUPT switch (off by default). This PR's own answer path is behind REMOTE_TASK_TURN_CONTEXT=1, and today's broker sends no room_question.

Why

AgentActivity ruling O8 lets agents answer room questions. The broker now adds task["room_question"], and a [AG2 Space room question; …] block inside the body, when an agent is asked. Before this PR:

• the structured field was dropped by _write_task, because it is not in _TASK_FIELDS;
• nothing told the agent how to answer, or which question_id to answer;
• the turn gate read applied_execution_phase and active_blocker_count from the latest outcome whatever task it described. An answer outcome that ever named the asker's task (for example input_ready) would have parked the answering agent's own reply as waiting_input + no_send. Backend ruling R2 says an answer outcome describes only the caller's own task; this guard is defensive.

What

• Bridge. room_question joins _TASK_FIELDS and is written as one line of quoted room data, carrying only the pinned keys: question_id, expected_revision, prompt, options, allow_free_text, response_mode, target_members, expires_at. It uses JSON with escapes and stays one line. A missing or unsafe question_id writes nothing.
• Answer rule. This applies under REMOTE_TASK_TURN_CONTEXT and only when can_answer is not false. It is a writer-owned line beside the ask-in-room rule. It tells the agent to:
  • take expected_revision and can_answer from room.question.inspect;
  • call room.action.execute_safe with action room.question.answer, top-level task_id, and arguments question_id, expected_revision and response ({"kind":"choice","option_id":…} or {"kind":"text","text":…}), once;
  • then write a [no-send] one-line result, so the answer is not also posted as a chat reply.
• Gate. classify_turn and result_file_decision take the task id. An outcome or reconciled record naming another task_id neither suspends nor settles this task. An outcome without a task_id still counts as the turn's own.
• Wake. A resolved blocker that carries an answers list renders each answer instead of answered "". The single answer (B13) is unchanged.

Evidence

python3 tests/… at the parent a20f02d93 (#5885) and at HEAD:

# before
$ python3 tests/sparrow-task-attempts.test.py
ERROR: test_a_room_question_renders_as_one_line_of_quoted_room_data
ERROR: test_the_answer_rule_needs_a_question_this_agent_may_answer
FAIL: test_render_wake_renders_an_answers_list_answer_by_answer
Ran 32 tests in 0.049s
FAILED (failures=1, errors=2)
$ python3 tests/agent-turn.test.py
ERROR: test_another_tasks_input_ready_does_not_suspend_this_one
ERROR: test_another_tasks_terminal_or_reconciled_outcome_does_not_settle_this_one
ERROR: test_its_own_input_ready_still_suspends_it
Ran 33 tests in 0.068s
FAILED (errors=3)
$ python3 tests/gateway-agent-activity-hooks.test.py
FAIL: test_a_room_question_reaches_the_task_file_with_its_answer_rule
Ran 45 tests in 0.731s
FAILED (failures=1)

# after
$ python3 tests/sparrow-task-attempts.test.py
Ran 32 tests in 0.051s
OK
$ python3 tests/agent-turn.test.py
Ran 33 tests in 0.085s
OK
$ python3 tests/gateway-agent-activity-hooks.test.py
Ran 45 tests in 0.722s
OK

The new cases:

• another task's input_ready does not suspend this one, and the reply posts as completed;
• this task's own input_ready, tagged or untagged, still suspends;
• another task's terminal or reconciled outcome does not settle this one;
• the room question renders as one line with only the pinned keys, escapes newlines and quotes, and an unsafe id renders nothing;
• the answer rule names execute_safe, room.question.answer, the task id and the question id; it is absent when can_answer is false;
• an answers list renders answer by answer;
• _write_task writes the data line and the rule, only the data when can_answer is false, and neither for an ordinary task.

The bridge suites pass, with the same two local-only Discord failures as main. ruff, scripts/review-checks.sh and the vendor sync check are clean. All new bridge lines are covered.

Live: the agent-answers path is not yet exercised on the rig; covered by unit tests and the MCP replay of captured question tasks.

[sonichi]

Re-reviewed 5c90bb0 (agent-assisted, Blue for Chi's seat).

• (a) Fixed: the answer-outcome filter falls back to the intent's action, so an action-less answer outcome no longer suspends the answering turn, while your own ask still does.
• (c) Fixed: the census anchor re-points to remote_gateway_bridge.py. census-d1-anchors and --verify both pass.

Still open:

1. Inherits #5885's gap: a reconciled-failed ask posts the "I asked X" note as completed.
2. "Answered once" is still partial. answered_in_journal is keyed by task_id, so a different task carrying the same question still gets the full answer rule after a crash. A single task offered a second question would wrongly get the already-answered note. Key it on question_id (or both). Nothing in the engine refuses a second room.question.answer; if the server's expected_revision is the real guarantee, say so in the rule's docstring.

agent-turn (47) and gateway-agent-activity-hooks (67) pass locally.

[marklysze]

Fixed in e3552db (head e3552db, which merges #5885's failed-ask fix up through #5913).

• (1) Inherited from feat(gateway): resume a woken task as a new turn and ask in the room [AgentActivity] #5885 via the merge.
• (2) answered_in_journal is now keyed on both: before any settle, a question counts as answered only when this task was offered that question (answer_offered == question_id) and the task's journal holds a succeeded room.question.answer. After a settle, the record is by question_id. A different question on the same task still gets the rule (test).
• The answer_rule docstring says that expected_revision guards only a concurrent answer: the rule re-reads it from room.question.inspect before answering, so it does not stop a second answer; the local record is the guard.

[sonichi]

Approving at e3552db (agent-assisted, Blue for Chi's seat). The journal check now also requires answer_offered == qid, so a second question on the same task gets the full rule (the test covers it), and the docstring now says plainly that this record, not expected_revision, is what stops a second answer. It inherits #5885's failed-ask fix.

One known limit, not blocking: before the first settle, a different task carrying the same question still relies on the per-task journal, so a crash in that window can repeat an answer. agent-turn and sparrow-task-attempts pass locally.

[keweichen]

Changes requested at current exact head e3552dbf4073cec13bf6acb57381e86d13370006 — not ready to merge. The requested 5c90bb09… snapshot moved during review; this verdict covers the current head.

The action fallback, failed-ask inheritance, and same-task/different-question correction are verified. Focused suites pass: agent-turn 47, task-attempts 41, gateway hooks 67.

Blocker 1 — “answered once” still has a cross-task crash window. Before the first settle writes the answered-ID record, the journal check requires the current task’s answer_offered == question_id. After task A successfully answers q1 in the journal, a different task B carrying q1 still receives the full answer rule; meanwhile A carrying q2 is now correctly allowed. No documented backend contract forbids rematerializing q1 under B, and the engine itself does not refuse the second call. Either make the pre-settle lookup follow q1 to the task that offered it (or record qid in the durable journal), or document and pin the backend invariant. Worst case is a duplicate room answer after a crash.

Blocker 2 — the real restarted gateway/MCP witness is still absent. Please show current HEAD receiving the one-line room data, inspecting and executing one answer at the expected revision, writing local [no-send], emitting no echo, and replay/redelivery adding no second answer.

This head also inherits #5913’s canonical-socket defect and #5885’s wake-mapping recovery defect. CI was still running with no completed failures at review time; CLA passes.

[sonichi]

Re-approving at 6b4182b (agent-assisted, Blue for Chi's seat). Each question now records which tasks were offered it (under _MUTEX, capped at 8 per question), and a succeeded answer in any of those tasks' journals counts as answered. That closes the cross-task crash window I noted. A question no answering task was offered still gets the rule. One nit: answered_in_journal is keyed by task, so if an offered task also answered a different question, that would count too. That's fine while a task carries one question. sparrow-task-attempts passes locally.

[marklysze]

Cross-task answered-once: fixed in 6b4182b (head 6b4182b).

• The proxy's journal names tasks, not questions, and records written by desktop can't carry question_id from this repo. So answer_rule keeps which tasks were offered each question (relay-answer-offers, bounded).
• Task B carrying q1 gets the already-answered note as soon as any task offered q1 (say A) has a succeeded room.question.answer in its journal, before any settle. After a settle, the record by question id still rules.
• Test (test_a_redelivery_after_a_crash_sees_the_answer_in_the_journal): A offered q1 and answered, with no settle. A redelivered → note; B with q1 → note; B with a question no answering task was offered → the rule.
• Recording question_id in the journal itself would be a desktop-proxy change.

[bassilkhilo-ag2]

Re-review at 6b4182b (delta from e3552db: 6b4182b plus the merge of #5913, reviewed there). The cross-task claim holds. One non-blocking regression note below. Verdict: not approving yet, because the REVIEW.md lesson 15 live witness is still missing.

Verified:

• task_attempts.py:190-210 answer_rule keeps relay-answer-offers (qid -> up to 8 offered tasks, under _MUTEX). Task B carrying q1 gets ANSWERED_HERE_NOTE once any task offered q1 has a succeeded room.question.answer in its journal, before any settle.
• test_a_redelivery_after_a_crash_sees_the_answer_in_the_journal fails on e3552db's task_attempts.py (rule returned instead of the note) and passes at head. sparrow-task-attempts 41, agent-turn, gateway-agent-activity-hooks and stop-interrupt all pass.
• CI: 39 pass, 3 skipped. Mergeable.

Non-blocking (a regression from e3552db, reachable only if one task is ever offered two questions):

• answered_in_journal (agent_turn.py:346) is per task, not per question. Once task R has answered q1 and is then offered q9, R joins offers[q9], and every later task carrying q9 gets the already-answered note even though q9 was never answered. Probe: R answers q1, then R offered q9 -> rule, then B offered q9 -> NOTE (at e3552db it was RULE). The assertion that covered "a different question on the same task" was dropped from the test (tests/sparrow-task-attempts.test.py:438-443), so nothing pins it now. If a task is guaranteed to carry one question for its whole life, say so in the answer_rule docstring. Otherwise, add R to offers[qid] only when R's journal holds no answer yet, and restore the dropped assertion. Worst case: a room question goes unanswered with a [no-send] result.

To approve: the restarted gateway/MCP witness keweichen asked for (one-line room data, one answer at the expected revision, local [no-send], no echo, replay adds no second answer).

(agent-assisted, Sutando for bassilkhilo-ag2)

[keweichen]

Changes requested at current exact head 6b4182b608da691ec38f9407d7dfb9d49b7a7632 — not ready to merge.

The narrow requested fix works: after task A is durably recorded as offered q1 and its answer succeeds in the journal, task B/q1 gets ANSWERED_HERE_NOTE; the same control returns the full rule at e3552dbf. The focused cumulative suites pass (task-attempts 41, agent-turn 47, gateway hooks 67, Stop 38).

Blocking — failure to persist an offer still publishes the irreversible answer instruction. In packages/ag2-sparrow/ag2_sparrow/task_attempts.py:203-210, _save_json() can return False, but answer_rule() ignores it, persists answer_offered, and returns the full rule. With only relay-answer-offers.json writes failed, A successfully answered q1 in the journal; after restart B/q1 still received the full answer rule because no durable association led the reader to A. This path must fail closed before publishing the rule, and needs a production-writer failure regression.

Blocking — the cap contradicts “any offered task.” ANSWER_OFFERS_PER_Q = 8 evicts a still-actionable association. After offering q1 to T0...T8, the file retained T1...T8. A succeeded answer by T0 was present in the journal, but T9/q1 still received the full rule. Preserve every association that can still answer, or pin and enforce a smaller upstream cardinality before relying on this bound; add the ninth-offer control.

Inherited blocker. The #5885 finish() transition in this head ignores its three durable-write results. Fault injection reproduces delivered-wake repost, episode rerun, and live-result quarantine states; see my current-head review on #5885.

Blocking live gate. The PR body still says this gateway/MCP answer path was not exercised on the rig, and no exact-head post-restart witness has since been posted. It needs one-line ingress, exactly one answer, local [no-send], no room echo, and replay/cross-task suppression, plus the inherited current-head witnesses required by the stack.

All current GitHub checks are green, including CLA. These are reproducible durability/cardinality gaps and missing live evidence, not CI failures.

[github-actions]

@cla-assistant check

[marklysze]

Fixed in 7a8e5e6 (head 7a8e5e6). answer_rule now checks both writes: the question's offer record and the attempt's answer_offered. If either fails, it returns a note instead of the rule: the agent is told not to answer and to end with [no-send], because an answer cannot be undone and an unrecorded offer could not be guarded. Test: test_an_offer_that_cannot_be_recorded_never_carries_the_answer_instruction covers each failing write, then the rule once both are recorded.

[sonichi]

Re-approving at 7a8e5e6 (agent-assisted, Blue for Chi's seat). If the offer record (or answer_offered) can't be saved, the task gets ANSWER_UNRECORDED_NOTE (write [no-send], don't answer) instead of the answer rule. Since an answer can't be undone, that's the right side to fail on. sparrow-task-attempts passes locally.

[marklysze]

Superseded by #6092.