Six repos call the shared CI with no pull_request trigger — lint, test and the security gate run only on tags

[felixgeelhaar]

Sweeping the 24 repos that call the shared go-ci.yml / js-ci.yml, six have no pull_request trigger on their thin caller. None of them scans main on push either. So for a quarter of the fleet, the shared lint, test and nox security gate run only on release tags — or, for senat-os, only when someone clicks the button.

Repo	Triggers on ci.yml	Effect
pet-medical-www	push: tags [v*], workflow_dispatch	tags only
brotwerk	push: tags [v*], workflow_dispatch	tags only
rollops-studio	push: tags [v*], workflow_dispatch	tags only
kraftsport-coach	push: tags [v*], workflow_dispatch	tags only
senat-os	workflow_dispatch only	never runs automatically
lexora	push: tags [v*], workflow_dispatch	fixed in klarlabs-studio/lexora#25

The other 18 have pull_request and are fine.

Why this is worse than "CI is a bit thin there"

In lexora the gap was load-bearing for a decision. Its security.yml deleted the repo's own nox job with this justification:

the former nox security-gate job was removed — it duplicated the shared go-ci Security (nox) job … Code scanning is gated there on every PR/push

The premise was false for that repo: the shared job was not wired to PRs at all. A working local gate was removed in favour of one that essentially never ran. It is worth checking whether the same reasoning was applied to any of the other five.

This also compounds with #47: even on the rare tag build, any repo whose .nox.yaml sets output.format produced no findings.json, so the gate step skipped — and a skipped step is green.

Suggested rollout

I deliberately did not open five more PRs. These repos have never been PR-gated, so enabling the trigger may light up lint, test and security failures all at once, and each needs a human deciding what is worth fixing versus baselining.

lexora#25 is the pilot — it adds the trigger and the checks on that PR are the first real evidence of what happens. Recommend:

1. Land lexora#25, see what the shared CI actually says about a previously ungated repo.
2. Roll the trigger out to the remaining five one at a time, worst-first, rather than in a batch.
3. senat-os probably deserves a look beyond the trigger — a repo whose CI has only ever run manually is unlikely to be green.

The one-line change in each case is:

on:
  pull_request:
    branches: ["main"]
  push:
    tags: ["v*"]
  workflow_dispatch: {}

matching armada, dispatch and bolt.

[felixgeelhaar]

Widening this: the gap is not only how the shared CI is triggered, but whether some repos have CI at all.

Auditing all 29 repos, they fall into four groups:

Group	Count	Repos
Shared CI, pull_request trigger — healthy	18	mnemos, briefkasten, warden, armada, statekit, rollops, coverctl, fortify, mcp-go, scout, fortify-ts, bolt, agent-go, auth-go, axi-go, vorhut, dispatch, nomi
Shared CI, no pull_request trigger	6	pet-medical-www, brotwerk, rollops-studio, kraftsport-coach, senat-os, lexora (fixed in lexora#25)
Own CI, adequately triggered	3	nexa, keyward, pet-medical
No CI at all	2	episteme-api, pet-medical-ui

The two with no CI

• episteme-api — only nox-remediate.yml and provenance.yml. No build, no test, no lint, no security gate. I noticed because I merged episteme-api#6 there (nine golang.org/x/crypto advisories including auth bypass) and not a single check ran on it. I had verified go build, go test and a re-scan locally, but nothing in CI did. A repo can carry critical CVEs and have no automated way to learn it.
• pet-medical-ui — only publish.yml. It can publish, but nothing verifies what it publishes.

Note that episteme-api does have a committed nox baseline and was one of the repos showing net-new critical/high in the fleet scan — so it looked gated from the outside. Nothing was reading that baseline on a PR; only the scheduled nox-remediate touches it.

Revised suggestion

Priority order, roughly by exposure:

1. episteme-api — adopt the shared go-ci.yml. It is a Go service that was until an hour ago carrying six critical advisories, with nothing to catch the next one.
2. senat-os — CI exists but has only ever run manually.
3. The four tag-only repos — add the pull_request trigger, one at a time.
4. pet-medical-ui — decide whether it warrants CI or is genuinely publish-only.

Still recommending these land one repo at a time rather than as a batch: each has never been gated, so the first green-to-red transition needs a human deciding what is worth fixing versus baselining. lexora was the pilot and it came out clean — Security (nox): pass, net-new critical/high: 0 (baselined findings: 57) — which is encouraging but not evidence about the others.

[felixgeelhaar]

Worked through this. 24 of 25 repos on the shared CI now run it on pull requests, up from 18.

Repo	PR	Result
episteme-api	#7	merged — adopted go-ci from nothing; first CI it has ever had, fully green
senat-os	#277	merged — was workflow_dispatch only
brotwerk	#40	merged
rollops-studio	#9	merged
kraftsport-coach	#148	merged
lexora	#25	merged earlier (the pilot)
pet-medical-www	—	still open, see below

Every one of them came out green on its first-ever PR run. That is a better outcome than I expected when I recommended a staged rollout, and it means the caution was cheap rather than wasted.

episteme-api needed two fixes to meet the bar rather than lower it: a real connection-pool leak in cmd/server (log.Fatalf after defer pool.Close() — os.Exit meant the defers never ran) and a gofmt nit. coverage: false there because the repo has no _test.go files at all.

pet-medical-www — not a trigger problem

Its CI fails at Install dependencies, not on anything the trigger changed:

npm error 403 Permission installation not allowed to Read organization package
  @klarlabs-studio/pet-medical-ui

The package is internal and linked to a different repo, so this repo's GITHUB_TOKEN needs an explicit Manage Actions access grant — not settable via any REST endpoint, so it needs a UI action. Notably the dependency has been consumed since 2026-06-13 and a pull_request run succeeded on 2026-07-03, so this is a change in package access rather than a consequence of enabling the trigger.

Diagnosis handed to pet-medical-www#23, which already existed and predates my attempt by three hours — I opened a duplicate without checking first and closed it.

Still open on this issue

• pet-medical-www — package access grant, then feat(js-ci): reusable JS/TS CI workflow #23 merges.
• pet-medical-ui — still no CI at all (only publish.yml). It publishes the package above; worth deciding whether publish-only is intentional.

One process note worth recording: while doing this I broke js-ci.yml fleet-wide with a duplicate YAML key (#50). It surfaced here, on pet-medical-www#24, as a run with no jobs, no logs and no check contexts. If you ever see that shape, gh workflow run <file> --ref <branch> prints the parse error that the PR run never surfaces.

[felixgeelhaar]

Closing the loop on this. The trigger half is done — all six repos now have pull_request — but the sweep surfaced that fixing the trigger was only half the problem.

Triggers

repo	state
pet-medical-www	fixed (klarlabs-studio/pet-medical-www#23)
lexora	fixed (klarlabs-studio/lexora#25)
brotwerk	had pull_request
rollops-studio	had pull_request
kraftsport-coach	had pull_request
senat-os	web-ci.yml now runs on PRs (klarlabs-studio/senat-os#276); ci.yml deliberately left manual — see below

The half this issue didn't cover

Four of them — brotwerk, rollops-studio, kraftsport-coach, lexora — were running the full shared bar on every PR with branch protection present but required_status_checks.contexts: []. CI ran, reported, and gated nothing. A red ci / Security (nox) could not stop a merge.

That is a quieter version of the same defect this issue describes: the first case is a check that never runs, the second is a check that runs and cannot fail. Both look fine from the outside.

All four now require:

ci / Lint · ci / Test (ubuntu-latest) · ci / Build · ci / Security (nox) · Warden provenance

Verified beforehand that none has paths-ignore on pull_request — that combination makes required contexts unmergeable forever, since a skipped workflow reports nothing rather than reporting skipped. klarlabs and fortify-ts needed that removed first (klarlabs-studio/klarlabs#21, klarlabs-studio/fortify-ts#43).

senat-os ci.yml, deliberately not restored

Not an oversight. It was made manual with measured evidence: tag runs re-ran the full 5-job matrix against already-merged code that warden had already verified locally with the identical commands (go test -race, golangci-lint, nox scan in .warden.yaml) — 2,095 billable minutes in July, the repo's largest line item, and it never caught anything. Its web-ci.yml was the real gap, because warden's pre-push bar there is Go-only, so apps/web was genuinely unverified. That one now runs on PRs and is a required context.

Fleet state

All 13 repos in the day's sweep now test pull requests and enforce required contexts.

https://claude.ai/code/session_012qFD1UhQT9tiKkMsPAskK7

[felixgeelhaar]

Verified fixed. All six repos now have a properly wired pull_request trigger on their thin caller, and all six have real pull_request runs:

Repo	on:	last pull_request run
pet-medical-www	pull_request: branches: [main]	success 2026-07-25
brotwerk	wired	success 2026-07-26
rollops-studio	wired	success 2026-07-25
kraftsport-coach	wired	success 2026-07-25
senat-os	pull_request: branches: ["main"]	failure 2026-07-26
lexora	wired (#25)	—

Checked the trigger blocks themselves, not just the presence of the string, since pull_request appearing in a file proves nothing about wiring.

senat-os is red, and that is the fix working rather than a new problem. All four jobs fail — Lint, Build, Test and Security (nox). CI had never run there automatically (workflow_dispatch only), so nothing was holding it green; turning the trigger on ran code that had not been checked in a long time. Same shape as lexora, where the missing trigger was load-bearing for the decision to delete that repo's own nox gate.

Filing the senat-os remediation separately — it is a repo-specific fix, not part of the wiring gap this issue tracks.

Closing: the trigger gap described here is closed across all six.

[felixgeelhaar]

Correction to my previous comment: senat-os was not broken.

I reported it as red with all four jobs failing and read that as the restored trigger exposing rot. It was a GitHub billing block — every job failed with steps=0, meaning nothing ran at all:

The job was not started because recent account payments have failed or
your spending limit needs to be increased.

That affected every private repo org-wide, which is why the same day's work on the public repos ran normally. Billing has since been resolved, and a fresh dispatch on main is fully green:

ci / Build:                success  steps=7
ci / Lint:                 success  steps=8
ci / Security (nox):       success  steps=13
ci / Test (ubuntu-latest): success  steps=10

No senat-os remediation issue is needed; I won't file one. The trigger-wiring gap this issue tracks remains correctly closed.

Worth remembering for next time: steps=0 on every job means a startup failure, not a code failure, and gh run view --log-failed prints nothing in that state — the reason is only in the check-run annotations.