[factory] Canary — end-to-end verification post fallback+watchdog 2026-08-31T17:55:37Z

[kjgbot]

Canary probe

Filed by factory-lead-r5 to verify the deployed factory container dispatches issues end-to-end after today's fixes:

• PR [factory] error {} — raw Errors serialize to {} (message/stack are non-enumerable); describeError() already exists one line away #83 (dispatch-reset admin route)
• PR relay backend: dispatch exits after placement, so nothing publishes the PR or parks the issue — remote work never reaches human-review #85 (wedge watchdog for factory#372)
• PR feat: add exhaustive Factory feature verification #86 (forceProvision fallback for ensure 500s)
• cloud PR #3222 (Daytona opencode fix)
• cloud PR #3227 (ensure error surfacing)

Expected pipeline:

1. Sweep ingests within ~5 min
2. JIT: fresh provision attempted, falls back to reused sandbox if hung
3. Implementer agent (ar-<n>-impl-factory) makes a trivial commit
4. factory/<n>-* branch appears on GitHub
5. PR opens by app/agent-relay-code

Implementer trivial task: add a single line comment to README.md at end of file: <!-- canary probe by factory-lead-r5 2026-08-31T17:55:37Z -->

[khaliqgant]

Software Garden human input request

Agent: ar-421-impl-factory
Issue: 421
Question: Can you repair or expose Relay's invoke_action tool and re-dispatch issue 421 so the required factory.lifecycle completed signal can be accepted?

[khaliqgant]

Software Garden human input request

Agent: ar-421-impl-factory
Issue: 421
Question: Can you restore the factory.lifecycle Relay action and rerun issue 421? The required single completion invocation returned action_not_found after branch factory/421-agentworkforce-factory-ef248fb3 was published at 08500c42604e1515fe57e2670033d79db0222133.

[khaliqgant]

Software Garden human input request

Agent: ar-421-impl-factory
Issue: 421
Question: Can you restore the factory.lifecycle Agent Relay action for this workspace so the completed implementer signal can be accepted?

[kjgbot]

Removed from the Software Garden dispatch pool (gate label dropped) — 2026-09-06.

This canary was being re-dispatched in a loop. Each run provisioned a JIT sandbox, the agent reached a point where it needed human input, posted a question here, waited, and was reaped by the orphan reaper at the 300s placement timeout — then re-dispatched and asked again.

Across the canary set that produced 34 unanswered human input requests in three days (this issue is one of seven), and 13 sandboxes provisioned in a single recent window. The questions had no reply path and no notification to a human, so none was ever answered.

Nothing here says the work is wrong — the loop is a dispatch-lifecycle defect, not a defect in this issue. Re-add the gate label once agents park correctly on a question instead of spinning.

The fix is in progress: on a human input request the agent should be released immediately, the issue parked in awaiting-clarification, the thread subscribed, and the work re-dispatched with the answer in context when a human replies.