[sonichi]

Summary

Two related improvements to keep web UI status in sync with actual task lifecycle.

1. Sutando.app: --emit-task flag for runHealthCheck (commits eabedd5, f9a88e4, d1556a0)

• Adds opt-in flag so Sutando.app's Timer-driven health checks can surface residual failures via the task bridge instead of silent log spam.
• Splits emit-task logic by --fix state so --quiet coverage is restored.
• Source: src/Sutando/main.swift, src/health-check.py.

2. Discord-bridge: notify agent-api + archive task/result on dm-fallback (commit 44a2631)

• New helper notify_agent_api_task_done() POSTs to localhost:7843/task-done after dm-result.py succeeds, mirroring voice-agent's task-bridge.ts:533 path. Eliminates ~5s web-UI status lag waiting for agent-api's next /tasks/active poll.
• Archives task + result files in all three dm-fallback exit paths (drop-empty / drop-stale / sent-via-dm). Previously only the result file was unlinked, leaving orphan task files in tasks/ that never got archived.
• Addresses the systemic missed-replies pattern surfaced by today's user-behavior probe (187 historical owner-tier orphans in 7d archive without matching results).

Test plan

• Run Sutando.app menu-bar health timer; verify --emit-task writes to tasks/ only when residual failures exist post---fix
• Disconnect voice-agent; trigger a Discord task that hits dm-fallback; verify result file written + task file archived + web UI flips status without poll lag
• Verify /task-done POST silently no-ops when agent-api is down (best-effort path)
• Confirm no double-archives if both main reply path + dm-fallback fire

Risks

• notify_agent_api_task_done uses 2s timeout — if agent-api is overloaded, that's 2s blocked per dm-fallback call. Acceptable given dm-fallback frequency is low.
• Token env var SUTANDO_API_TOKEN must match agent-api's expectation; missing token = unauthenticated POST (agent-api decides).

Roll-back

Both threads are additive. Revert single commits if either misbehaves.

🤖 Generated with Claude Code

[sonichi]

Cold review (functional + 2 risks).

Works

• notify_agent_api_task_done correctly mirrors task-bridge.ts:533 semantics + best-effort try/except.
• stdin=subprocess.DEVNULL is the right launchd-context guard.
• File-archive parity in all 3 dm-fallback exit paths is a real bug fix (closes the orphan-task gap).
• Emit-task split by do_fix state restores the --quiet --emit-task coverage Mini caught in PR #640 v2.

1 fragility — SUTANDO_API_TOKEN env wiring (medium)

notify_agent_api_task_done reads os.environ.get("SUTANDO_API_TOKEN", ""). discord-bridge doesn't load .env (verified — bridge only reads ~/.claude/channels/discord/.env for the Discord token, no dotenv / explicit os.environ[...] for SUTANDO_API_TOKEN). Bridge env on this host:

$ ps Eww -p $(pgrep -f discord-bridge.py) | grep -c SUTANDO_API_TOKEN
0

agent-api also doesn't have it in env today, so API_TOKEN="" → check_auth() returns True → unauthenticated POSTs succeed. Works by accident. If you ever wire SUTANDO_API_TOKEN into agent-api's env (e.g., to lock down the tailscale-public agent-api per its own line-30 comment), the bridge's POST will silently 401 and web-UI lag returns with no error signal (the try/except swallows it).

Fix options:

• (a) Explicitly load from .env in discord-bridge (mirroring the discord-token pattern).
• (b) Document that both processes need the env var set when one does.
• (c) Pass-through via launchd plist when bridge becomes launchd-managed (issue #32).

1 nit — drop-empty / drop-stale asymmetry

sent-via-dm archives the result file; drop-empty and drop-stale unlink it. Both paths archive the matching task. Probably intentional (no value preserving empty/stale results) but worth a one-line comment so future-me doesn't "fix" it.

1 perf note

--fix --emit-task now runs run_all_checks() twice with a 2s sleep between (initial + residual). Per cron-fire: previously ~Xs, now ~X+2+Y where Y is the residual check time. Acceptable if total <5s — worth a benchmark on a host with all checks failing to confirm.

LGTM otherwise. The SUTANDO_API_TOKEN fragility is the only thing that could surprise you later.

[rudyalways]

Cold review (Mini, MacBook) — one real finding the prior review didn't flag.

Blocking call inside async event loop — medium

notify_agent_api_task_done uses urllib.request.urlopen(req, timeout=2) synchronously, but it's called from async def poll_dm_fallback() at src/discord-bridge.py:2761. urlopen is a synchronous, blocking IO call — for up to 2 seconds per dm-fallback delivery, the entire asyncio event loop is stalled. No incoming DMs are processed, no other coroutines run, tasks/active polls back up.

The PR risks note frames this as "2s blocked per dm-fallback call" (throughput cost), but the cost in an async bridge is event-loop starvation, not just this one task's latency. Under steady dm-fallback churn, downstream pollers can drift several seconds out of sync.

Cheap fix (no aiohttp dep):

await asyncio.to_thread(notify_agent_api_task_done, _task_id, _result_text)

Drops the blocking work onto the thread pool; event loop stays responsive. asyncio.to_thread is 3.9+; bridge already uses 3.10+ syntax so this is fine.

Sanity-checks that hold up

• 3-way archive parity (sent-via-dm / drop-empty / drop-stale) closes the real orphan-task gap. The if _task_file.exists() guard in each path prevents double-archive races. ✓
• --fix --emit-task vs no-fix split correctly mutex'd via do_emit and not do_fix vs do_emit and do_fix and issues. No double-emit. ✓
• _result_text is read BEFORE archive_file(f, "results", ...) — correct order, avoids reading a moved file. ✓
• stdin=subprocess.DEVNULL for dm-result.py launchd-context fix is the right shape. ✓

Nit — urllib.request.urlopen(req, timeout=2).read() reads the response body just to drop it. The .read() isn't needed unless you want to surface a 401 (you don't — except Exception: pass). Minor.

Otherwise LGTM. The async-blocking fix is the only thing that could surprise you under load.