ci.yml calls its gates merge-blocking; `main` has no protection at all, and the repo was never registered with the standards program

[ChelseaKR]

Two related facts, both verified today.

main is unprotected

• gh api repos/ChelseaKR/perimeter/rulesets returns an empty list.
• gh api repos/ChelseaKR/perimeter/branches/main returns "protected": false.
• gh api repos/ChelseaKR/perimeter/branches/main/protection returns 404,
  "Branch not protected".

So main can be force-pushed, deleted, or pushed to directly with red CI. The
verify, secret-scan and sast jobs run and report; none of them blocks
anything.

.github/workflows/ci.yml opens with:

Least-privilege GITHUB_TOKEN, SHA-pinned actions, and the merge-blocking gates:
SAST, secret scan, and make verify ...

That sentence is not true of this repository. A reader who opens the workflow to
check the posture is told the opposite of what the server enforces, which is worse
than saying nothing.

Controls: CICD-13 (AUTO, required status checks: format, lint, type, test,
security + zizmor + codeql-actions), CICD-16 (AUTO, force-push to main blocked
via non_fast_forward), CICD-11 (AUTO, Scorecard Branch-Protection >= 8/10).
ledger's protect-main is the working reference in this portfolio.

Two gates named by CICD-13 have no implementation here at all: there is no zizmor
job and no CodeQL workflow, in a repo whose CI runs Node and Python and publishes
to GitHub Pages from a second workflow.

The repo was never onboarded

The portfolio conformance checker's FIX-02 discovery gate reports perimeter as
existing in the portfolio and not registered in its applicability manifest. Nothing
has ever decided which standards bind this repo, which is why the gaps below are
unrecorded rather than tracked:

Control	Gate	Status here
FIX-02	AUTO	No applicability-manifest entry
DOC-11	AUTO	_readme_conformance_table reports "no 'Standards Conformance' section in README"
DOC-04	AUTO	docs/adr/ exists and is empty; no 0000-record-architecture-decisions.md, no MADR template
DOC-01	AUTO	No .standards-version and no pinned standards reference

CITATION.cff, SECURITY.md, CONTRIBUTING.md, CHANGELOG.md and
.github/dependabot.yml are all present, so this is the last mile rather than the
first.

The docs/adr/ case deserves a note of its own: several genuinely
architectural decisions are already written up as prose in README.md and
docs/MARKERS.md (the three-state cell model, treating an out-of-domain value as
outside_published_domain rather than an error, the published-versus-inferred
marker split). An empty ADR directory beside that much recorded reasoning is a
filing problem, not a thinking one.

Done looks like

• A protect-main ruleset requiring verify, secret-scan and sast by their
  job names, plus non_fast_forward and deletion.
• zizmor and CodeQL (language: actions) added and required, or each recorded as
  a waiver with an owner and an expiry.
• An applicability-manifest entry created, via the standards program's
  repo-registration script.
• A fifteen-row Standards Conformance table in README.md and an ADR log with
  0000 plus the decisions the README already argues for.
• The ci.yml header comment describes what is actually enforced.

[ChelseaKR]

Re-verified against the code and against the live repository on 2026-09-01. Four of the five items under "Done looks like" have landed since this was written. The fifth is a live repository setting and is yours, so this stays open, narrowed to that one action.

Done

The ci.yml header no longer calls the gates merge-blocking. It now opens by naming what runs, then says in as many words that "these gates report. As of 2026-08-15 they block nothing", quotes the three API answers, points at the committed profile, and ends "Edit this paragraph when the ruleset goes on, not before." The sentence this issue objected to is gone.

zizmor and CodeQL both exist. .github/workflows/ci.yml carries four jobs, verify (L38), secret-scan (L73), sast (L94) and zizmor (L111, online mode on purpose so the audits needing the API are not silently dropped). .github/workflows/codeql.yml carries analyze, named codeql (actions · python · javascript), triggering on pull_request: branches: [main]. All five contexts report on every PR; they were confirmed doing so on the head commits of #30 and #31, and again on #41 today.

The applicability manifest has an entry. Added 2026-08-15, read 2026-08-27: archetype civic-data-tool, publication cleared and public since 2026-08-08, tier B+C, flags html: true, hosted: true, dockerfile: false, llm: false, bilingual: false, fourteen of fifteen standards applying with AI Evaluation N/A. FIX-02's discovery gate has nothing left to report. The README table transcribes it with the date it was read, and says plainly that the registry lives in another repository so nothing in CI can check the transcription.

DOC-11, DOC-04 and DOC-01 are met. README.md carries a fifteen-row Standards Conformance table stating what is true rather than what is intended, and tests/test_standards_conformance.py fails on a blank state. docs/adr/ holds 0000-record-architecture-decisions.md, a MADR template.md, and eleven records, several of them the back-filled decisions this issue named: the three-state cell model is 0001, out-of-domain values are 0002, the published-versus-inferred marker split is 0003. .standards-version pins v2.0.0 and the conformance test reads it.

Not done, and not mine to do

No ruleset is applied. Measured again today:

Question	Answer
gh api repos/ChelseaKR/perimeter/rulesets	[]
gh api repos/ChelseaKR/perimeter/branches/main	"protected": false
gh api repos/ChelseaKR/perimeter/branches/main/protection	404, "Branch not protected"

So main can still be force-pushed, deleted, or pushed to with every check red, and CICD-13, CICD-16 and CICD-11 are unmet in fact rather than unimplemented in the repository. The protect-main profile is committed at .github/rulesets/main.json and requires all five contexts by their reported names, plus non_fast_forward, deletion, required_linear_history and required_signatures.

Applying it is a POST against the live repository and the owner's call. Two things worth reading before you run it, both in .github/rulesets/README.md: the file must carry RepositoryRole 5 with bypass_mode: always before it is posted, and POST adds a ruleset rather than replacing one, so posting twice leaves a second empty-bypass ruleset over main. tests/test_ruleset.py now fails if the bypass actor is ever lost from the file.

The two zizmor and codeql waivers this issue offered as an alternative are not needed: both are implemented, and requiring them is part of the same single apply.

[ChelseaKR]

Re-checked every item on this issue's "Done looks like" list against origin/main at
6948cb2 and against the live repository today, 2026-09-06. Five of the six are done. The
sixth is the one that cannot be done from a pull request.

Done-looks-like item	State today	Evidence
ci.yml header describes what is actually enforced	done	The header now opens "These gates report. As of 2026-08-15 they block nothing." and states that main carries no ruleset, that rulesets returns [], and that applying the committed profile is the owner's call
zizmor added	done	zizmor job in .github/workflows/ci.yml, online mode, zizmor==1.29.0 (#16)
CodeQL added, language: actions	done	.github/workflows/codeql.yml, languages: actions,python,javascript-typescript, security-extended, and a gate that fails on no-SARIF rather than passing on it
applicability-manifest entry created	done	Registered 2026-08-15; transcribed into the README standards table by #30, which verified every field against applicability.yml directly
fifteen-row Standards Conformance table, and an ADR log with 0000	done	README "Standards conformance" carries all fifteen rows; docs/adr/ holds 0000 plus eleven decisions and a template; .standards-version pins v2.0.0 and tests/test_standards_conformance.py reads it
a protect-main ruleset, applied	not done, and it needs you	gh api repos/ChelseaKR/perimeter/rulesets still returns [] and branches/main still returns "protected": false

The one thing left, and why it stops here

The profile itself is written and reviewed. .github/rulesets/main.json requires
verify, secret-scan, sast, zizmor and codeql (actions · python · javascript) by
the exact job names those checks report under, plus deletion, non_fast_forward,
required_linear_history and required_signatures. #32 already fixed the lockout this
file would have caused on its first apply, so bypass_actors carries the repository-admin
role rather than being empty.

Applying it is a live repository setting, not a file, and it is a setting that can lock
its owner out. That is the reason this is left for you rather than done here. It is one
command:

gh api -X POST repos/ChelseaKR/perimeter/rulesets --input .github/rulesets/main.json

Two things worth knowing before you run it. All five required contexts are reporting
green on main today, and the check names are exact: codeql (actions · python · javascript) contains non-ASCII middle dots, which is why codeql.yml pins the job's
name: rather than letting it be generated. And required_signatures means every future
commit on main must be signed, including merge commits GitHub creates, so squash-merges
from the web UI are signed by GitHub and are fine, while an unsigned local push is not.

Also worth recording, because a row in the README now says the wrong thing

The Security row states "Dependabot alerts are disabled on the repository, so SEC-15 has
nothing to read". That is no longer true. repos/ChelseaKR/perimeter/vulnerability-alerts
returns 204 (enabled) and dependabot/alerts returns four, all four the fast-uri
advisories and all four now fixed by #53. What is still disabled is
dependabot_security_updates, so alerts are raised and no security-update PR is opened
from them. I am sending a separate PR to make that row say what is actually the case.

Prepared with AI assistance; reviewed before submission.

[ChelseaKR]

Verified this rather than inheriting it. I applied nothing — no ruleset, no branch protection, no repository setting was changed. Below is what I could confirm, one thing I could not, and a defect I found that should land first.

The committed profile is sound

.github/rulesets/main.json is rule-compliant on the point that matters most. It carries exactly one bypass actor:

"bypass_actors": [
  { "actor_id": 5, "actor_type": "RepositoryRole", "bypass_mode": "always" }
]

That is the correct value and it must stay. An empty list here is not a stricter gate, it is the lockout.

The five required contexts still match the workflows, re-derived from origin/main today rather than trusted — worth re-checking because #48 and #54 both touched workflow files after the README's last measurement:

Context in main.json	Source	Still matches
verify	ci.yml, job verify, no name:	yes
secret-scan	ci.yml, job secret-scan	yes
sast	ci.yml, job sast	yes
zizmor	ci.yml, job zizmor	yes
codeql (actions · python · javascript)	codeql.yml, job analyze, its name:	yes

Land #69 before applying this

I found a real defect while checking the above, fixed in #69. ci.yml runs on push: branches: [main] and keyed its concurrency group on github.ref with cancel-in-progress: true, so every push to main shared one group and cancelled its predecessor. A cancelled run is not a failure, it is no signal — the commit lands on main with no verdict and nothing says so. Six PRs merged inside 45 minutes this morning (#44, #45, #48, #55, #56, #57), which is exactly the pattern that collides.

This is a prerequisite rather than a detail: turning on five required checks over main while main-push runs silently cancel each other makes that gap harder to see, not easier.

Three facts in .github/rulesets/README.md have gone stale

The file's measurements are dated 2026-08-15/28/29. Re-read from git today:

• "all fourteen commits on main" → main now has 64 commits.
• "the three merge commits already on main" → there are now 12.
• "all fourteen commits on main report verification.verified: true, so nothing is locked out by turning [required_signatures] on" → 13 commits on main today carry no signature at all (git log origin/main --format='%G?' returns N for them; newest is 1b90643, 2026-08-15). The other 51 carry SSH signatures I could not verify locally without an allowed-signers file.

To be clear about the consequence: this does not block the apply. A ruleset governs new pushes, not existing history — the README makes that point itself about required_linear_history, and it applies equally here. But the sentence is no longer a true statement about main, and it is the stated evidence for recommending the riskiest rule in the profile, so it should not be what anyone relies on.

What I could not verify, and why it matters

I could not re-read the live ruleset state. The account was under a GitHub secondary (concurrency) rate limit throughout; every read of rulesets, branches/main and branches/main/protection returned HTTP 403 between 19:47 and 20:02 UTC, including after a 300-second backoff.

So I cannot confirm today that the README's "no ruleset is applied" still holds, and neither should you assume it. Re-run these three before applying anything:

gh api repos/ChelseaKR/perimeter/rulesets
gh api repos/ChelseaKR/perimeter/branches/main --jq .protected
gh api repos/ChelseaKR/perimeter/branches/main/protection

This is not pedantry. POST /rulesets adds a ruleset, it does not replace one, and rules from every applicable ruleset combine while bypass actors are per-ruleset. Applying on top of an existing ruleset leaves a second one over main, and if that first one has no bypass, the owner is locked out whatever this one allows.

Ready to run, owner-only

# 1. confirm nothing is applied yet (above), then:
gh api -X POST repos/ChelseaKR/perimeter/rulesets \
  --input .github/rulesets/main.json

# 2. confirm the bypass survived — an apply that lands every rule and loses
#    this actor still returns 201, and that is the lockout:
gh api repos/ChelseaKR/perimeter/rulesets --jq '.[]|{id,name}'
gh api repos/ChelseaKR/perimeter/rulesets/<id> --jq .current_user_can_bypass   # must be "always"
gh api repos/ChelseaKR/perimeter/rulesets/<id> --jq .bypass_actors             # must hold exactly the one actor

If step 2 shows the bypass missing, delete the ruleset immediately (gh api -X DELETE repos/ChelseaKR/perimeter/rulesets/<id>) while you still can.

Leaving this open. Applying a live repository setting is yours, not a pull request's, and not an agent's.

Prepared with AI assistance; reviewed before submission.

[ChelseaKR]

Re-measured today (2026-09-06). Five of the six "Done looks like" items have landed; one remains and it is yours.

Item	State on origin/main today
zizmor and CodeQL added	✅ zizmor is a job in ci.yml; .github/workflows/codeql.yml exists and reports as codeql (actions · python · javascript)
applicability-manifest entry	✅ landed in #30 ("The manifest entry this table said did not exist")
Standards Conformance table in the README	✅ ## Standards conformance, pinned to .standards-version v2.0.0 and gated by tests/test_standards_conformance.py
ADR log with 0000	✅ docs/adr/ holds 13 ADRs including 0000-record-architecture-decisions.md
ci.yml header describes what is actually enforced	✅ it now says in terms that these gates report and block nothing, and names the committed profile
A protect-main ruleset applied	❌ still not applied

Re-confirmed just now, the same three ways this issue opened with:

gh api repos/ChelseaKR/perimeter/rulesets          -> []
gh api repos/ChelseaKR/perimeter/branches/main     -> "protected": false
gh api repos/ChelseaKR/perimeter/branches/main/protection -> 404 Branch not protected

The committed profile at .github/rulesets/main.json is correct and ready: all five
required contexts still match jobs that exist and report, and bypass_actors carries
exactly the owner's RepositoryRole 5 / always entry.

Applying it is deliberately left to you and this comment is not asking an agent to do
it. A POST to /rulesets adds a ruleset rather than replacing one, so a second
apply would leave a second ruleset over main, and rules combine while bypass actors are
per-ruleset.

What did get fixed here is the evidence around it. PR #70 corrects
.github/rulesets/README.md, which had drifted badly: it argued for required_signatures
from "all fourteen commits on main" (there are 66) and against a merge commit from "the
three merge commits already on main" (there are 12). Both conclusions survive
re-measurement.

One finding worth recording here, because it nearly went the other way: a local
git log --format='%G?' reports N, "no signature", for thirteen commits on main.
Those commits are not unsigned. They are SSH-signed with your key, and git 2.55 reports
an SSH signature as N when no gpg.ssh.allowedSignersFile is configured. Measured
against the API this document actually cites, 0 of 66 commits fail verification. So
required_signatures is still safe to turn on, and the reasoning behind that
recommendation is now written down with the instrument named.

Prepared with AI assistance; reviewed before submission.

[ChelseaKR]

Re-measured against origin/main @ d4f533f and the live repository (2026-09-06). Most of this has shipped; two items have not, and both are the owner's.

From "Done looks like"	State now
ci.yml header describes what is actually enforced	Done. The header now says in terms that the gates report and block nothing, that main carries no ruleset, and that the paragraph must be edited when the ruleset goes on and not before.
zizmor added	Done. zizmor runs and reports success on pull requests.
CodeQL (language: actions) added	Done. codeql (actions · python · javascript) and the CodeQL check both run and pass.
DOC-04: ADR log with 0000 plus the decisions the README argues for	Done. docs/adr/ holds 0000 through 0011 and a template — the three-state cell model, out-of-domain values counted rather than errored, published-versus-inferred marker basis, and a gate having to be able to fail are all written up.
DOC-01: .standards-version	Done. Present on main.
DOC-11: README "Standards conformance" section	Done. README.md §"Standards conformance".
A protect-main ruleset requiring verify, secret-scan, sast, plus non_fast_forward and deletion	Not done. rulesets is [] and branches/main reports "protected": false.
Applicability-manifest entry via the standards program's registration script	Not done, and not visible from here.

Why the last two stay open and should not be taken by automation.

Applying a ruleset is a live repository setting, and a POST adds one rather than replacing one, so a mistaken profile is not a revert away. The committed profile at .github/rulesets/main.json carries exactly the owner's RepositoryRole 5 / always bypass entry, and tests/test_ruleset.py already refuses a profile that would lock the owner out — that guard exists because an empty bypass_actors list once locked her out of a repository in this portfolio and restoring access took a sweep across eighteen repos. Applying it is hers to do.

One measurement caution for whoever picks this up. Reading repos/ChelseaKR/perimeter/rulesets with a token that lacks ruleset-write access returns bypass_actors redacted, so an empty list read back is not evidence that no bypass is configured. The [] above is the ruleset list being empty, which is a different and unambiguous fact.

And a correction that belongs on the record here, because this issue is where signature posture gets argued: a local git log --format='%G?' over main reports N for thirteen commits. Those commits are not unsigned. They are SSH-signed, and git 2.55 reports N for an SSH signature when no gpg.ssh.allowedSignersFile is configured; supply any allowed-signers file and the same commits report U. Measured against the API that required_signatures actually enforces, zero of the 66 commits on main lack a signature. PR #70 carries that correction into .github/rulesets/README.md.

Needs from the owner: apply the ruleset, and register the repository with the standards program.

Triaged with AI assistance.

[ChelseaKR]

Re-measured today. Most of this is built; what is left is one live repository setting that is yours.

Done and on main:

• zizmor is a job in .github/workflows/ci.yml (arrived with ci: scan the workflows, which nothing here has ever done #16); codeql.yml exists and runs actions, python and javascript. Both gates named by CICD-13 that had no implementation now have one.
• The false sentence is gone. The ci.yml header no longer calls these gates merge-blocking; it states in terms that they report, that main carries no ruleset, and that the profile which would make the sentence true is committed at .github/rulesets/main.json. It ends "Edit this paragraph when the ruleset goes on, not before."
• .github/rulesets/main.json is committed with deletion, non_fast_forward, required_linear_history, required_signatures, a pull-request rule, and the five required contexts (verify, secret-scan, sast, zizmor, codeql (actions · python · javascript)). It carries bypass_actors: [{actor_id: 5, actor_type: RepositoryRole, bypass_mode: always}], so applying it cannot lock you out.
• .github/rulesets/README.md maps every required context to the job that produces it, which is the part that usually goes wrong.
• .standards-version is v2.0.0; README.md has its Standards conformance section; docs/adr/ holds 0000 plus eleven decisions; tests/test_ruleset.py, test_ruleset_evidence.py and test_standards_conformance.py gate all of it.

Still open, and not something automation should do:

1. Applying the ruleset. gh api repos/ChelseaKR/perimeter/rulesets still returns [] and branches/main still reports "protected": false. Applying a committed profile is a live repository setting, and ci.yml records in its own comment that this is your call. Note it requires required_signatures, so it interacts with Cut the first signed tag #49.
2. The applicability-manifest entry (FIX-02). That registration lives in portfolio-standards, not in this repository, and is out of scope for anything working here.

Leaving this open for those two. Both are recorded in the campaign's owner-decisions file.

Prepared with AI assistance; reviewed before submission.

[ChelseaKR]

Triage against origin/main @ b35a8d67, 2026-09-08. Six of the seven items in "Done looks like" have landed. The two that have not are both live repository settings, which is why they are still here.

Landed, verified in the tree rather than from memory:

Item	Where
The ci.yml header describes what is actually enforced	It now opens "These gates report. As of 2026-08-15 they block nothing", quotes the three API calls that show it, says the previous header was the opposite of what the server enforces, and points at the committed profile
A protect-main ruleset profile	.github/rulesets/main.json, with .github/rulesets/README.md beside it
zizmor	a job in ci.yml; the check run reports on every PR
CodeQL, language: actions	codeql.yml; the check run reads codeql (actions · python · javascript)
.standards-version	present, pinned at v2.0.0, and tests/test_standards_conformance.py reads it
A Standards Conformance table in the README	README "Standards conformance", from line 334, and tests/test_standards_conformance.py fails on a row that stops being true
An ADR log with 0000 and a template	docs/adr/ holds 0000 through 0011 plus template.md. The empty-directory finding is closed, and the decisions the README argues for are written up: the three-state cell model is 0001, out-of-domain values are 0002, the published-versus-inferred marker split is 0003

Still open, and both are yours alone:

1. Applying the ruleset. gh api repos/ChelseaKR/perimeter/rulesets still returns [] and branches/main still returns "protected": false, measured today. The profile is committed and reviewed; turning it on is a repository settings change. The ci.yml header says in terms not to edit its paragraph until it goes on, so the document and the server stay honest either way.

2. Registering the repository with the standards programme. The applicability manifest lives in a private repository. Nothing here can create the entry.

Nothing left in this issue is automatable, and the parts that were are done. Leaving it open as the record of the two settings changes.

Triaged with AI assistance.

[ChelseaKR]

Re-measured against origin/main at ee88edb today (2026-09-10). Everything in "Done looks like" has shipped except the one step that is a live repository setting.

item from this issue	state today
ci.yml header calls the gates merge-blocking	corrected — the header now says in terms that the gates report and block nothing, names the three API reads that prove it, and says to edit the paragraph only when the ruleset goes on
no zizmor job	shipped — zizmor job in ci.yml, pinned zizmor==1.29.0, online mode with a comment on why offline would be silent
no CodeQL workflow	shipped — codeql.yml, languages: actions,python,javascript-typescript, security-extended
docs/adr/ empty	shipped — 0000 plus eleven ADRs and a template, including the three decisions this issue said were argued in prose (three-state cells, out-of-domain values, published-vs-inferred basis)
no .standards-version	present
no README conformance section	present (## Standards conformance)
main unprotected	still true. gh api repos/ChelseaKR/perimeter/rulesets returns []

The remaining step, and one thing measured so it is not a leap of faith

.github/rulesets/main.json is committed and its own README says applying it is the owner's call. Two things checked before saying it is ready:

1. The bypass actor is there. bypass_actors: [{"actor_id": 5, "actor_type": "RepositoryRole", "bypass_mode": "always"}]. An empty list has locked this account out of a repository before.

2. Every required context actually reports — the deadlock this repo's own ruleset README warns about does not apply. A required check that never reports never turns green. The profile requires five contexts; read off the head SHA of a real pull request (#88, 29a96b8):

codeql (actions · python · javascript) :: success
sast                                   :: success
secret-scan                            :: success
verify                                 :: success
zizmor                                 :: success

All five, names matching the profile exactly. Worth noting why that needed a PR head to check: codeql.yml triggers on pull_request and schedule, not push, so the same read against a main commit shows only four of them and looks like a missing context. Required status checks gate pull requests, so the PR head is the right place to read.

So this issue is now one command, and it is yours. Left open.

Prepared with AI assistance; reviewed before submission.