Overwrite mode is documented as idempotent, but Steps 6 and 7 are not #172

Gap

Overwrite mode is described in Step 1 of create-dev-loop.md with the words "Steps 6–7 still run, idempotently re-asserting the repo and registry entry", and the claim is repeated at README.md:57. The commands prescribed by those Steps are not idempotent against artifacts created by an earlier fresh run.

What is prescribed for a second run

The following was read from create-dev-loop.md at a0b80a4:

• Step 6, line 689: gh repo create <slug>-dev-loop --private ... is run with no existence check, although the repo was already created by the fresh run.
• Step 6, line 698: git remote add origin ... is rejected when an origin remote is already configured in the skill directory.
• Step 6, line 700: a second "Initial commit" is recorded by git commit -m "Initial commit: ...", or the commit is rejected if the regenerated file is unchanged.
• Step 6, line 717: gh label create is called without --force, so an already-existing label is rejected.
• Step 7, line 735: a new row is appended to the catalog table with no check for an existing row, so the entry is duplicated rather than re-asserted.

These outcomes were derived from the prescribed commands and the documented behavior of gh and git. No actual overwrite run was executed, since a real skill repo would have been touched. gh label create --help could not be run in this dispatch, so the --force behavior still needs to be confirmed.

Why it matters

Step 6 is either aborted partway through, or each failure is improvised around by the executing agent, with no guarantee that two generations are handled the same way. Overwrite is presented in the README as a safe re-assertion, so no warning is given to the user.

Suggested action

The documented behavior should be kept, and the commands should be brought into line with it:

• gh repo create should be skipped when the repo is found by gh repo view.
• git remote add should be replaced by an add-or-set-url form.
• A regeneration commit message should be used outside MODE=fresh, and an empty diff should be tolerated.
• --force should be passed to gh label create.
• An existing Step 7 row should be updated instead of a new one being appended.

Step 6's commands would be changed, but not what Step 6 creates, so gardener's interface is expected to be unaffected. That should be confirmed when the change is made, since Step 6 is treated as load-bearing by CLAUDE.md.

This gap was found during a Stage A documentation sweep. Under the Stage A rule it was filed rather than fixed, since the intended behavior is described correctly by the docs and the Steps are what is wrong.

This issue was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener).

drafted by Claude on behalf of Daniel Stephenson