Certify pm CLI 2026.9.21, move merge drivers onto the canonical pm-ops launcher, and fix release visibility - #117
Conversation
…cal pm-ops launcher - Pins @unbrained/pm-cli 2026.9.21, pm-ops 2026.9.18 and pm-changelog 2026.9.18 exactly (package.json and package-lock.json). - scripts/prepare-merge-driver.ts is now a thin launcher over pm-ops/merge-driver, replacing the untyped prepare-merge-driver.mjs; one canonical, tested installer instead of a private copy per repository. - CI installs the drivers before `pm health --strict-exit --require-merge-drivers`, so a clone without them fails the gate instead of hard-conflicting tracker files on the next merge. - Release workflow: 10-minute npm visibility window, GitHub Release decoupled from bun mirror lag with a visible gate step, and a best-effort backfill of missing Releases (companion pm-cli-website-3y5d). pm items: pm-context-2axh, pm-context-ims7. Companion epic pm-cli-website-5s6z. release:check exits 0.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Reviewer's GuideThe PR certifies the 2026.9.21 pm toolchain, centralizes merge-driver installation in pm-ops with stricter CI enforcement, and restructures release automation to tolerate npm/bun propagation differences while backfilling missing GitHub Releases and keeping failures visible. Sequence diagram for release publication and visibility handlingsequenceDiagram
participant Workflow
participant NPM
participant Git
participant Bun
participant GitHub
Workflow->>NPM: Publish package with provenance
loop 10-minute visibility window
Workflow->>NPM: Check version and dist.attestations with --prefer-online
end
NPM-->>Workflow: Attested version visible
Workflow->>Git: Push release tag
Workflow->>Bun: Verify bun add
Workflow->>GitHub: Create GitHub Release
alt Bun verification fails
Bun-->>Workflow: Install failure
Workflow->>Workflow: Fail job visibly
else Bun verification succeeds
Bun-->>Workflow: Install success
end
Flow diagram for backfilling missing GitHub Releasesflowchart TD
Tags[Fetch release tags] --> Existing{GitHub Release exists?}
Existing -->|Yes| Next[Continue to next tag]
Existing -->|No| Version[Convert tag to npm version]
Version --> Attested{npm version visible with attestations?}
Attested -->|No| Skip[Skip and warn]
Attested -->|Yes| Notes[Generate tag-scoped release notes]
Notes --> Create[Create GitHub Release]
Create --> Next
Notes -->|Failure| Warn[Warn and continue]
Create -->|Failure| Warn
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
The prepare launcher statically imports pm-ops, a devDependency, so the README's promise that production / --omit=dev installs cannot break was only true for registry installs (npm never runs prepare for a registry tarball). A production install of a clone omits pm-ops as well and must pass --ignore-scripts, which is what this fleet's own Dockerfiles do. Raised by Greptile and Sourcery on pm-starter#113. The canonical guarded launcher is tracked as companion item pm-cli-website-xy19.
CI ran an explicit pm merge install right before pm health --require-merge-drivers, so the gate only verified the step before it and would have passed with a broken prepare hook. Without that step, the health gate asserts what a fresh clone actually relies on: npm ci runs the prepare launcher, which installs the drivers through pm-ops/merge-driver. Verified on a fresh git clone: no merge.pm* keys before npm ci, all of them after, and pm health --strict-exit --require-merge-drivers exits 1 once they are removed. Raised by Greptile on pm-github#93.
The backfill created a GitHub Release for any fleet-shaped tag whose npm version carried some attestation, without proving the tag's commit produced that artifact, so a stale, moved or hand-made tag could get a misleading Release. Comparing the attested commit with the tag commit is not the fix either: this fleet's provenance names the workflow trigger commit, measured as the tag's direct parent on three real releases. The correct check (same repository and workflow, attested commit an ancestor of the tag) belongs in the canonical pm-ops release verifier. The 10-minute npm visibility window and the Release decoupled from bun mirror lag remain; they fix the root causes. Raised by Greptile on pm-brief#124 and pm-linear#121.
This comment has been minimized.
This comment has been minimized.
- release.yml: max_attempts is declared before refuse_unattested_or_fail, which expands it, so its visibility no longer depends on call-time reasoning (the fleet's bindings-before-use rule; Greptile on pm-todos#99). Behaviour is unchanged. - pm records: the release Issue no longer claims the backfill that review removed, and the certify Task describes CI as it now is (health gate right after npm ci, no separate install step). The final release.yml is byte-identical to a fresh run of the anchored applier on origin/main (identical).
The resolution, expected result and close reason still described the backfill step that review removed, and the close reason cited the earlier 7-scenario harness run. All three now state the two changes that ship, the 5 applicable harness scenarios, and that the backfill moved to companion item pm-cli-website-mxrp. Raised by Greptile on pm-slack#115.
Summary
Fleet wave of 2026-09-22 (companion epic
pm-cli-website-5s6z), applied by the fleet's deterministic wave script and verified by this repository's own gates.scripts/prepare-merge-driver.tsis a thin launcher overpm-ops/merge-driver(removed: scripts/prepare-merge-driver.mjs). CI runspm health --strict-exit --require-merge-driversright afternpm ci, with no separate install step, so the gate proves that the prepare hook installed the drivers. A broken launcher fails CI instead of silently leaving clones that hard-conflict.toon/history files on the next multi-agent merge.pm items
Review follow-ups
Findings tracked centrally rather than fixed per repository (one pm-ops release moves the whole fleet):
pm-cli-website-xy19: a guarded launcher so thatnpm ci --omit=devin a clone no-ops instead of failingpm-cli-website-mxrp: the release-workflow recovery harness as a checked-in pm-ops verifier run by everyrelease:check, plus the backfill with provenance-ancestry verification (the attested commit must be an ancestor of the tag; this fleet's provenance names the trigger commit,pm-cli-website-nodo)Verification
git config --get-regexp '^merge\.pm'afternpm cipm health --strict-exit --require-merge-driversnpm run release:checkok - the flag changes the heading: '## 2026.1.2-2 - 2026-01-02' with it, '## 202)changelog:fullthenchangelog:checkDependabot PRs are not absorbed here and will rebase onto this change.
Summary by Sourcery
Certify the updated pm toolchain, centralize merge-driver setup, and make release status accurately reflect npm, bun, and GitHub visibility outcomes.
Bug Fixes:
Enhancements:
CI:
Documentation:
Chores:
Summary by cubic
Certifies the pm CLI toolchain at 2026.9.21, replaces the vendored merge-driver install with a thin launcher over
pm-ops/merge-driver, and makes release creation resilient to npm propagation and bun mirror lag.Bug Fixes
--prefer-onlinereads and an end-of-window re-check) so a late-visible publish is treated as success instead of a false failure.pm-opsrelease verifier.Refactors
scripts/prepare-merge-driver.tsnow delegates to the canonicalpm-ops/merge-driverlauncher, replacing the vendoredscripts/prepare-merge-driver.mjs.pm merge install; thepm health --strict-exit --require-merge-driversgate now proves thatnpm ci'spreparehook installed the drivers, so a broken prepare hook or missing drivers fail the gate instead of silently hard-conflicting tracker files on the next merge.@unbrained/pm-cli2026.9.17 → 2026.9.21,pm-changelog2026.9.16 → 2026.9.18, andpm-ops2026.9.13 → 2026.9.18 inpackage.jsonandpackage-lock.json.pm-ops, so a production install of a clone must pass--ignore-scripts; registry installs never runprepare.Written for commit c585c42. Summary will update on new commits.