Branch protection is inconsistent fleet-wide, and no repo requires its own test suite

[twistedmelonman]

Origin

Noticed while merging a queue of Dependabot PRs on 2026-08-29: landing one PR
pushed the next to BEHIND, forcing @dependabot rebase, which pushed the
one after it to BEHIND. Four rebase cycles on amelia-boone (#63, #64, #66),
none of which surfaced a real conflict.

The obvious question was "should we turn off require-branch-up-to-date?" A
fleet-wide survey says that is the wrong question — or at least not the first
one. The rebase cycles are a symptom; the protection configuration is
inconsistent and, in most repos, gating on almost nothing.

What the fleet actually looks like

Surveyed all 39 non-archived repos across both orgs
(gh api repos/OWNER/REPO/branches/main/protection), 2026-08-29:

Configuration	Count	Repos
strict: true, requires claude-review only	27	most of the fleet
strict: true, requires nothing	5	networth-agent, smartwatermelon/.github, dumbify, huddle-transcribe, x-thread-reader
strict: true, requires validate + claude-review	1	personify
No protection at all	6	claude-code-workflows-agents, Instapaper-MCP, nightowlstudiollc/.github, pr-review, repo-template, scripts, superpowers

Three distinct problems fall out of that table.

Problem 1: strict: true with an empty required-checks list — 5 repos

strict governs when required checks must re-run. With zero required checks
it enforces a rebase and then gates on nothing at all. This is pure cost with
no protection whatsoever.

All five have CI workflows that could be required. dumbify has validate.yml,
huddle-transcribe has lint.yml, and every one has
claude-blocking-review.yml — none are in contexts.

Problem 2: test suites are advisory-only, fleet-wide

This is the significant one. No repo requires its own test or build job.
claude-review / run-review is the only required check anywhere except
personify:

Repo	Has	Required?
dotfiles	bash-tests.yml (18 test files, 110 assertions)	❌ advisory
projectinsomnia	build.yml (includes check-audit-baseline.sh)	❌ advisory
amelia-boone	ci.yml (Code standards & build)	❌ advisory
kebab-tax-netlify	test.yml (unit, HTML, functions, audit, icons)	❌ advisory
personify	validate	✅ required

A red test suite does not block a merge in any repo but personify. Note
kebab-tax-netlify#252 deliberately removed continue-on-error: true from
three of those jobs to make them blocking — but they were never added to
contexts, so the intent did not actually land.

This also interacts with a known failure mode: a green check whose job skipped
without running still reads as green. Requiring a check that can silently skip
is not the same as requiring the work.

Problem 3: six repos have no protection at all

Including scripts, which is on this machine's PATH and whose contents run
against every repo, and repo-template, which is presumably the seed for new
repos — so the gap propagates.

The original question, in context

Should strict: true be turned off?

Argument for: the only required check on 27 repos reviews the diff, not
the merged tree. Re-running it after a rebase re-reviews the same diff and
returns the same verdict. The rebase buys nothing the previous run did not
already establish.

Argument against: semantic conflicts — branch and main each merge cleanly
but combine into something broken. Real, but catching it requires test
coverage on the merged result, and per Problem 2 tests are not required
anywhere. So today strict: true is not buying that protection either.

Tentative shape (to be confirmed, not a decision):

• Repos that deploy on merge (projectinsomnia, amelia-boone,
  kebab-tax-netlify, tnjcleaning, night-owl-studio, crazy-larry):
  keep strict: true and add the build/test job to contexts. That is
  when strict starts earning its keep.
• Repos with no deploy step (dotfiles, claude-config, dev-env,
  github-workflows, scripts): add the test job to contexts; strict
  becomes optional and can probably go.
• The 5 empty-context repos: decide whether they want protection at all, and
  configure it coherently either way.
• The 6 unprotected repos: decide deliberately rather than by omission.

Open questions

• Is there a fleet-standard protection profile anywhere, or has each repo been
  configured ad hoc? repo-template having no protection suggests the latter.
• Should this be enforced as code (a script in dotfiles/scripts that
  asserts a profile per repo class) rather than clicked in the UI? The
  Dependabot auto-merge rollout used a propagation script for exactly this
  reason.
• Does requiring a check interact badly with the auto-merge workflow, which
  enables auto-merge and lets GitHub land the PR once checks pass? Probably
  fine, possibly not for checks that skip.
• personify is the only repo doing this right. Worth understanding whether
  that was deliberate.

Not urgent

Nothing is on fire. The cost today is rebase cycles and a weaker gate than
intended, not broken output. Worth a deliberate pass rather than a quick
sweep — changing protection rules across 39 repos is exactly the kind of
change that wants a plan and a dry run.