docs: turn PUBLISHING.md into an ordered sequence - #2
Merged
Merged
Conversation
Scope decision recorded: publication readiness is judged on THIS
repository's contents, and the credential question is out of scope here.
That is factually consistent with what this repo is — a fresh history,
not a filtered clone, created that way precisely so the development
history is absent rather than scrubbed. The value in question appears in
none of this repository's objects, and the commit that introduced it does
not exist here. The blocker framing has been removed accordingly; the
verification steps that prove the claim remain.
The file was a checklist in no particular order, which is the wrong shape
for something where three items only work in one direction. It now leads
with the sequence:
1. flip to public — everything below becomes possible at this point
2. enable secret scanning, push protection, private vulnerability
reporting (all free on a public repo, all refused with 422/404 on a
private one — I tried)
3. ./tools/apply_branch_protection.sh
4. delete the lychee self-link exclusion, as a PR
5. verify CodeQL ran for both `python` and `actions`
with the social preview and a first release as optional follow-ups.
Each step says why rather than just what, because the ordering is the
whole point: the security features cannot be enabled before step 1, and
the lychee exclusion must not be deleted before it either — GitHub
answers 404 to anonymous requests for a private repo, so the weekly
external link check would fail on the repo's own URLs for a reason that
is not a broken link.
Also verified as part of this: every external badge target in the README
returns 200, and the three self-referencing links are correctly shaped
for GitHub and will resolve on publication.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Scope decision recorded: publication readiness is judged on THIS
repository's contents, and the credential question is out of scope here.
That is factually consistent with what this repo is — a fresh history,
not a filtered clone, created that way precisely so the development
history is absent rather than scrubbed. The value in question appears in
none of this repository's objects, and the commit that introduced it does
not exist here. The blocker framing has been removed accordingly; the
verification steps that prove the claim remain.
The file was a checklist in no particular order, which is the wrong shape
for something where three items only work in one direction. It now leads
with the sequence:
reporting (all free on a public repo, all refused with 422/404 on a
private one — I tried)
pythonandactionswith the social preview and a first release as optional follow-ups.
Each step says why rather than just what, because the ordering is the
whole point: the security features cannot be enabled before step 1, and
the lychee exclusion must not be deleted before it either — GitHub
answers 404 to anonymous requests for a private repo, so the weekly
external link check would fail on the repo's own URLs for a reason that
is not a broken link.
Also verified as part of this: every external badge target in the README
returns 200, and the three self-referencing links are correctly shaped
for GitHub and will resolve on publication.