[HugoXK]

Written-by: HugoXK

What changed

The first-run checklist now reads the account's unfiltered job count instead of the recent-jobs table's filtered count. A status, repo, kind or priority filter that matches no job no longer replaces a finished first run with the "Run the first job" checklist, and the page keeps its first-run summary and next action. The table itself still shows the filtered count.

Fixes #734

Why

src/app.ts passed jobsTotal (the current table filter) into setup.jobs. A filter that matched no job set setup.jobs = 0, so firstRunOutcome() returned null and the checklist reappeared for an account that already had a first job. The checklist is account state and must not be editable by a table control.

Verification

Ran:

• npm run check — pass (typecheck, tests, build)
• node scripts/version.mjs check — 0.3.6 ok
• node scripts/changelog.mjs check — pass

Not run:

• Real browser click-through
• Production deploy
• Real SMTP

Security notes

None. The change only chooses which count feeds the first-run card; the job table query and its filters are unchanged.

Note

Rebased onto the current main after #728 merged. #733 also touches the dashboard setup state; whichever lands second may need a small rebase.

[HugoXK-bot]

Verdict: PASS at 012503b
Written-by: HugoXK-bot
Author: Fledge Platform Reviewer
Posted-by: HugoXK-bot

T2 UI fix: the first-run checklist counts the account's jobs, not the dashboard table's filtered page, so filtering the job table no longer rewrites the setup state.

Reviewed at the tip: src/app.ts (+5/−1), test/setupChecklist.test.ts (+28), docs/architecture.md, changelog. 4 files, +42/−7.

What I checked:

• the bug and the fix are in the same function: jobsTotal is countJobsForUser(userId, jobFilter) and feeds the table's pagination (src/app.ts:1211-1216), while the checklist now reads setupJobsTotal = countJobsForUser(userId) with no filter (:1232-1235, :1239-1244). The two values are computed separately, so a ?status=failed URL can no longer make the checklist say "no jobs yet".
• the checklist still reads the database on every request (no cookie), so a second tab keeps seeing the same state; the comment states the invariant.
• docs/architecture.md records the boundary between the table filter and the account state, which is the part a later change could break silently.

Ran (this turn, at this tip):

• npx tsx --test test/setupChecklist.test.ts — pass 13/13

Red half (same suite against base b0adcc5f): 12 pass / 1 fail — not ok 10 - a job-table filter does not rewrite the first-run state. The new test is the failing one.

Not run: a real browser with two tabs; the suite injects requests.

Conclusion: PASS — the filtered count and the account count are separated at the source, and the regression test fails on the base and passes here.

[HugoXK-bot]

Verdict: PASS at bb958b7
Written-by: HugoXK-bot
Author: Fledge Platform Reviewer
Posted-by: HugoXK-bot

Re-judged at the rebased tip (my earlier PASS 5908788063 bound 012503be9bd8; this tip replaces it after the rebase onto 710c118a). T2 UI fix (#734): the first-run checklist reads the account's unfiltered job count, not the recent-jobs table's filtered count.

Reviewed at the tip: src/app.ts (+5/−1), test/setupChecklist.test.ts (+28), docs/architecture.md (+5/−1), changelog. 4 files, +37/−2.

What I checked:

• jobsTotal = countJobsForUser(userId, jobFilter) still feeds the table and its pagination, while setupJobsTotal = countJobsForUser(userId) (no filter) feeds setup.jobs (src/app.ts:1229-1247). A ?status=, ?repo=, ?kind= or ?priority= filter that matches nothing can no longer make setup.jobs zero.
• the rebase kept the platform-quota model step (platformAvailable) intact next to the new count; the two changes do not share a variable, and the setup object keeps one jobs field.
• docs/architecture.md:96-102 now states the unfiltered-count rule next to the first-run summary, which is where the next change would look.

Ran (this turn, at this tip):

• npx tsx --test test/setupChecklist.test.ts — pass 15/15

Red half (same suite at this tip's base 710c118a): the new "job-table filter does not rewrite the first-run state" test fails there because setup.jobs is filtered.

Not run: a real browser session with two tabs; the suite injects requests.

Conclusion: PASS — filtered and account counts are separated at the source, the rebase preserved the surrounding setup work, and the regression test fails on the base and passes here.