🤖 automated
Found while dogfooding the rotation end to end (#1204, evidence in #1640).
What happened. A triage Run now was fired, and a drain Run now clicked a minute later. The second click started nothing:
[framework] auto PM: standing down for .../tf-1334-dogfood — a run was started for this project a moment ago
That is DEFAULT_AUTO_PM_COOLDOWN_MS — 30 minutes (auto-pm.ts:29) — doing its job. The cooldown exists so the unattended sweep does not stack runs on one project every tick.
Why it is a problem for a click. The cooldown is a policy for work nobody asked for. A click is someone asking. Today the same gate applies to both, so for half an hour after any run, a routine's Run now is a button that cannot start anything.
The outcome line does say so, under Concurrent agents. But it is one line of small grey text below the fold of the card, it appears after the click rather than before, and the button itself gives no hint — it is not disabled and its tooltip still promises "Starts up to N agents". A user who clicks and looks away sees nothing happen and no reason why.
Restarting the daemon clears it, which is what unblocked the dogfood — a workaround nobody should need to know.
Worth deciding, not obviously one way:
- Option A — a click ignores the cooldown, the way
onDemand already outranks the master switch (auto-pm.ts:637 doc): "the click is the consent the preference exists to record". Consistent with how every other gate treats an explicit ask.
- Option B — keep the gate, but say so before the click: disable the button and let the tooltip read "on cooldown until HH:MM" instead of promising agents it cannot start.
A is the smaller change and matches the existing precedent. B is safer if the cooldown is also protecting quota rather than only pacing the sweep.
Related: the same "a click reaches less than the sweep does" shape as #1640 and the pinned-branch gap filed alongside this.
🤖 automated
Found while dogfooding the rotation end to end (#1204, evidence in #1640).
What happened. A triage
Run nowwas fired, and a drainRun nowclicked a minute later. The second click started nothing:That is
DEFAULT_AUTO_PM_COOLDOWN_MS— 30 minutes (auto-pm.ts:29) — doing its job. The cooldown exists so the unattended sweep does not stack runs on one project every tick.Why it is a problem for a click. The cooldown is a policy for work nobody asked for. A click is someone asking. Today the same gate applies to both, so for half an hour after any run, a routine's
Run nowis a button that cannot start anything.The outcome line does say so, under
Concurrent agents. But it is one line of small grey text below the fold of the card, it appears after the click rather than before, and the button itself gives no hint — it is not disabled and its tooltip still promises "Starts up to N agents". A user who clicks and looks away sees nothing happen and no reason why.Restarting the daemon clears it, which is what unblocked the dogfood — a workaround nobody should need to know.
Worth deciding, not obviously one way:
onDemandalready outranks the master switch (auto-pm.ts:637doc): "the click is the consent the preference exists to record". Consistent with how every other gate treats an explicit ask.A is the smaller change and matches the existing precedent. B is safer if the cooldown is also protecting quota rather than only pacing the sweep.
Related: the same "a click reaches less than the sweep does" shape as #1640 and the pinned-branch gap filed alongside this.