CodeQL default setup and a committed advanced workflow cannot coexist — 3 metadatastician repos run both, and the advanced one is rejected at upload

[hyperpolymath]

Summary

Three metadatastician repos run two CodeQL configurations at once, and they are mutually
exclusive. GitHub's default setup is enabled and an advanced workflow
(CodeQL Security Analysis) is committed. The default setup succeeds; the advanced workflow runs
to completion and is then rejected at SARIF upload:

##[error]Code Scanning could not process the submitted SARIF file:
CodeQL analyses from advanced configurations cannot be processed when the default setup is enabled

Measured on main on 2026-09-23:

repo	CodeQL (default setup)	CodeQL Security Analysis (advanced)	failing before?
metadatastician/first-post	✅ success	❌ failure	no — was startup_failure, newly visible
metadatastician/harvard-dehallucinator	✅ success	❌ failure	yes, pre-existing
metadatastician/metadatastician-governance	✅ success	❌ failure	yes, pre-existing

How it surfaced

These were found while landing the estate-wide codeql-action re-pin (hyperpolymath/standards#1005).
On first-post the advanced workflow had been dead at startup — its actions.lock recorded
github/codeql-action@v4.37.9 while the workflow pinned @v4.38.1, and GitHub compares those by
literal string, so the run never started. Fixing the pin brought the workflow back to life, and it
immediately hit the same conflict the other two already had.

This is not a regression. Nothing was broken by the re-pin; a workflow that had not executed for
some time started executing and revealed a configuration conflict that was already there.
failure here means "did not complete", not "found a vulnerability" — no security finding is
implied by any of these three reds, and none of them is currently producing alerts from the
advanced configuration.

Why it should not be left

The advanced workflow is doing real work — checkout, build, database creation, the full analysis —
and then throwing the result away at the last step. So the repo pays the whole cost of a scan,
reports a red check, and gets no alerts from it. Meanwhile the default setup is quietly doing
the actual scanning. The red is also indistinguishable at a glance from a genuine security failure,
which is the more expensive problem.

The decision to make

These are mutually exclusive by design; one of them has to go. Both are defensible:

• Keep default setup, delete the advanced workflow — simplest, zero maintenance, and it is what
  is actually producing alerts today. Loses per-language/query customisation and any custom
  queries: or paths-ignore: the workflow carries.
• Keep the advanced workflow, disable default setup — needed if any of the three requires a
  custom query pack, a non-default language matrix, or build-mode control. Requires a settings
  change per repo (Settings → Code security → Code scanning → default setup → disable).

⚠ Whichever way it goes, it should be the same choice in all three, and ideally an estate rule
in standards, since this will recur every time a repo gains default setup while carrying a
committed CodeQL workflow.

Acceptance criteria

• AC1 — Decide the estate rule. Default setup or advanced workflow, not both. Record the
  decision in standards so new repos inherit it. Owner call; blocks AC2.
• AC2 — metadatastician/first-post. Apply AC1. Afterwards main shows exactly one CodeQL
  workflow and it concludes success.
• AC3 — metadatastician/harvard-dehallucinator. Same, verified the same way.
• AC4 — metadatastician/metadatastician-governance. Same, verified the same way.
• AC5 — Before deleting any advanced workflow, diff it against the default setup's coverage:
  confirm no custom queries:, paths-ignore:, config-file: or extra language is being lost.
  If something is, that repo takes the other arm of AC1 and the reason is recorded here.
• AC6 — Detection. A governance check that flags a repo having default setup enabled and a
  committed CodeQL workflow, so this is caught at the point it is introduced rather than the next
  time someone reads a red check. If a repo is a deliberate exception, it carries a documented
  exemption rather than a permanent red.

Not in scope

The four repos still showing an unrelated startup_failure on main — betlang
(Comprehensive Quality Gates, Test), universal-chat-extractor (Secret Scanner), burble
(Hypatia Security Scan, OSSF Scorecard), first-post (SonarQube). All were verified dead on the
pre-merge parent as well; they are separate defects with separate causes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm

[hyperpolymath]

AC5 result — this inverts the assumption behind AC1, so nothing has been changed yet

The decision taken was "disable default setup, keep the pinned advanced workflow", on the
reasoning that the advanced workflow is the version-controlled, SHA-pinned, lockfile-visible one
and that this makes all 40 repos uniform. That reasoning still holds. But AC5 says to check what
would be lost before changing anything, and what would be lost is substantial:

repo	default setup covers	advanced workflow covers
metadatastician/first-post	actions, javascript, javascript-typescript, python, typescript — extended query suite	actions only, build-mode: none
metadatastician/harvard-dehallucinator	actions, javascript, javascript-typescript, python, typescript — extended	actions only, build-mode: none
metadatastician/metadatastician-governance	actions, python — default	actions only, build-mode: none

The advanced workflow in all three is a single-entry matrix analysing only GitHub Actions
workflows. It is not a richer configuration than default setup — it is a much narrower one.
Switching to it as written would drop four languages and downgrade two repos from the extended
query suite to default. That is a measurable reduction in security coverage, which is the
opposite of what AC1 was chosen to achieve.

AC5 is doing exactly its job here, so it is being honoured rather than worked around: no
settings have been changed and no workflow has been deleted.

The arm that satisfies the ruling without the regression

Bring the advanced workflow up to parity first, then disable default setup:

1. Expand the matrix to the languages default setup currently covers in that repo.
2. Set the query suite explicitly — queries: security-extended for first-post and
   harvard-dehallucinator, matching what they get today.
3. Confirm the expanded workflow goes green (adding javascript/python analysis can surface
   build-mode problems that actions-only never exercises).
4. Only then set default setup to not-configured.

That keeps every property the ruling was chosen for — one uniform, SHA-pinned, lockfile-visible
configuration across all 40 repos — while ending up with coverage equal to or better than today.
It is more work than a settings flip, and step 3 can fail, which is why it is being put back to
the owner rather than assumed.

The alternative reading is that these three repos take the other arm — keep default setup and
delete the actions-only advanced workflow — which is the outcome AC5 was written to allow. That
resolves the red immediately and loses nothing that is running today, at the cost of those three
repos not matching the other 37.

Until that is settled, the three reds remain; they are a configuration conflict and not a
security finding, and nothing is being scanned less than it was yesterday.

🤖 Generated with Claude Code

https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm