Add code scanning under the check name Analyze (go)

[iderex]

The generator reads a data file and writes markup. That is a parser and a
renderer, which is exactly the shape where an injection or an escaping mistake
lives, so the source gets scanned like any other code.

CodeQL, on pull requests to any branch and on pushes to the default branch, with
the results in the code scanning tab. One language, so one analysis job.

The check name has to be stable, because a ruleset matches it literally. With a
single-language matrix the run reports as Analyze (go). The gate this
repository is held to requires two names for this, one per matrix leg plus the
workflow. There is one leg here, so one name; that difference is a deviation and
belongs in the parity ledger with its reason rather than being papered over with
a second empty job.

Confirm the scan actually names this repository rather than the template it was
copied from, which is a mistake that has already happened elsewhere and produces
a green check that scanned nothing here.

Done when

A pull request shows a check named exactly Analyze (go), the code scanning tab
lists an analysis whose repository is this one, and a deliberately introduced
finding appears in that tab and reds the check.

[iderex]

The workflow is landed on 8cc17d9. Two of the three things the done-when asks
for are met and the third cannot be met by this workflow, which is measured
rather than argued.

A check named exactly Analyze (go) reports, and the analysis in the tab is of
this repository:

gh api 'repos/Flowfin/site/code-scanning/analyses?tool_name=CodeQL&ref=refs/heads/main&per_page=1' \
  --jq '.[] | {url, ref, category, results_count, commit_sha}'
{"category":"/language:go","commit_sha":"8cc17d96d5580bfadba4bbaf7629afdbf7c2f4d2","ref":"refs/heads/main","results_count":0,"url":"https://api.github.com/repos/Flowfin/site/code-scanning/analyses/1591946047"}

A deliberate finding was put in the tree for one run on #115, a shell command
built from a query parameter in a package nothing calls. It appeared in the tab
as a critical alert, and Analyze (go) passed anyway:

gh api repos/Flowfin/site/commits/9f88de84603f5d2b651687b30b7f213330c1221a/check-runs \
  --jq '.check_runs[] | select(.name=="CodeQL" or .name=="Analyze (go)") | {name, conclusion, title:.output.title}'
{"conclusion":"failure","name":"CodeQL","title":"1 new alert including 1 critical severity security vulnerability"}
{"conclusion":"success","name":"Analyze (go)","title":null}

Both runs 2026-08-09. The two names answer different questions. Analyze (go)
says whether the analysis ran; CodeQL says whether the change introduced
alerts, and it is the only one of the pair that refuses anything. No setting of
this workflow makes the first one red on a finding, so the last clause of the
done-when asks for something the mechanism does not do.

Two things follow, and neither is a change to this workflow.

The name a rule should require is CodeQL as well as Analyze (go), since a
required Analyze (go) alone would be a context that stays green over a critical
alert. That is #47's decision.

The parity row expecting CodeQL and Analyze (csharp) to collapse into
Analyze (go) is contradicted by the run above: both names report here, so
CodeQL is not a name this repository has to give up.

What would close this issue is a done-when naming the check that can refuse a
finding. Rewriting the done-when is not a call to make from inside the work it
judges.

[iderex]

Reopened. This was closed by the merge of #115, whose body carries the phrase does not close #12 and the platform reads the keyword without the negation. Its done-when is not met: the comment above measures that a deliberate finding reds the check named CodeQL and leaves Analyze (go) green.

[iderex]

This issue was closed automatically on 09.08.2026 at 13:23:09Z when #115 was
merged - against the explicit text of the pull request.

The body of #115 says verbatim "It does not close #12" and "So #12 stays
open". The merge commit says "which is why the issue stays open". The platform
did not read the negation, only the number.

It is therefore reopened.

Why it belongs open: the acceptance criterion is not met

The done-when calls for a deliberately planted finding that turns the check
RED that this issue is named after. The near miss in #115 showed the
opposite.

Measured at commit 9f88de84603f5d2b651687b30b7f213330c1221a, on which a
critical go/command-injection lay in the tree:

Analyze (go)   Lauf 93249383918   SUCCESS
CodeQL         Lauf 93249460902   FAILURE   (App: GitHub Advanced Security, app_id 57789)

Alert 12: go/command-injection, critical
Annotation: internal/nearmiss/injection.go:17:39-51

Analyze (go) only reports WHETHER the analysis ran. The SARIF upload succeeds
even with a finding. What reacts to a finding is the check of the GHAS app, and
that one is called CodeQL.

So the near miss did not prove that the scanner refuses. It proved that a
critical finding leaves the job green.

What this means for the gate plan

That belongs on #47. A ruleset that carries Analyze (go) as a required check
would NOT have held on exactly this critical finding - the job was green.

Today's state does not make it urgent, but not harmless either:

gh api repos/Flowfin/site/rulesets/20572614
  types: deletion, non_fast_forward, pull_request
  required_status_checks: keine

There is currently no required check at all. Whoever sets one up has to name
CodeQL and not Analyze (go) - and that is exactly the kind of detail one
gets wrong while setting it up when it is written down nowhere.

Two routes from here

A - this issue stays open until a required check exists that goes red on a
finding, and a near miss shows it. That is the done-when as it stands.

B - the done-when is corrected to CodeQL and this issue is then closed on
purpose, because the proof for THIS name is already in: the finding turned
CodeQL red.

I recommend B with one condition: the correction is factually right, but it
must not happen without the line in #47 that pins down the name. Otherwise the
proof is delivered and the knowledge of which name bites is lost again.

Which of the two applies is mine to decide. Until then it stands open, because
that is the state #115 itself wanted.

[iderex]

Three lines of the comment of 2026-08-09 are in German, and two of them name the wrong object as well

This repository writes in English. Three lines of that comment do not:

gh issue view 12 --repo Flowfin/site --json comments \
  --jq '.comments[] | select(.createdAt=="2026-08-09T15:36:06Z") | .body' | grep -n -E '\b(Lauf|keine)\b'
19:    Analyze (go)   Lauf 93249383918   SUCCESS
20:    CodeQL         Lauf 93249460902   FAILURE   (App: GitHub Advanced Security, app_id 57789)
41:      required_status_checks: keine

Run 2026-08-27. Lauf is run and keine is none.

None of the three is a paste of what a command printed, which is the case an
indented block around foreign evidence covers. gh api repos/Flowfin/site/rulesets/20572614
answers in JSON rather than in the two-space form line 41 sits in, and lines 19
and 20 are a table assembled by hand rather than the output of anything. So the
block they sit in is holding prose, and the prose is in the wrong language.

The noun is wrong too, and that one costs a reader a 404

Lauf in a GitHub interface names a workflow run. Neither number is one:

gh api repos/Flowfin/site/actions/runs/93249383918
gh: Not Found (HTTP 404)

Both are check runs, which is the object the paragraph around them is actually
about, since its whole point is that two check names answer different questions:

gh api repos/Flowfin/site/check-runs/93249383918 --jq '{id,name,conclusion,head_sha}'
{"conclusion":"success","head_sha":"9f88de84603f5d2b651687b30b7f213330c1221a","id":93249383918,"name":"Analyze (go)"}
gh api repos/Flowfin/site/check-runs/93249460902 --jq '{id,name,conclusion,head_sha}'
{"conclusion":"failure","head_sha":"9f88de84603f5d2b651687b30b7f213330c1221a","id":93249460902,"name":"CodeQL"}

All three run 2026-08-27. So the three lines read, in this repository's language
and naming what they name:

Analyze (go)   check run 93249383918   SUCCESS
CodeQL         check run 93249460902   FAILURE   (App: GitHub Advanced Security, app_id 57789)
  required_status_checks: none

The comment of 2026-08-09 stands as it was written. The correction lives here
rather than in an edit to it, so the reading that found it and the repair are
both visible instead of one replacing the other.

What the corrected line says is still true

Re-taken rather than quoted back:

gh api repos/Flowfin/site/rulesets/20572614 \
  --jq '{enforcement, bypass:.bypass_actors, required:[.rules[].type], checks:[.rules[]|select(.type=="required_status_checks")|.parameters]}'
{"bypass":[],"checks":[],"enforcement":"active","required":["deletion","non_fast_forward","pull_request"]}

Run 2026-08-27. There is still no required status check on the default branch of
this repository, which is what line 41 said and what the paragraph it sits in is
for. The measurement that paragraph rests on is unmoved: a critical finding left
Analyze (go) green and turned CodeQL red, and the two check runs above are
that pair at the commit that carried the finding.

What this does not move

The done-when, and the two routes out of it. Nothing above settles which of them
applies, and this issue stays open on that.

[iderex]

The ruleset quoted yesterday returns a fourth rule today, and the sentence it was quoted for is unmoved

The reading of 2026-08-27 closes with the live shape of this repository's
default-branch ruleset. That output no longer reproduces:

gh api repos/Flowfin/site/rulesets/20572614 \
  --jq '{enforcement, bypass:.bypass_actors, required:[.rules[].type], checks:[.rules[]|select(.type=="required_status_checks")|.parameters]}'
{"bypass":[],"checks":[],"enforcement":"active","required":["deletion","non_fast_forward","pull_request","required_signatures"]}

Run 2026-08-28. The list carried three entries yesterday and carries four now,
and the new one is required_signatures. The change is recent rather than
something the earlier reading missed:

gh api repos/Flowfin/site/rulesets/20572614 --jq '{created_at,updated_at,enforcement}'
{"created_at":"2026-08-08T00:09:02.548+02:00","enforcement":"active","updated_at":"2026-08-28T14:22:58.455+02:00"}

Run 2026-08-28. Still one ruleset on this repository, so there is no second one
holding a check the query above would not see:

gh api repos/Flowfin/site/rulesets --jq '.[] | {id,name,target,enforcement}'
{"enforcement":"active","id":20572614,"name":"gate","target":"branch"}

Run 2026-08-28.

What that does and does not do to the paragraph it stood in

Nothing to it. That output was quoted for one sentence, that there is still no
required status check on the default branch of this repository, and checks is
still empty in the run above. So the conclusion holds and the paste under it had
stopped reproducing, which is the pair worth separating rather than leaving a
reader to find a difference and guess which half moved.

What it does change is the price of getting the name wrong later. Whoever sets a
required check now edits a ruleset that already refuses an unsigned commit, so a
branch that reaches it carries verified signatures and an empty check list, and
the two facts arrive together in the same object.

What this does not move

The done-when, and the two routes out of it. This is a correction to a quotation
and settles neither, and this issue stays open on that.