Pin kaizen-loop v0.1.3 and close the release-check gap that let v0.1.2 ship - #204
Conversation
…2 ship v0.1.2 could not perform any GitHub operation. The guard added in #344 threw unconditionally because nothing ever attached the trusted executables to the command runner, and the trusted-path rule rejected any executable under a group-writable ancestor — which excludes /nix/store by design and Homebrew prefixes by default. On macOS both usual ways to install gh failed the check and gh does not ship in /usr/bin, so the error's own remediation could not be followed. v0.1.3 carries kaizen-loop#354, which wires the runner and accepts sticky root-owned directories. The checklist change matters as much as the bump. v0.1.2 passed tests, typecheck, check:dist and an install smoke, and still shipped a build that could not talk to GitHub, because `kaizen doctor` without --project returns before it calls GitHub. The checklist now requires naming a registered project and seeing gh auth pass, and records why. Verified against the published tag: install from this manifest checks out v0.1.3, and doctor --project reports gh auth PASS from that build. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 47 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository: kaizen-agents-org/coderabbit/.coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThe release documentation now requires project-scoped ChangesRelease verification
Estimated code review effort: 1 (Trivial) | ~3 minutes Possibly related issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9512eb98aa
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/release-tags.md`:
- Around line 48-55: Align the documentation and supported onboarding
verification by updating the relevant guidance around `kaizen doctor --repair`
and `kaizen doctor --project <slug>`. Ensure the documented release check uses a
registered project slug, or revise the release-verification wording to
accurately describe the onboarding command; keep the chosen command and its
documentation consistent.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: kaizen-agents-org/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 75a92091-104f-415f-8315-05740df410a2
📒 Files selected for processing (2)
docs/release-tags.mdonboarding/versions.json
|
@coderabbitai review |
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3c0d7f2fc4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@coderabbitai review |
|
|
Codex Review: Didn't find any major issues. Swish! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
PR Guardian update
No merge was performed. GitHub mergeability is clear; strict guardian state is |
1 participant
Why
v0.1.2could not perform any GitHub operation —doctor,smoke,run, all of them failed with:Two defects, both fixed by kaizen-agents-org/kaizen-loop#354:
withTrustedExecutables, and nothing ever called it, so the throw was unconditional.ghcould not be resolved as trusted on a normal macOS install. The rule required every ancestor up to/to be root-owned with no group-write bit./nix/storeisdrwxrwxr-tby design, and Homebrew prefixes are user-owned. Both common install paths failed, andghdoes not ship in/usr/bin, so the error's own remediation had no answer. Sticky root-owned directories are now accepted, which keeps the intent — other users still cannot replace another's files — while being satisfiable.The checklist change is the more important half
v0.1.2passed tests (634), typecheck, check:dist, mode 755, and a packed-tarball install that rankaizen --version. I tagged it on that evidence. It still shipped a build that could not reach GitHub.The reason is narrow and worth recording:
kaizen doctorwithout--projectreturns before it calls GitHub, so it passes even when every GitHub call is broken. Nothing else in the checklist runsgheither.docs/release-tags.mdnow requireskaizen doctor --project <slug>against a registered project withgh authpassing, and says why in one paragraph so the next releaser does not quietly drop the flag.Verification
Against the published tag, following the amended checklist:
Release commit verified from a clean checkout before tagging: 640 tests pass, typecheck clean,
check:distcurrent,dist/cli.jsmode 755, and a global install from the packed tarball reaches GitHub.Suites: onboard, install-kaizen, uninstall-kaizen, toolchain-update, and the doc-link check all pass.
Note
builder-agentandverifierstay atv0.1.0; neither changed. Both have unreleased commits onmain, deliberately left out — #120 is verifying whether the harness handles Rust, and moving two variables at once would make a Rust-specific failure indistinguishable from an update-induced one.Refs #120
🤖 Generated with Claude Code
Summary by CodeRabbit
Documentation
kaizen doctor.kaizen-loopv0.1.2 to v0.1.3.Chores
kaizen-loopv0.1.3.