fix(reporters): stop prescribing a workflow change on a first run

[veksen]

Goal

The no-baseline message told a user to add a push trigger their workflow already had, and named an empty branch when none was set. Both land on a project's first run. Closes Query-Doctor/Site#3841.

Found by putting four open-source repositories through the agent onboarding flow. Two of them hit this, on different repositories.

What

A correctly configured first run was told to fix its workflow. On Mastodon the workflow contained push: branches: [main], the comparison branch was set, and the run producing the message was that push. There was no baseline because it was the first run.

Before: "To establish a baseline, add a push trigger for your comparison branch so the analyzer runs on merges to main."

After: "The analyzer records a baseline when it runs on a push to main, and compares later runs against it. If this run is the first, the next one has something to compare against. If the workflow has no push trigger for main, add one."

The report cannot see the workflow, so the guidance is now a condition rather than a claim about what is in it.

An unset comparison branch rendered as nothing. On listmonk the branch resolved to empty and the console read:

No baseline found on branch "". Comparison will be skipped. To establish a baseline, run the analyzer on pushes to "" (add "push: branches: []" to your workflow trigger).

branches: [] matches no branch. That case now says no comparison branch is set, and says to set one.

How

Read success.md.j2 first, then baseline-notice.ts.

The template had one branch serving both situations. It now splits on whether comparisonBranch is present.

The console message moved out of main.ts into baselineNotFoundMessage, which made the empty case reachable from a test. It was inline in a long function, which is part of why it went unnoticed.

The branch resolves from the project's configured comparison branch, then the pull request base, then the current branch. On a push run for a project with none set, all three can be absent.

Tests

Both suites assert the property rather than the sentence. The template test checks that no empty inline code span survives rendering, which is the shape of the bug, and covers a comparison branch that is absent and one that is the empty string. The empty string is what production actually produced, and the first version of these tests did not cover it.

baselineNotFoundMessage is covered for empty, undefined and null.

Both were mutation-checked. Forcing the template back to the single branch turns two cases red; removing the guard in baselineNotFoundMessage turns three red.

Two existing cases from Site#3287 asserted the old sentence verbatim. Their purpose is to keep "no baseline" distinct from "temporarily unavailable", which still holds, so they now assert the phrase that survived rather than the one that changed.

npm run typecheck clean. src/reporters and src/sync: 185 passed across 12 files.

What changed since the first push

The first version of these tests was weak in three ways, and I rewrote them rather than leave them. Two assertions could never fail: the template never contained branches: [], which is a string from main.ts, and merges to no longer exists in either template branch. A third matched /If the workflow/, pinning my own wording, so it would have caught a rewrite and not a defect.

[github-actions]

Query Doctor — 6 successful checks

 Cost regression — No query went up more than 5%
 Untested data access — No changed data-access file without a test
 New query — No new queries
 New query with index recommendation — No new query ships an index recommendation
 Schema drift — No schema changes
 High-value nudge — No index or rewrite past the threshold

---

_{More details via MCP → get_ci_run({ runId: "019fceec-8ea9-74dc-b93d-5e317d5761d2" }) · view run · docs
3 queries read against main on assumed statistics of 10,000,000 rows per table. Sync production stats for costs measured against your real data.}