Skip to content

docs: correct new-repo section (bootstrapping is not automatic) - #4

Merged
Neil-Smithline merged 3 commits into
mainfrom
docs/correct-new-repo-bootstrapping
Aug 26, 2026
Merged

docs: correct new-repo section (bootstrapping is not automatic)#4
Neil-Smithline merged 3 commits into
mainfrom
docs/correct-new-repo-bootstrapping

Conversation

@Neil-Smithline

Copy link
Copy Markdown
Contributor

Why

docs/security-review-setup.md told readers, under Adding a new repo, that new repos are "protected as soon as they're created." That is false, and it is the exact false belief that lets unscanned code reach a protected default branch.

A brand-new empty repo has no default branch yet, so its first commit cannot go through a PR (a PR needs an existing base). Pushing code to an empty repo and then renaming a side branch onto the default — or repointing the default branch, or an admin bypass — lands unscanned code on a protected branch while the ruleset still reports all rules active. The repo looks governed; its initial code never was.

What changes

Docs only. Replaces the "Adding a new repo: Nothing" section with a "Creating a new repo" section that:

  • tells you to create repos with gh repo create --add-readme (or the UI "Add a README") so the default branch exists and is protected from commit zero
  • explains the chicken-and-egg reason the first commit can't be a PR
  • names the wrong workarounds (side-branch rename, default repoint, admin bypass) and says not to use them
  • states that a GH013 ... Required workflow ... is not satisfied rejection is the gate working as intended — stop and report, don't route around — for humans and AI coding agents (Claude Code, Codex, Gemini, …) alike

Note

This PR is itself a live test of the gate on a docs-only change: it should scan clean and be mergeable once Claude Security Review (required) passes.

🤖 Generated with Claude Code

Neil-Smithline and others added 3 commits August 26, 2026 11:33
The "Adding a new repo" section claimed new repos are "protected as soon
as they're created." That is false and actively dangerous: a brand-new
empty repo's first commit cannot go through a PR (no base branch exists),
and pushing code then renaming/repointing a side branch onto the default
lands unscanned code on a protected branch while the ruleset still reports
all rules active.

Replace it with explicit guidance: create repos with --add-readme so the
default branch exists and is protected from commit zero, do real work via
PRs, and treat a GH013 rejection as stop-and-report rather than something
to route around — for humans and AI coding agents alike.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Reviewer point: "a rejected push is never an obstacle to engineer around"
was too blunt — it could read as discouraging the legitimate recovery
(move changes to a branch, push, open a PR), which is the intended
workflow, not a workaround.

Split the guidance in two: (1) a rejected push to an existing default
branch just means "open a PR instead" — that works and is sanctioned;
the bypass is specifically landing code on the default WITHOUT a scanned
PR (rename onto default, repoint default, admin bypass). (2) commit zero
in a brand-new empty repo is the one case branch-and-PR cannot cover
(no base branch to target), which is why repos must be created with
--add-readme.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Clarify the importance of using a scanned PR to avoid bypassing security checks on the default branch.
@Neil-Smithline
Neil-Smithline merged commit 595925f into main Aug 26, 2026
3 checks passed
@Neil-Smithline
Neil-Smithline deleted the docs/correct-new-repo-bootstrapping branch August 26, 2026 19:30
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