Watchers: see what scheduled agents found, and act on it in one place

[shubhdeep128]

The problem

Scheduled tasks are good at starting an agent on a timer. Running several every day (a performance auditor, a log checker, a QA sweeper) shows what's missing after the prompt is sent:

• A task reports "succeeded" as soon as the prompt is delivered, not when the agent finishes. There's no history of past firings. A task whose agent never finishes keeps firing on top of itself.
• Agents have nowhere to record what they found. Each one writes its own files or Slack posts, and two agents often report the same problem.
• The work they start (worker threads and their PRs) is scattered across the sidebar, with no link back to the problem that caused it.
• Keeping workers moving takes a second "watchdog" agent that guesses when threads stall.

I've been running this with JSON files, SSH between two Macs and a hand-written WebSocket client. It works, but T3 already has most of the pieces.

The proposal

1. Firing history. Each scheduled task firing is recorded at dispatch, and its status is read from the orchestration run it started. A task doesn't fire again while its own previous run is still going. That covers [Feature]: Skip scheduled task occurrences when the bound thread is already running #18038 for a task's own runs, and the skipped firing shows in the history instead of piling up queued prompts.
2. Findings. A small per-environment list that agents write through MCP tools (report_finding, list_findings, update_finding). Reporting the same fingerprint twice returns the existing finding. A problem that comes back after its fix merged opens a new one. Findings can be backlogged, dismissed and restored.
3. A Watchers view, next to Pull requests and Usage.
   • A Today list grouped by what needs you: questions, PRs ready to merge, new findings and work in progress. Merging uses the existing pull request actions.
   • A Watchers tab with one card per scheduled task, showing its last firing and next run.
4. Fix on any machine. One action claims a finding and launches a normal worker thread in its own worktree, on whichever connected environment you pick. Progress (working, needs you, in review, ready to merge, merged) is derived from the thread and its PR, not stored twice.

It builds on scheduled tasks, thread launch, PR snapshots and pullRequests.runAction. Nothing is synced between machines. Each environment owns its data, and the client shows every connected environment in one list.

Questions for maintainers

• Is "Watchers" a good name next to the existing "automation" wording in the thread panel?
• Should the Scheduled tasks settings page move into this view?
• Is the findings list in scope for T3, or better left to a fork?
• If yes, should the two new tables land as numbered migrations? My fork creates them at startup, so it doesn't collide with your migration numbers.

I'm running this in my fork (shubhdeep128/t3code). If the direction is approved, I'd open one PR.

Demo

A one minute walkthrough of the fork, recorded on a demo project with made-up data. The voiceover is text to speech, and the captions carry the same points.

watchers-launch.mp4