schedules: a healthy scheduled task has no way to run now, so a new daily/weekly task cannot be checked until its first period passes #2507

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: 31c8ce45f8584df08e3993fa5ebeb798
Branch: dev/3-schedules-run-now
Base: 550fb3a
At: 2026-11-05T05:53:50Z

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.

Written-by: FlyBot Lead

What happens

On the Scheduled tasks panel, the only per-task control that can start a run is Retry, and it is drawn only when task.lastRun.result === 'failed' (core/src/client/schedules.js:180/:193). A healthy task — and a task that has never run — has no way to run now, so after creating a daily, weekly or cron task there is no way to check it works until a whole period has passed (up to a week), short of editing at to a minute from now and editing it back, which moves the DSH timeline.

The host already supports it: core/src/host/schedules.js:567-594 (retrySchedule) refuses only paused and unknown tasks, and for a healthy task it does the same agent.followup(retryText) + noteRun; retryText (:80-86) does not write to DSH's schedule at all, so the task's next run stays where it was. The client simply never offers the entry.

Expected behaviour

A scheduled task that is not paused and is not currently running draws Run now (title Run the task once now); pressing it once sends exactly one schedule-retry for that task and does not change DSH's next run. A failed task keeps Retry. Paused and running tasks draw neither. A read-only window draws no write control at all, Run now included.

Scope

• core/src/client/schedules.js: draw the control when !locked && actions.scheduleRetry && status !== 'paused' && task.lastRun?.result !== 'running'; label failed ? 'Retry' : 'Run now'; the call stays actions.scheduleRetry(sessionId, id) (two ids only).
• core/src/client/i18n.js: one zh entry for Run now.
• core/test/schedules-client.test.js: the red-first cases below.
• docs/subsystems/core-client.md: the schedules section, including the read-only sentence.
• A changelog.d/ fragment, and regenerate core/client.js + patches/ds-bot/** (client bundle lane).

Not in scope: core/src/host/**, any new endpoint, any change to DSH's schedule.

Acceptance

1. Healthy task (and a task with no lastRun) draws Run now; one press sends exactly one schedule-retry with that task's ids and the Next: line is byte-identical before and after.
2. Failed task still draws Retry; paused draws nothing; lastRun.result === 'running' draws nothing.
3. A read-only window draws no write control, and Run now is added to the existing read-only write-label assertion so a new write entry cannot escape it.
4. build + generate leave git status --porcelain clean; verify green.

Evidence for the red first

On a clean 550fb3ac, with only the test change placed: 64 tests, 61 pass, 3 fail — the healthy/never-run row offers no control (expected ['Run now','Run now','Retry'], actual ['Retry']), the read-only positive control sees [], and the existing #2232 read-only write-label assertion goes red as soon as Run now joins the label set. After the fix the same file is 64/64 and the eleven neighbouring suites are 137/137.

Dedupe

Live main (550fb3ac) and closed issues: "Run now" schedule matches only #794 (live-e2e), #1651, #473 (the scheduler feature that introduced Retry for failures), #1319, #106, #358; schedule-retry matches #473 and unrelated workflow/social issues; "retry now" matches #968/#1227/#473/#992. None asks for a run-now entry on a healthy scheduled task.