Skip to content

docs(register): C-86 is live — the trigger has fired - #263

Merged
Polichinel merged 4 commits into
developmentfrom
docs/c86-trigger-has-fired
Aug 13, 2026
Merged

docs(register): C-86 is live — the trigger has fired#263
Polichinel merged 4 commits into
developmentfrom
docs/c86-trigger-has-fired

Conversation

@Polichinel

Copy link
Copy Markdown
Collaborator

protect_main now requires the test check on main, with zero bypass actors. Verified against the live ruleset and observed working — PR #262 sat at BLOCKED until CI went green.

The entry said "latent rather than live". That stopped being true.

Also records the decision rather than leaving it open: no bypass actor. Added in advance it is a permanent hole against a hypothetical; added during an incident it is a console action taking under a minute.

🤖 Generated with Claude Code

Polichinel and others added 4 commits August 13, 2026 06:33
Sync development → main: version/tag agreement, and epic #241's Gate 2/3
protect_main now requires the `test` check on `main` with zero bypass actors.
Verified against the live ruleset and observed working: PR #262 sat at BLOCKED
until CI went green. A merge to main — the release to FAO — now requires
views-appwrite reachable, and admin status is not an exemption.

The entry said "latent rather than live" and that stopped being true. The
exposure is also as small as it can be: one sibling checkout instead of two,
and a drift check that fires on 13 rows per partner instead of 25.

DECISION RECORDED, not left open: no bypass actor. Added in advance it is a
permanent hole against a hypothetical; added during an incident it is a console
action taking under a minute. This paragraph is what makes that a two-minute
decision rather than a discovery.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…their evidence

The ritual on #263, and it caught the sentence I had flagged as least certain plus one
I had not.

THE RULESET CLAIM HOLDS, and is better evidenced than I wrote. `protect_main` version
46391648 added `required_status_checks: [{context: "test"}]` at 2026-08-13 04:51 CEST;
version 45955166 before it had no such rule. So the trigger fired at a datable instant
and the "latent" assessment was true right up to it. The API also reports
`current_user_can_bypass: "never"` for an admin account — stronger proof that admin
status is no exemption than the argument-from-semantics the entry originally made.

"PR #262 SAT AT BLOCKED UNTIL CI WENT GREEN" — WITHDRAWN. The required `test` check was
never red on #262. The only failing check was `check-branch`, which is NOT required and
blocks by a different mechanism. So the observation showed a failing check, not the
requirement biting. Replaced with what the record supports: the requirement was in force
before #262 opened, and the merge landed 21 seconds after `test` reported success.

"A WEEK AGO CI CHECKED OUT TWO SIBLINGS, NOW ONE" — FALSE. On 2026-08-06 it checked out
ONE, views-crafdapi. views-appwrite was added 08-10 once it went public; crafdapi was
removed 08-12. The count is unchanged at one; what changed is WHICH repository and what
the check does with it. The two-sibling window lasted about two and a half days. The real
reduction is in the matching, not the count: `meta.version` then, 13 declared rows now.

THE ENTRY WAS ASSERTING BOTH THINGS AT ONCE, in six places — title, Tier, Location, and
three body paragraphs still said "two repositories" and "latent today". My "original
assessment" marker also swept 122 lines including two later amendments that are not the
original assessment and are not wrong. Scoped properly, and the original is now marked
superseded rather than "wrong": it was true when written and correctly named both the
mechanism and the moment.

AND C-81 CONTRADICTED C-86 IN FIVE UNMARKED PLACES. Its enforcement half is DISCHARGED —
that is what "the required check exists" means — and its own closing paragraph warned
against making the check required and going live on an external dependency "in one
unremarked step". That is exactly what happened on 2026-08-13, so it is remarked there.

THE DECISION IS NO LONGER RECORDED AS SETTLED. `Owner` makes both responses console
actions, which CLAUDE.md puts on the operator's side. It now reads as my recommendation
pending assent. I had written it as decided, which was not mine to do.

Also deleted `tests/test_falsification_campaign_4_1.py`: an `assert False` probe under
`xfail(strict)`, whose entire purpose is to surface probes that start passing — and which
could never flip. Its finding is resolved. C-36's resolution already records this residual
for marker-style probes. The campaign table and the register entry that named the file are
updated in the same change.

Suite 422 passed / 2 skipped / 39 xfailed, ruff clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…nding held

/review-diff on the C-86 remediation, verifying the reviewer figures rather than
propagating them. All three held. But checking them surfaced one nobody had:

C-81 says protect_main's ref_name include-list is EMPTY, "so it matches nothing".
The ruleset has exactly two recorded versions — 45955166 from 2026-08-08 and
46391648 from 2026-08-13 — and the 2026-08-08 one already reads
include: ["~DEFAULT_BRANCH"]. So on 2026-08-10, when C-81 measured, the ruleset
DID match main. That half was wrong when written.

The finding survives on its other half, which was correct and was the one that
mattered: no required_status_checks rule. deletion, non_fast_forward,
pull_request, and nothing else. A red Run Pytest genuinely would not have blocked
a merge — not because the rules matched nothing, but because none of them was a
status check.

Verified this turn, not recalled: version 45955166 rules and conditions read from
the history endpoint; current_user_can_bypass = never for account Polichinel with
admin = true.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@Polichinel
Polichinel merged commit d290d39 into development Aug 13, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant