forked from farhoodlabs/paperclip
f784d8d90e
## Thinking Path > - Paperclip orchestrates AI agents for zero-human companies, and the release pipeline is part of keeping that control plane shippable. > - The relevant subsystem here is the release automation in `scripts/release.sh`, which publishes canary builds and then verifies npm registry state. > - The failing CI run showed a successful publish followed by an immediate registry-state verification failure while npm dist-tag metadata was still propagating. > - That made the canary job flaky even when the publish itself had succeeded, which is the wrong failure mode for release automation. > - This pull request adds bounded retries around the post-publish registry-state verification step instead of failing on the first stale read. > - The benefit is that canary releases tolerate transient npm propagation lag while still failing clearly if registry metadata never converges. ## What Changed - Wrapped the post-publish `verify-release-registry-state.mjs` call in a bounded retry loop inside `scripts/release.sh`. - Reused the existing publish verification retry defaults and added optional overrides via `NPM_REGISTRY_STATE_VERIFY_ATTEMPTS` and `NPM_REGISTRY_STATE_VERIFY_DELAY_SECONDS` for dist-tag-specific tuning. ## Verification - `bash -n scripts/release.sh` - CI will also exercise the release path via the existing `Canary Dry Run` workflow job in `.github/workflows/pr.yml`. ## Risks - Low risk. The main behavioral change is that a genuinely broken registry-state verification can now wait through the configured retry window before failing. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex local agent, GPT-5-based Codex runtime in Paperclip with tool use and shell execution. The exact backend model ID/context window is not surfaced in this local heartbeat environment. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [ ] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] I will address all Greptile and reviewer comments before requesting merge