Skip to content

Triage #126 — folded into the unreleased 1.15.1: reversibility carve-out, post-merge false positive, CI + scripts.test fixes - #127

Merged
cportka merged 1 commit into
mainfrom
claude/code-repo-setup-practices-var7xm
Aug 7, 2026
Merged

cportka merged 1 commit into
mainfrom
claude/code-repo-setup-practices-var7xm

Conversation

@cportka

@cportka cportka commented Aug 7, 2026

Copy link
Copy Markdown
Owner

Summary

Triage of #126 (greenfield-JS field report, nine items, three owner-confirmed HIGH). Folded into the still-unreleased 1.15.1 rather than cut as a new version — see the CI change below, which makes that legitimate rather than a bypass. repo-bootstrap → 1.15.1 (unchanged number; the version isn't tagged yet). Closes #126.

#8 — the carve-out keyed on firstness, and that inverted the contract. Owner-confirmed and the most consequential item: "a first prod release" matches every greenfield PR #1, so an agent following the standard correctly held a green PR the owner expected merged — on the single most common merge in a fresh repo. Step 4 now tests reversibility: hold only when a revert cannot undo the merge (auth/provider cutover, data migration, registry publish, coupled multi-service deploy, anything that emails/charges/notifies real users), with the explicit counter-example that a static site deploying for the first time is not that — merge it. The old phrase is gone from the block entirely so it can't be pattern-matched again.

#9 — the post-merge "1 unpushed commit" false positive. Deterministic for anyone following the branch-pinned restart: the local branch ends up exactly one merge commit ahead of origin/<pinned>, so a hook measuring origin/<branch>..HEAD flags work already on origin/main. The block now says to confirm with git rev-list HEAD --not --remotes --count and not to push to clear it — pushing puts the merge commit on the branch whose deletion is step 5's confirmation signal — and points at --heal-stop-hook, whose corrected hook already handles it. (This fired at me repeatedly during this very session.)

#1 — the scripts.test heads-up cried wolf. It fired whenever a test script existed, including node --test — the very script this tool writes — and asserted the scaffolded test "will NOT run", which is false. It now inspects the command, reassures for node --test/vitest/jest, and warns only when the script plausibly misses it, naming the node --test tests/ trap (MODULE_NOT_FOUND) rather than leaving the reader to find it.

Also: scaffolded CI filters push to main (#2 — it ran twice per PR commit; this repo's own workflow has done this since 1.10.0, the template never caught up) and pins Node for a JS repo via setup-node (#3); a Pages/deploy situational note (#5, full --pages still roadmap); the feedback path leads with the web/MCP form since repo-bootstrap exists for web sessions where gh is absent (#6); --heal-stop-hook is in --help (#7b) and SKILL.md no longer claims the stop-hook auto-installs (#7a — untrue since 1.15.0, and exactly how #9 reached a user). #7 withdrawn by the reporter.

CI — version-bump-guard now distinguishes released from unreleased. Releases here are hand-cut tags, often days after merge, so a version with no v<ver> tag is still mutable and work can be folded into it; once tagged it's immutable and a change must bump. That preserves the guard's actual purpose — a released version must never change underneath an installed copy — while allowing this release's folding.

Two self-inflicted bugs caught in testing and fixed before commit: the setup-node filler used open(p,"w") inline, which truncates before the read runs and produced an empty workflow; and $(...) stripped the step's trailing newline, welding it onto the next step. The suite now parses the generated YAML so neither can recur silently.

Tests: +3 cases, 315 green. Block text changed, so standard-version.txt → 1.15.1 and this repo's own block was regenerated.

Release checklist

  • Bumped version in .claude-plugin/plugin.json for each plugin whose files changed
    (CI's version-bump-guard enforces this). — Folded into unreleased 1.15.1; the guard now
    permits this and fails once v1.15.1 is tagged.
  • Added a ## [x.y.z] entry to CHANGELOG.md for the new version (CI checks every plugin
    version has a matching heading).
  • Updated the README plugin-table row(s) and the header Version: line to match. — No change
    needed: versions are unchanged.
  • Ran bash tests/run-tests.sh locally → 0 failures (or relied on CI).
  • Preserved existing script comments; annotated new/changed lines.

🤖 Generated with Claude Code

https://claude.ai/code/session_015M7QWFzt9NnWmSmNQXj1mM


Generated by Claude Code

Nine items from a greenfield-JS field report; three owner-confirmed HIGH. No version bump: 1.15.1
is not tagged yet, so this folds into it (see the CI change below, which makes that legitimate
rather than a bypass).

- #8 (owner-confirmed, most consequential): step 4's carve-out keyed on FIRSTNESS, so "a first prod
  release" matched every greenfield PR #1 and an agent correctly following the standard held a
  green PR the owner expected merged — inverting the contract's headline promise on the most common
  merge in a fresh repo. The test is now REVERSIBILITY: hold only when a revert cannot undo the
  merge (auth/provider cutover, data migration, registry publish, coupled deploy, anything that
  emails/charges/notifies), with the explicit counter-example that a first static-site deploy is
  NOT that. The old phrase is gone from the block so it can't be pattern-matched again.
- #9: the post-merge "1 unpushed commit" false positive is deterministic for anyone following the
  branch-pinned restart (the local branch is one merge commit ahead of origin/<pinned> by
  construction). The block now says to confirm with `git rev-list HEAD --not --remotes --count` and
  NOT to push to clear it — pushing puts the merge commit on the branch whose deletion is step 5's
  confirmation signal — and points at --heal-stop-hook, whose corrected hook already handles it.
- #1: the scripts.test heads-up was a false positive for `node --test`, the very script this tool
  writes (it does discover tests/*.test.mjs). It now inspects the command, reassures for
  node --test/vitest/jest, and warns only when the script plausibly misses it — naming the
  `node --test tests/` trap (MODULE_NOT_FOUND) instead of leaving the reader to find it.
- #2: scaffolded CI filtered `push` to main — it ran twice on every PR commit. This repo's own
  workflow has done this since 1.10.0; the template never caught up.
- #3: scaffolded CI pins Node for a JS repo via actions/setup-node (engines.node when declared,
  else 22), since `node --test` semantics moved across 18/20/22.
- #5: a Pages/deploy situational note — scaffold the workflow, hand the Settings-only source flip
  back like the default-branch flip. The full --pages scaffold stays on the roadmap.
- #6: the feedback path now leads with the web/MCP form (repo-bootstrap exists FOR web sessions,
  where `gh` is absent) and carries a field skeleton, since a freeform body can't populate the
  structured form's dropdowns. `gh` remains the local-CLI shortcut.
- #7a/#7b: SKILL.md no longer claims the stop-hook is "installed and auto-refreshed each session"
  (untrue since 1.15.0 made it consent-gated — which is exactly how #9 reached a user), and
  --heal-stop-hook is now in --help, which the generated block already pointed at.
- #7 withdrawn by the reporter (correct premise: the consent gate is deliberate).

CI: version-bump-guard now distinguishes released from unreleased versions. Releases here are
hand-cut tags, often days after merge, so a version with no v<ver> tag is still mutable and work
can be folded into it; once tagged it is immutable and a change must bump. That preserves the
guard's real purpose — a RELEASED version must never change underneath an installed copy.

Two self-inflicted bugs caught while testing and fixed before commit: the setup-node filler used
open(p,"w") inline, which truncates before the read runs and produced an empty workflow; and $(...)
stripped the step's trailing newline, welding it onto the next step. Both now verified by parsing
the generated YAML in the suite.

Tests: +3 cases (CI push-filter + conditional Node pin with YAML parsed, scripts.test
discrimination, and block assertions for the reframed carve-out / post-merge note / feedback
order). Block text changed, so standard-version.txt -> 1.15.1 and this repo's own block was
regenerated. Suite: 315 green.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015M7QWFzt9NnWmSmNQXj1mM
@cportka
cportka merged commit 141861d into main Aug 7, 2026
2 checks passed
@cportka
cportka deleted the claude/code-repo-setup-practices-var7xm branch August 7, 2026 19:50
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.

[feedback] repo-bootstrap: greenfield JS repo — false-positive test-script warning, duplicate CI runs, no Pages story

1 participant