Name the prerequisites the agent cannot supply, and assert the remote

[ptr727]

Closes the gap reported in #490, found by standing Blog up against STANDUP.md.

What happened

Blog reached 24 signed commits, the full carried instruction set, the baseline files, a working build, a proven URL gate, and a site serving locally. The GitHub repository did not exist. Steps 0 through 3 all completed, step 4 was never reachable, and the maintainer found it by asking rather than by anything in the procedure reporting it.

Verified against the tree rather than taken on report: STANDUP.md contains no occurrence of gh repo, remote, or origin, and names the maintainer exactly three times, none of them for an onboarding input.

Why the procedure allowed it

Step 0 implies a local git init and step 4 presumes a remote, with nothing in between creating the repository or saying who does. The inputs that can only come from a human were never enumerated, so each blocked at the step that needed it instead of being handed over at the start. And every local step passes with no remote at all, so the procedure reported progress the whole way.

What lands

Step 0A lists what only the maintainer can supply, as a checklist to hand over before step 1:

• the repository, with owner, name, and visibility
• the GitHub App installed on it, not merely created (repo-config/README.md already states the distinction)
• the App secret values, in the Actions and Dependabot stores both
• every publish credential and environment the repo's mechanisms declare in spec/secrets.json

Creating a repository is an outward-facing write, so it sits behind the per-session permission GOVERNANCE.md "Repository Boundaries and Write Safety" requires, and the agent asks rather than assuming.

Two statements carry the rest of the failure:

• A repo with no remote is not partially stood up. It is not started. Local progress is not evidence of onboarding progress, and AUDIT.md reads a live repo, so the one instrument that would catch this is unavailable exactly while it holds.
• A blocking prerequisite is escalated when it is found, not carried. In a task list it renders identically to a pending task, which is how this one survived an entire session while work continued around it.

Step 4 asserts the remote before running anything, with gh repo view <owner>/<repo>. An absent repository otherwise surfaces as a resolution error from whatever configure.sh calls first, which reads as a permissions or naming problem rather than the missing prerequisite it is.

Step 4 also states why it follows step 3. A ruleset requiring a check name no run has ever reported leaves the first pull request waiting on a status nothing produces, and an operational repo promotes by pull request too, so this is not only a release-repo concern.

One deviation from the issue's suggestion

#490 says the check-name fact "is currently in repo-config/README.md rather than in the step that needs it". It is in both: step 4 already ended with it. So this adds the ordering consequence rather than restating the fact, since duplicating a rule into a second location is its own defect.

Verification

• python3 scripts/prose_lint.py . --check charset --check dupword --check spelling clean tree-wide, and the warn set clean on STANDUP.md. Both invocations match the CI steps in validate-task.yml rather than the narrower ad-hoc default.
• markdownlint-cli2 and editorconfig-checker clean.
• CRLF-only by byte scan, 24 insertions and 1 modified line.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the repository standup procedure (STANDUP.md) to explicitly surface maintainer-only prerequisites up front and to fail fast when the target GitHub repository/remote prerequisites are missing, addressing the onboarding stall described in #490.

Changes:

• Adds a new step 0A listing onboarding inputs the agent cannot supply (repo creation, app installation, secrets/publish credentials), and instructs escalation when a prerequisite is blocking.
• Updates step 4 to assert the target GitHub repository exists before running repo-config/configure.sh, and explains why the ordering follows workflow standup.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (2)

STANDUP.md:99

• In a POSIX shell, < is input redirection, so copy/pasting gh repo view <owner>/<repo> ... will fail. Use a placeholder format that is safe to paste (e.g., OWNER/REPO).

gh repo view <owner>/<repo> --json nameWithOwner,visibility

STANDUP.md:95

• The checks here confirm (1) an origin remote exists and (2) the target repository exists on GitHub, but they do not verify that origin actually points to that repo. Consider adjusting the wording to avoid implying a stronger assertion than the commands perform.

**Assert that the repository exists and that this checkout points at it**, since this is the first step needing either and every step before it passes without both:

[ptr727]

Answering the two suppressed findings from round 2, since neither reaches a thread. Both accepted, fixed in 427cfb27b8c4fe556926692eda36f8feadf85997.

1. <owner>/<repo> is not pasteable. Correct, and it is the worse kind of doc bug because the reader is being told to run the line. In a POSIX shell < is input redirection, so the command fails on paste with an error about a file rather than about the repository. The rest of this file already writes it [owner/repo], so the block was also inconsistent with its own document. It is now the bare OWNER/REPO form, which survives a copy and reads unambiguously as a placeholder.

2. The wording still overclaimed, one round after the first correction. Also correct. Reading a remote proves a remote exists, resolving a repository proves the repository exists, and neither proves the first points at the second. The step now says the agent compares the two outputs and names that comparison as the third thing being checked, rather than implying the commands do it.

Worth recording that this is the second round on the same sentence. The first correction added the local half after gh repo view alone was called an assertion of the remote, and the heading then absorbed a claim the new command still did not support. A heading that summarizes two commands is where an overclaim hides, because the commands underneath look like evidence for it.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (2)

STANDUP.md:99

• The placeholder OWNER/REPO in the example command is inconsistent with the rest of this document’s placeholder style (e.g., reports/<repo>/...) and can be read as a literal. Using the same <owner>/<repo> convention makes it clearer that the value must be substituted.

gh repo view OWNER/REPO --json nameWithOwner,visibility

STANDUP.md:102

• This paragraph says “Any of the three” even though only two commands are listed above, and the three distinct conditions being checked (missing origin, missing repo, or mismatch) aren’t explicitly named. Reword to avoid the dangling reference and make the checked conditions explicit.

Each command answers half the question, and the agent compares the two outputs to confirm they name the same repository, which neither command checks on its own. A checkout with no `origin` has nothing to push to even where the repository exists, and it is the state a local-only standup reaches with every step reporting success. An absent repository instead surfaces as a resolution error against whatever `configure.sh` calls first, which reads as a permissions or naming problem rather than as the missing prerequisite it is. Any of the three turns a confusing stall into a specific one, and any of them is step 0A's escalation rather than something to work around.

[ptr727]

Answering the two suppressed findings from round 3. Both accepted, fixed in ac79eb6026f1efbab0624f4a7faaf8717ece2ab6.

1. Placeholder style. This one contradicts the round-2 finding on the same line, which asked for a pasteable placeholder precisely because an unquoted < is input redirection. Rather than pick a side, the line now quotes it, which satisfies both:

$ echo gh repo view "<owner>/<repo>" --json nameWithOwnergh repo view <owner>/<repo> --json nameWithOwner
$ echo gh repo view <owner>/<repo> --json nameWithOwnerbash: line 1: owner: No such file or directory

The document's convention is kept and the command survives a paste. The prose says why the quotes are there, so the next editor does not helpfully remove them.

2. "Any of the three" with two commands listed. Correct, and the dangling reference hid the more useful content. The three conditions are now named as separate bullets: no origin, no repository, and the two disagreeing. The third is the one neither command reports, which is what the previous round's correction was about, so it now appears as a condition to check rather than as a clause inside a paragraph.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.