Replace the onboarding-branch entry with the sequence that avoids cleanup

[ptr727]

Replaces the onboarding-branch entry added in #504 with the sequence Pieter proposed after watching Blog hit the problem.

What changed and why

The #504 entry said the initial commits belong on a feature branch and reach develop by squash. That is correct, but it still treats main and develop as branches an agent might commit onto and then have to clean up. Blog tried to squash its standup work back onto the main and develop it had already committed to, and was blocked, which is the ruleset doing its job.

The proposed sequence removes the problem rather than managing it:

1. Create main, carrying nothing.
2. Create develop from main, carrying nothing.
3. Create the first feature branch from develop and do the whole standup there.
4. Add the repo to GitHub and apply the repo config while still on that branch.
5. Open a normal pull request to develop when the repo is ready.

Nothing ever has to be cleaned off main or develop, because nothing ever reached them without review.

Two details the write-up would otherwise get wrong

A git branch cannot exist without a commit. "Carrying nothing" therefore means exactly one signed empty root commit (git commit --allow-empty), not a literally empty ref. Section 0's signing window applies to that commit like any other, so it has to be signed before it is made.

Squashing afterwards is not an escape hatch. non_fast_forward is set on both develop payloads, so once history reaches develop it cannot be rewritten without disabling the ruleset. That is why Blog was blocked rather than merely inconvenienced.

The gap this fills

STANDUP.md says nothing about how main and develop come into being. Section 0 covers signing before the first commit, section 0A covers the human-gated prerequisites, and section 2 covers carrying the baseline files, but the branch bootstrap between them is undocumented. An agent with no instruction commits onto whichever branch it finds itself on.

Worth noting the protection is uneven, which the entry records:

Payload	Rules	Direct commit to develop
repo-config/develop.json (release)	adds pull_request, required_linear_history, required_status_checks, copilot_code_review	blocked
repo-config/operational/develop.json	deletion, non_fast_forward, required_signatures only	succeeds

On an operational repo the ruleset alone would not stop a direct commit, so only the instruction stands between it and an unfixable history. That is the argument for documenting the sequence rather than relying on the gate.

Correction, after this PR was opened: Blog is release, not operational. I had classified it wrongly, and Pieter corrected it. The test is where the config lives, since operational is for config that sits on the actual server, and Blog builds and pushes releases out instead. So Blog's own develop is PR-gated and the ruleset does block it. That strengthens the entry rather than weakening it: the uneven-protection point stands for every genuinely operational repo, and the bootstrap sequence is what keeps main and develop clean in both models.

The reason it matters on a public repo: the exploratory standup history is where PII, secrets and noise commits accumulate, and squashing a feature branch is the one chance to leave them out.

Verification

prose_lint TODO.md  (dash, semicolon, charset, charset-unknown, dupword, spelling, sentence-split)   clean
prose_lint . --check charset --check dupword --check spelling                                        clean
markdownlint-cli2 (docker)    0 issues
cspell (docker)               0 issues

cspell rejected "unreviewed" on the first pass. Rephrased rather than adding a word to cspell.json, since one entry's worth of dictionary growth is not worth a phrasing that had an ordinary alternative.

Backlog only. The STANDUP.md change itself is the work this entry describes, not this PR.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the TODO backlog entry that tracks the planned STANDUP.md onboarding guidance, replacing the prior “initial commits on a feature branch then squash to develop” write-up with a more explicit branch-bootstrap sequence that avoids ever needing to clean up main/develop.

Changes:

• Replaces the existing STANDUP.md-documentation backlog item with an explicit “bootstrap main/develop then do standup on first feature branch” sequence.
• Adds the key constraint that “carrying nothing” still requires a (signed) empty root commit, and notes that non_fast_forward prevents later history rewrites on develop.
• Records the operational vs release ruleset difference (repo-config/develop.json vs repo-config/operational/develop.json) as motivation for documenting the safer sequence.