docs(security): move the built gitleaks and SBOM jobs out of "Planned CI additions" (BACKLOG #1485)

[wshallwshall]

What

docs/SECURITY.md's "Supply-chain & CI security" section listed the gitleaks secret scan and the CycloneDX SBOM build under Planned CI additions. Both are built. Files BACKLOG #1485 and fixes it in the same PR.

Verified against the tree at 4c68c28eb (origin/main's tip in the same run)

the claim, as it stood	what the tree says
SBOM is planned	security.yml's sbom job builds CycloneDX SBOMs for the engine and the VS Code extension, scores them with sbomqs, uploads them; trivy adds the container image. ADR 0149, docs/SUPPLY-CHAIN.md.
secret-history scan is planned	security.yml job gitleaks, name: gitleaks (secret scan) -- that exact string is in .github/required-contexts.txt.
"Kept in CI rather than a per-author pre-commit hook"	.pre-commit-config.yaml pins repo: https://github.com/gitleaks/gitleaks, rev: v8.18.4, hook id gitleaks. Both exist.
the scan runs "over the full git history"	BACKLOG #1479 scoped it with --log-opts HEAD (merged as a1f3232a1).
pip-audit and bandit are "advisory"	Both job comments read BLOCKING, neither declares continue-on-error, and both context strings are required.

One more, in the sentence directly above the block: it told the reader to enable CodeQL through GitHub Advanced Security "on a private repo". codeql.yml has run here for a long time and this repository is public, so no licence is involved. security.yml's own header already records that correction.

The scope wording

The new text states the scan's scope nowhere. It names the step that holds it (Scan the ref under test for secrets) and stops. A second copy of that fact is exactly what went false last time, and the job-level comment in security.yml says in terms that the scope must not be restated (SDS-3.5).

Two things worth a reviewer's attention

1. tests/test_cutover_slug_rot.py is touched. Its triage taxonomy cited the removed GHAS sentence by name as a KEEP example. The docstring now records the retirement instead of pointing at a line that no longer exists. No logic changed. The ratchet count falls 39 to 38 against a ceiling of 41; test_the_ratchet_is_not_slack allows 8 slack, so the ceiling is deliberately left alone.
2. docs/Secure_Build_Scorecard_MEFOR.md is deliberately NOT touched. It says "gitleaks full-history" at lines 31, 58 and 93, one of them the evidence for signal 5 graded Built -- Strong, so that evidence is now overstated by exactly the scope #1479 removed. That file is a dated scoring snapshot ("Scored 2026-07-14") whose own convention is that re-scoring is an owner act. #1485 names the three lines for whoever re-signs it.

Checks run

• pre-commit run --files on all three changed files: every hook passed (ledger gate, forbidden-content, gitleaks, ruff).
• ruff check, ruff format --check, mypy on tests/test_cutover_slug_rot.py: clean.
• pytest on the tests that read these files -- test_cutover_slug_rot, test_backlog_status_check, test_required_contexts, test_merge_gate_controls, test_docs_security_pathways, test_adaptive_attributes_doc_drift, test_security_posture, test_docs_cite_no_refused_config_keys: 413 passed.
• scripts/docs/backlog_status_check.py, backlog_citation_check.py, link_check.py: OK.
• Not run: the full suite, and the hosted-only legs (windows-service-smoke among them). Read those in CI.

🤖 Generated with Claude Code

[wshallwshall]

Ledger tail adjacency, measured — for whoever sequences these

Three open PRs append to the tail of docs/BACKLOG.md. All hunk positions below are three-dot against each branch's own merge-base, so main's work is not miscounted as anyone's deletion.

PR	item	hunk	state now
981	#1484	@@ -24617,3 +24617,39 @@	MERGEABLE / BLOCKED
982 (this one)	#1485	@@ -24617,3 +24617,39 @@	MERGEABLE / BLOCKED
976	#1480	@@ -24343,3 +24343,122 @@	CONFLICTING / DIRTY

981 and this PR conflict with each other. Identical start line and context. git merge-tree --write-tree on the two heads exits 1 with a content conflict in docs/BACKLOG.md. Both read mergeable only because GitHub computes each against main and neither has landed.

976 does not conflict with either of us today. Its merge-base is a1f3232a1; 24343 was the tail as the file stood then. It conflicts with main, which has since taken 8 commits touching BACKLOG.md. After it rebases, its item lands at the current tail and joins this contest.

The resolution is verified, not assumed

Keep both items in number order. Built that resolution and ran the gate on it:

• item sets: main 446, 981 447 (adds 1484), this PR 447 (adds 1485), resolved 448 — exact union, nothing missing, nothing extra.
• scripts/docs/backlog_status_check.py --backlog <resolved> exits 0: 448 backlog items, each declaring exactly one status, with the one pre-existing #1426 advisory that is also on main.
• #1484 at line 24620, #1485 at 24657, each with its own heading, body, and a single banner.

Order

I have no claim to going first. 981 is the older PR and touches one file; this one touches three, so it carries more surface to go red. Land 981 first and I will rebase. Not rebasing pre-emptively: nothing has landed to rebase onto, and a push would discard the CI runs queued on this head.

[github-actions]

@wshallwshall

This pull request is green and nobody has marked it read.

Every check that has reported is passing and the reviewed label is absent, so
a reviewer has read this is the only thing between it and a merge. Nothing else reports that, which is
why this comment exists (BACKLOG #1413).

To clear it, IN THIS ORDER:

1. If the branch is behind main, update it FIRST: gh pr update-branch --repo MEFORORG/MessageFoundry 982.
   That push fires synchronize, and synchronize REMOVES the reviewed label. Labelling
   before updating throws the label away and costs a round trip.
2. Read the diff.
3. gh pr edit 982 --repo MEFORORG/MessageFoundry --add-label reviewed

DO NOT TRIAGE THIS FROM mergeStateStatus. It returns one value with precedence, so BEHIND,
DIRTY and UNSTABLE each mask the missing check -- the requirement is invisible until you act on
something else. This check never reads that field; see scripts/ci/check_unread_prs.py.

A seat can find every pull request in this state in one call: gh pr list --label unread.

Adding reviewed withdraws unread: the label event re-evaluates this pull request,
and so does the next completion of a watched workflow. Those are the two edges that clear it, so a
change neither of them reports -- converting to a draft, say -- can leave the label standing until one
of them next happens.

The reviewed label is a PROCESS gate. It records that a step happened. It does not
establish that an independent party looked, and nothing here should be read as saying it does.

[github-actions]

@wshallwshall

This pull request is green and nobody has marked it read.

Every check that has reported is passing and the reviewed label is absent, so
a reviewer has read this is the only thing between it and a merge. Nothing else reports that, which is
why this comment exists (BACKLOG #1413).

To clear it, IN THIS ORDER:

1. If the branch is behind main, update it FIRST: gh pr update-branch --repo MEFORORG/MessageFoundry 982.
   That push fires synchronize, and synchronize REMOVES the reviewed label. Labelling
   before updating throws the label away and costs a round trip.
2. Read the diff.
3. gh pr edit 982 --repo MEFORORG/MessageFoundry --add-label reviewed

DO NOT TRIAGE THIS FROM mergeStateStatus. It returns one value with precedence, so BEHIND,
DIRTY and UNSTABLE each mask the missing check -- the requirement is invisible until you act on
something else. This check never reads that field; see scripts/ci/check_unread_prs.py.

A seat can find every pull request in this state in one call: gh pr list --label unread.

Adding reviewed withdraws unread: the label event re-evaluates this pull request,
and so does the next completion of a watched workflow. Those are the two edges that clear it, so a
change neither of them reports -- converting to a draft, say -- can leave the label standing until one
of them next happens.

The reviewed label is a PROCESS gate. It records that a step happened. It does not
establish that an independent party looked, and nothing here should be read as saying it does.