# Conversation 2026-07-27T17-29-11-843Z

## 2026-07-27T17:29:12.397Z · user · cli

Open TODO_AGENTS.md and work on this one open entry only, then check it off:

- [Verify the concurrent-agents setting actually works](tickets/2026-07-25_concurrent-agents-setting.md) — the implementation landed on `main` via #1252 but is unverified ("Done, but not sure it works"); verification is the named remaining step. Exercise the setting end-to-end (a routine spins up the configured number of concurrent agents), fix what's broken if the fix is small, otherwise report the diagnosis. The thread's open question (driving "Run now" concurrency from routine tasks) stays out of scope.

Do not start any other entry. If that entry is already checked off or no longer there, stop and do nothing.

## 2026-07-27T17:39:10.830Z · agent · cli

The entry is done. **Verdict: the concurrent-agents setting works.**

\## What I verified

I traced the whole chain and found every link held except one, which had no coverage at all — the daemon-side wiring between the registry file and the sweep. I added two tests for it in `packages/the-framework/src/daemon-services.test.ts`, driving the real `startBackgroundServices` against a real registry file and a real `TODO_AGENTS.md`, stubbing only the daemon's spawn:

- `autoPmConcurrency: 4` with six open entries → the start-up sweep asks for **exactly four** runs, pinned to the first four entries in order, each `unattended` with its own `queueEntry` and `ticket`.
- Auto-run **off**, `autoPmConcurrency: 3` → the schedule starts nothing by itself; the drain row's `Run now` (`wakeAutoPm({ onDemand: true, drainOnly: true })`) fans out to three.

To make sure these aren't passing incidentally, I severed the read (`concurrency: async () => undefined`) and confirmed both fail on the batch size, then restored it.

The rest of the chain was already covered and passes: `RoutineWork.test.tsx` (24), `registry.test.ts` clamping, `auto-pm.test.ts` (8+ tests naming #1204), and — the real-process link — `daemon.test.ts` *"a git project starts concurrent runs, each in its own worktree (#736)"*, which spawns actual children.

No fix was needed, so none was made.

\## Two things worth knowing

**The 10 `daemon.test.ts` failures are environmental, not a regression.** They pre-date my change (confirmed by stashing). The daemon answers `the dashboard bundle is not installed` and the tests JSON-parse that. `npm run build` in `framework-dashboard` + `npm run bundle:dashboard` makes all 29 pass. Full suite is otherwise 1493/1503.

**Caveats for the demo,** recorded on the ticket rather than acted on:
- Only the *draining* routine fans out (by design — rotation jobs each rewrite the queue file). So the 10-parallel-agents shot needs the queue to already hold ≥10 open entries; triage will not spin up 10 agents to fill it. This is the same ground as the thread's open question, which I left out of scope.
- A batch smaller than the cap isn't topped up for 30 minutes (the per-project cooldown is stamped once per batch).
- Hands-off web runs end their local process at hand-off, so `activeRunCount` stops counting them and a later batch can exceed the cap. #1253's durable claims still stop the same entry going out twice, so it over-fans rather than duplicating work.

The ticket stays **open** — its remaining half is the unanswered question about routine-triggered concurrency, which the entry explicitly kept out of scope.

```ready-for-merge
```
