Skip to content

client: state the scheduled task count and open the list from the row after three - #2032

Merged
Birfy merged 1 commit into
ThinkFlowLab:mainfrom
HugoXK:dev/3-schedule-summary-more
Nov 1, 2026
Merged

Birfy merged 1 commit into
ThinkFlowLab:mainfrom
HugoXK:dev/3-schedule-summary-more

Conversation

@HugoXK

@HugoXK HugoXK commented Nov 1, 2026 •

Copy link
Copy Markdown
Contributor

Owner: Dev-3
Reviewer: Birfy

Fixes #2030

What changed

The details panel's Scheduled tasks line drew tasks.slice(0, 3) and said nothing about what it left out: a Bot with five scheduled tasks looked like a Bot with three, and the only way to learn the real number was to open Settings → Scheduled tasks by hand.

  • Above three tasks the section title carries the count — Scheduled tasks · 5, the same · separator the settings rows and the board already use. At three or fewer the title stays exactly Scheduled tasks, so the common case does not change.
  • One row after the three says how many are left (2 more not shown, the key the project board already uses) and opens the full list.
  • That row calls openSettings('schedules') with no bot id: schedules.js is useState(Boolean(start)) and the settings page is start: id ?? undefined, so an id opens the new-task form instead of the list. Only the empty state's button passes bot.id, which is what "Add one" means.
  • Zero tasks: the empty state is untouched — same label, same openSettings('schedules', bot.id).

Scope: ScheduleSummary only. SchedulesPage, TaskList, the settings section, the cap of three, the row order and nextText are untouched; no new i18n string beyond the count-bearing title (the N more row reuses an existing key); one changelog fragment and one sentence on the owned subsystem doc (core/src/client/ is an owned path).

Rebase

The branch was rebased onto f6fcb7ffabee43da79388313cbcdb7ada9111dcb (the merge of #2028, which had also touched core/client.js and both generated patches) and every generated artifact was rebuilt on that base, not text-merged:

  • core/scripts/build-client.mjs wrote core/client.js;
  • node scripts/ds-bot-patches.mjs generate ran twice — the second run left core/client.js, patches/ds-bot/0001-core-fixes.patch and patches/ds-bot/0008-client-bundle.patch byte-identical (md5 cc779a1bc78475c33e13028dc7294779, c3df40f0e46bee10deabc6c8ed4a7b3c, 45aa8be6c2125fadf1a2ad87173360b8);
  • check → ok 10 patches apply cleanly in order and ok core/ equals ds-bot/ + patches/ds-bot/; canonical → ok patches/ds-bot/ is what generate writes (generate is a no-op); build-client.mjs --check → no-op.

Red first

Two independent runs on the base f6fcb7ffabee43da79388313cbcdb7ada9111dcb, each in a fresh checkout of the base carrying only the new test file: 30 tests, 28 pass / 2 fail both times, and the two failures are the two new behaviours:

  1. #2030: five tasks draw three rows and the title says the real count — the rendered title is Scheduled tasks where Scheduled tasks · 5 is expected (the three .bt-task-line rows already pass today).
  2. #2030: the row after the three says how many are left and opens the list, not the new-task form — 0 buttons with class bt-more, expected 1.
  3. Control, green on the base and still green at the tip: three tasks keep the bare title and draw no more row; zero tasks keep the empty state, and its click still passes bot.id.

Each new test bites

Mutation checks, one at a time, on the fixed tree:

mutation result
title drops the count (t('Scheduled tasks')) case 1 red — 29 pass / 1 fail
the more row passes bot.id case 2 red on the call arguments — 29 pass / 1 fail
the more row drawn at three tasks too (hidden > -1) control red — 29 pass / 1 fail

Verified on the head

TZ=UTC ARCH_DOCS_BASE=f6fcb7ffabee43da79388313cbcdb7ada9111dcb npm run verify in a clean detached checkout of 5c34342690a3a9ad948f084c57515e204f138224, exit 0:

  • core 2454/2454, social 541/541, tree 127/127, timeline 135/135, workflow 336/336, .github/scripts 563/563, interop 37/37, live-e2e 24/24
  • arch-docs: OK (9 changed file(s)) against base f6fcb7ff; core lint 73 warnings and 0 errors — the base's own count, with no warning in a line this diff adds
  • ok 10 patches apply cleanly in order, ok core/ equals ds-bot/ + patches/ds-bot/, ok patches/ds-bot/ is what generate writes (generate is a no-op); build-client.mjs --check no-op

Not run: smoke/bench (no host or turn path), and the CI package job's pack, typecheck and actionlint.

The generated patch: 0008 moves text, it does not rewrite it

core/client.js changes by +16/−8 (one i18n key, one ScheduleSummary hunk), 0001-core-fixes.patch by +16/−6 (the schedules.js diff), yet patches/ds-bot/0008-client-bundle.patch shows +4,700/−2,925 and grows from 23,095 to 24,870 lines. What that is, measured rather than asserted:

  • generate on a pristine checkout of the base with no changes at all reproduces main's 0008 byte-for-byte, so this is not a git-version or tooling difference;
  • with only this change, 2,618 of the 4,700 added lines are byte-identical to a line the same diff removes, and 481 lines that are plain context in the base's 0008 are now emitted as removals: the bundle text is re-hunked (303 hunks become 266, one block merging into @@ -1624,969 +1624,2049 @@), because core/client.js and ds-bot's client.js differ almost everywhere and a small edit re-pairs the duplicated minified CSS/JS;
  • decisive check: applying the whole series with main's 0008 substituted reproduces main's core/client.js byte-for-byte, and substituting this PR's 0008 changes the result by exactly +16/−8 — the same delta as core/client.js. The patch is a different spelling of the same edit, not a different edit.

Nothing in the patch was hand-edited: canonical proves the committed series is exactly what generate writes, and check proves the ten patches still apply in order and reproduce core/ — the tree that ships.

Checkpoint

{
  "pr": 2032,
  "claim": "Dev-3",
  "issue": 2030,
  "summary": "The details panel's Scheduled tasks line drew only three rows and said nothing about the rest of a Bot's tasks. Above three it now puts the real count in the title (Scheduled tasks · 5) and draws one more row saying how many are left, which opens the settings list. That row passes no bot id, because an id opens the new-task form rather than the list. Three or fewer tasks, and a Bot with none, render exactly as before, and the empty state keeps its add-one button.",
  "files": [
    "core/src/client/schedules.js",
    "core/src/client/i18n.js",
    "core/test/schedules-client.test.js",
    "core/client.js",
    "patches/ds-bot/0001-core-fixes.patch",
    "patches/ds-bot/0008-client-bundle.patch",
    "patches/ds-bot/files/test/schedules-client.test.js",
    "docs/subsystems/core-client.md",
    "changelog.d/2030-schedules-summary-more.changed.md"
  ],
  "checks": {
    "ran": "TZ=UTC ARCH_DOCS_BASE=f6fcb7ffabee43da79388313cbcdb7ada9111dcb npm run verify",
    "result": "green",
    "at": "5c34342690a3a9ad948f084c57515e204f138224"
  },
  "next": "none — ready for review"
}

… after three

The details panel's Scheduled tasks line drew tasks.slice(0, 3) and said
nothing about the rest, so five tasks looked like three and the only way
to learn the real number was to open Settings by hand.

Above three the title now carries the count (Scheduled tasks · 5) and one
row after the three says how many are left and opens the settings list.
That row calls openSettings('schedules') with no bot id: with an id the
settings page opens the new-task form, which is what only the empty
state's button means. Three or fewer tasks and no tasks render as before
(ThinkFlowLab#2030).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bot details: the Scheduled tasks list draws three rows and never says how many it left out

2 participants