Prepare v0.5.0-alpha.1 release - #43
Conversation
|
Warning Review limit reached
More reviews will be available in 51 minutes and 49 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?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 credits. 🚦 How do rate 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 see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughAdds automated release-tag creation after successful main CI, extends release publication to accept manual tags and close milestones, and updates the v0.5.0-alpha.1 release notes, policy/docs/tests, and crate version. ChangesRelease automation and v0.5 rollout
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/topics/release-process/runbook.md (1)
103-110: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winAnchor the fallback tag to refreshed
main, not implicitHEAD.Line 103 removes the old “refresh local
mainfirst” guard, but the fallback still usesgit tag -a ...with no target. If an operator runs this from a stale checkout or the oldrelease/...-prepbranch, the tag can land on the wrong commit, andrelease.ymlwould still accept any older commit that is merely reachable fromorigin/main.As per coding guidelines, “Documentation is a product interface, not a Markdown inventory.”
Suggested fix
Manual tagging is now an operator fallback, not the normal path. If automation does not run and the release-prep merge commit has been verified on `main`, the fallback is: ```bash +git switch main +git fetch origin +git merge --ff-only origin/main -git tag -a vX.Y.Z-alpha.N -m "vX.Y.Z-alpha.N" +git tag -a vX.Y.Z-alpha.N origin/main -m "vX.Y.Z-alpha.N" git push origin vX.Y.Z-alpha.N</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@docs/topics/release-process/runbook.mdaround lines 103 - 110, The fallback
tagging step in the release-process runbook can tag the wrong commit because
git tag -ais currently using the operator’s implicitHEAD. Update the
instructions around the manual fallback to first refresh localmainfrom
origin/main(for example via the existing release flow context), then make
git tag -aexplicitly point atorigin/mainso the tag is anchored to the
verified commit. Use the existing release-prep fallback section and thegit tag -a/git push originsteps as the place to adjust the guidance.</details> <!-- cr-comment:v1:df9838fa454661517646e90b --> _Source: Coding guidelines_ </blockquote></details> </blockquote></details>🤖 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 @.github/workflows/auto-release-tag.yml: - Around line 9-12: The workflow_run job is over-privileged because the single tag-release job currently holds actions: write and contents: write for every step. Split the logic in auto-release-tag into separate stages or jobs around the existing identify/tag/dispatch flow so the release-PR lookup runs with only pull-requests: read and contents: read, the git push step in the tag creation path gets only contents: write, and the gh workflow run dispatch step gets only actions: write; keep the permissions scoped to the specific job or stage names used in the current release tagging flow. In @.github/workflows/release.yml: - Around line 65-66: The milestone lookup in the release workflow is only querying the first page of GitHub results, so it can miss the target milestone in long-lived repositories. Update the gh api call in the release job to use pagination so the milestone search in the MILESTONE_JSON assignment traverses all pages before the jq filter runs, keeping the existing TAG-based lookup intact. In `@xtask/src/main.rs`: - Around line 904-929: The auto-release workflow guard test is missing coverage for the push-event predicate, so update auto_release_tag_workflow_is_guarded in xtask/src/main.rs to also assert the workflow contains github.event.workflow_run.event == 'push'. Keep the existing checks around workflow_run, CI, main, and success, but add the missing guard string so the test fails if the auto-tagger starts reacting to non-merge CI runs. - Around line 880-901: The current guard in release_workflow_supports_dispatch_and_milestone_closure only checks for milestone-related text, so it can miss ordering and wiring regressions. Harden this test by inspecting the release workflow structure around Publish GitHub release and Close release milestone, and assert that the close step runs only after the publish step and is driven by steps.release.outputs.* rather than just matching substrings. Use the existing release_workflow_supports_dispatch_and_milestone_closure test and the release.yml workflow contract as the target for the behavior check. --- Outside diff comments: In `@docs/topics/release-process/runbook.md`: - Around line 103-110: The fallback tagging step in the release-process runbook can tag the wrong commit because `git tag -a` is currently using the operator’s implicit `HEAD`. Update the instructions around the manual fallback to first refresh local `main` from `origin/main` (for example via the existing release flow context), then make `git tag -a` explicitly point at `origin/main` so the tag is anchored to the verified commit. Use the existing release-prep fallback section and the `git tag -a` / `git push origin` steps as the place to adjust the guidance.🪄 Autofix (Beta)
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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID:
9e7a759d-bc04-4541-bea9-7fa80f31de67⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock📒 Files selected for processing (13)
.github/workflows/auto-release-tag.yml.github/workflows/release.ymlCHANGELOG.mdREADME.mdROADMAP.mdcrates/edict-syntax/Cargo.tomldocs/README.mddocs/releases/v0.5.0-alpha.1.mddocs/topics/release-process/README.mddocs/topics/release-process/policy.tomldocs/topics/release-process/runbook.mddocs/topics/release-process/test-plan.mdxtask/src/main.rs📜 Review details
🧰 Additional context used
📓 Path-based instructions (3)
**
⚙️ CodeRabbit configuration file
**: # AGENTSGit Rules
NEVER amend git commits. Make a new commit instead.
NEVER use
git rebaseunless the user explicitly approves a rare exception.
Use regular merge commits.NEVER force any git operation. If a force operation appears necessary, stop and
explain what happened and what options remain.NEVER create draft pull requests.
NEVER use a
codexprefix in branch names, PR titles, or commit messages.Pull request bodies for issue work MUST include GitHub auto-close text such as
Closes#123`` for every issue the PR is intended to close.Think
Think is durable memory for cross-session coordination.
- Use
codex-think --remember --jsonwhen starting a new session, changing into
this repository, or regaining context after a context shift.- Use
codex-think "..." --jsonwhen a cycle closes or a significant event
should survive across turns.- Treat Think as memory, not repo truth. Anchor strong claims back to files,
commits, commands, issues, or pull requests.- Claude memories are read-only. Use
claude-think --remember --jsononly for
additional context.Topic Shelves
docs/topics/contains the living contract graph for landed behavior. Topic
shelves are not proposals, retrospectives, or design archaeology.Each shelf may contain:
README.md: what is true in HEAD.test-plan.md: how those truths are verified, including requirements, cases,
fixtures, oracles, implemented evidence, planned cases, and known gaps.architecture.md: optional structure or dataflow notes when the machinery
earns a separate page.rationale.md: optional still-relevant tradeoffs and rejected approaches.When To Update Topic Shelves
For every nontrivial behavior, contract, workflow, release, schema, validation,
or public-surface change:
- Identify the owning topic shelf before editing code.
- If no shelf owns durable behavior, create one.
- Update
test-plan.mdbefore or alongside tests with requirement IDs, case
IDs,...Files:
crates/edict-syntax/Cargo.tomlCHANGELOG.mddocs/releases/v0.5.0-alpha.1.mdROADMAP.mddocs/topics/release-process/README.mdREADME.mddocs/README.mddocs/topics/release-process/policy.tomldocs/topics/release-process/runbook.mdxtask/src/main.rsdocs/topics/release-process/test-plan.mddocs/topics/**/README.md
📄 CodeRabbit inference engine (AGENTS.md)
docs/topics/**/README.md: Topic shelfREADME.mdfiles must describe only what is true in HEAD.
Update the topic shelfREADME.mdonly after the behavior exists in the branch; do not describe intended future behavior there.
Do not churn topic-shelf README files for purely mechanical edits that do not change a contract.Files:
docs/topics/release-process/README.mddocs/topics/**/test-plan.md
📄 CodeRabbit inference engine (AGENTS.md)
docs/topics/**/test-plan.md: Update a topic shelftest-plan.mdbefore or alongside tests with requirement IDs, case IDs, fixtures, oracles, implemented evidence, planned cases, and known gaps.
Mark planned cases as implemented only when executable evidence exists.
Do not usepolicyrows in topic-shelf test plans to avoid writing behavior tests for software behavior.
Negative tests in topic-shelf test plans should assert stable error kinds or structured artifacts, not merelyis_err()or diagnostic text.
For nontrivial behavior, contract, workflow, release, schema, validation, or public-surface changes, update the owning topictest-plan.mdwith planned requirement and case rows before or alongside the first test.
Mark planned rows as implemented only after executable evidence exists.Files:
docs/topics/release-process/test-plan.md🪛 LanguageTool
docs/topics/release-process/README.md
[uncategorized] ~11-~11: The official name of this software platform is spelled with a capital “H”.
Context: ...Edict publishes GitHub releases through.github/workflows/release.yml. A release can b...(GITHUB)
[uncategorized] ~16-~16: The official name of this software platform is spelled with a capital “H”.
Context: ...p PR merge. WhenCIpasses onmain,.github/workflows/auto-release-tag.ymlchecks ...(GITHUB)
docs/topics/release-process/runbook.md
[uncategorized] ~90-~90: The official name of this software platform is spelled with a capital “H”.
Context: ...w runs onmain. If that run succeeds,.github/workflows/auto-release-tag.ymlchecks ...(GITHUB)
docs/topics/release-process/test-plan.md
[uncategorized] ~42-~42: The official name of this software platform is spelled with a capital “H”.
Context: ... and dispatches release publication. | .github/workflows/auto-release-tag.yml, docs/to...(GITHUB)
[uncategorized] ~43-~43: The official name of this software platform is spelled with a capital “H”.
Context: ... the milestone has zero open issues. | .github/workflows/release.yml, docs/topics/rele...(GITHUB)
[uncategorized] ~55-~55: The official name of this software platform is spelled with a capital “H”.
Context: ... full tag name after auto-tagging. | | .github/workflows/auto-release-tag.yml | Succes...(GITHUB)
[uncategorized] ~71-~71: The official name of this software platform is spelled with a capital “H”.
Context: ...ports_dispatch_and_milestone_closure | .github/workflows/auto-release-tag.yml, .github...(GITHUB)
[uncategorized] ~71-~71: The official name of this software platform is spelled with a capital “H”.
Context: ...github/workflows/auto-release-tag.yml, .github/workflows/release.yml, docs/topics/rele...(GITHUB)
🪛 zizmor (1.26.1)
.github/workflows/release.yml
[error] 15-15: overly broad permissions (excessive-permissions): contents: write is overly broad at the workflow level
(excessive-permissions)
[error] 16-16: overly broad permissions (excessive-permissions): issues: write is overly broad at the workflow level
(excessive-permissions)
[warning] 15-15: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
[info] 131-131: code injection via template expansion (template-injection): may expand into attacker-controllable code
(template-injection)
[info] 132-132: code injection via template expansion (template-injection): may expand into attacker-controllable code
(template-injection)
.github/workflows/auto-release-tag.yml
[warning] 24-27: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 10-10: overly broad permissions (excessive-permissions): actions: write is overly broad at the workflow level
(excessive-permissions)
[error] 11-11: overly broad permissions (excessive-permissions): contents: write is overly broad at the workflow level
(excessive-permissions)
[error] 3-7: use of fundamentally insecure workflow trigger (dangerous-triggers): workflow_run is almost always used insecurely
(dangerous-triggers)
[warning] 10-10: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
🔇 Additional comments (8)
docs/releases/v0.5.0-alpha.1.md (1)
1-96: LGTM!crates/edict-syntax/Cargo.toml (1)
3-3: LGTM!CHANGELOG.md (1)
11-12: LGTM!README.md (1)
462-465: LGTM!Also applies to: 494-495, 514-524
ROADMAP.md (1)
180-181: LGTM!Also applies to: 195-195, 247-247
docs/README.md (1)
16-19: LGTM!.github/workflows/auto-release-tag.yml (1)
29-83: LGTM!Also applies to: 84-113, 115-124
.github/workflows/release.yml (1)
7-53: LGTM!Also applies to: 73-87, 95-123, 124-142
![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: 87f3940737
ℹ️ 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".
Activity Summary@codex second opinion requested on the resolved review queue.
Validation:
All previously unresolved review threads were resolved via GraphQL after the fixes were pushed. |
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
docs/topics/release-process/runbook.md (1)
134-139: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winUse the real milestone query contract here.
This command is wrong for the post-release state it asks operators to verify. Without
state=all, it will usually return nothing once the workflow has closed the milestone, and without pagination it can miss older milestones entirely. Match the workflow’s query instead.Suggested fix
-gh api repos/flyingrobots/edict/milestones --jq \ - '.[] | select(.title == "vX.Y.Z-alpha.N") | {title,state,open_issues}' +gh api --paginate "repos/flyingrobots/edict/milestones?state=all&per_page=100" --jq \ + '.[] | select(.title == "vX.Y.Z-alpha.N") | {title,state,open_issues}'As per coding guidelines, documentation is a product interface, not a Markdown inventory.
🤖 Prompt for 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. In `@docs/topics/release-process/runbook.md` around lines 134 - 139, The milestone verification command uses the wrong API contract for the post-release state; update the runbook’s gh api query to match the workflow’s real milestone lookup by requesting all states and handling pagination, then filter for the target milestone title and closed/zero-open-issues result. Locate the command under the release-process runbook near the milestone check, and make sure the documented query aligns with the same contract used by the release workflow so operators can still find closed milestones after release.Source: Coding guidelines
.github/workflows/release.yml (1)
37-47: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winCheck out the selected tag before reading release artifacts.
For
workflow_dispatch,RELEASE_TAGcomes frominputs.tag, but the workspace remains the manually selected dispatch ref. That can publishdocs/releases/${TAG}.mdfrommainor another branch instead of the immutable tag being released.Proposed fix
TAG="${RELEASE_TAG}" VERSION="${TAG#v}" - NOTES="docs/releases/${TAG}.md" - TAG_COMMIT="$(git rev-parse "${TAG}^{commit}")" if [[ ! "${TAG}" =~ ^v[0-9]+\.[0-9]+\.[0-9]+(-[0-9A-Za-z.]+)?$ ]]; then echo "::error::Release tag must look like a SemVer v* tag: ${TAG}" exit 1 fi + + TAG_COMMIT="$(git rev-parse "${TAG}^{commit}")" @@ if ! git merge-base --is-ancestor "${TAG_COMMIT}" origin/main; then echo "::error::Release tags must target commits reachable from origin/main." echo "::error::Tag ${TAG} targets ${TAG_COMMIT}, which is not on origin/main." exit 1 fi + + git checkout --detach "${TAG_COMMIT}" + NOTES="docs/releases/${TAG}.md"🤖 Prompt for 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. In @.github/workflows/release.yml around lines 37 - 47, The release workflow reads release notes from the current workspace, but when RELEASE_TAG comes from inputs.tag in workflow_dispatch it may still be on the dispatch ref instead of the immutable tag. Update the release job so the checked-out revision matches TAG before using NOTES or TAG_COMMIT, and keep the logic centered around RELEASE_TAG, TAG, and TAG_COMMIT in the release shell step.
🤖 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 @.github/workflows/auto-release-tag.yml:
- Around line 99-102: The checkout in the auto-release tagging workflow is
persisting write credentials on disk, so update the existing actions/checkout
step to disable credential persistence with persist-credentials: false. Then
harden the Create immutable release tag step by removing any reliance on cached
git auth and using explicit per-command authentication for the git ls-remote,
fetch, and push operations, referring to the checkout and release-tagging logic
so the token is only used transiently in each command.
In `@xtask/src/main.rs`:
- Around line 925-933: The release workflow test is too broad because
release_workflow_paginates_milestone_lookup only checks for any gh api
--paginate usage instead of the milestone lookup specifically. Tighten the
assertion in xtask/src/main.rs so it matches the milestone lookup command in
release.yml, using the existing release_workflow_paginates_milestone_lookup test
and workflow content to verify the paginated call is tied to milestone retrieval
rather than any unrelated API call.
- Around line 973-990: The auto-release workflow permission test is too weak
because it only checks for strings anywhere in the YAML, so it can miss
permissions leaking to a broader scope. Update
auto_release_tag_workflow_scopes_job_permissions to parse and inspect the
workflow structure for the specific job entries identify-release-pr,
create-release-tag, and dispatch-release-publication, and assert their job-local
permissions exactly match the expected scoped values rather than just containing
the text. Use the existing workflow-loading logic in xtask/src/main.rs to locate
the job definitions and verify the permissions map for each job.
---
Outside diff comments:
In @.github/workflows/release.yml:
- Around line 37-47: The release workflow reads release notes from the current
workspace, but when RELEASE_TAG comes from inputs.tag in workflow_dispatch it
may still be on the dispatch ref instead of the immutable tag. Update the
release job so the checked-out revision matches TAG before using NOTES or
TAG_COMMIT, and keep the logic centered around RELEASE_TAG, TAG, and TAG_COMMIT
in the release shell step.
In `@docs/topics/release-process/runbook.md`:
- Around line 134-139: The milestone verification command uses the wrong API
contract for the post-release state; update the runbook’s gh api query to match
the workflow’s real milestone lookup by requesting all states and handling
pagination, then filter for the target milestone title and
closed/zero-open-issues result. Locate the command under the release-process
runbook near the milestone check, and make sure the documented query aligns with
the same contract used by the release workflow so operators can still find
closed milestones after release.
🪄 Autofix (Beta)
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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 1c4faddc-db6d-4c68-a415-559708a4ad5e
📒 Files selected for processing (5)
.github/workflows/auto-release-tag.yml.github/workflows/release.ymldocs/topics/release-process/policy.tomldocs/topics/release-process/runbook.mdxtask/src/main.rs
📜 Review details
🧰 Additional context used
📓 Path-based instructions (1)
**
⚙️ CodeRabbit configuration file
**: # AGENTSGit Rules
NEVER amend git commits. Make a new commit instead.
NEVER use
git rebaseunless the user explicitly approves a rare exception.
Use regular merge commits.NEVER force any git operation. If a force operation appears necessary, stop and
explain what happened and what options remain.NEVER create draft pull requests.
NEVER use a
codexprefix in branch names, PR titles, or commit messages.Pull request bodies for issue work MUST include GitHub auto-close text such as
Closes#123`` for every issue the PR is intended to close.Think
Think is durable memory for cross-session coordination.
- Use
codex-think --remember --jsonwhen starting a new session, changing into
this repository, or regaining context after a context shift.- Use
codex-think "..." --jsonwhen a cycle closes or a significant event
should survive across turns.- Treat Think as memory, not repo truth. Anchor strong claims back to files,
commits, commands, issues, or pull requests.- Claude memories are read-only. Use
claude-think --remember --jsononly for
additional context.Topic Shelves
docs/topics/contains the living contract graph for landed behavior. Topic
shelves are not proposals, retrospectives, or design archaeology.Each shelf may contain:
README.md: what is true in HEAD.test-plan.md: how those truths are verified, including requirements, cases,
fixtures, oracles, implemented evidence, planned cases, and known gaps.architecture.md: optional structure or dataflow notes when the machinery
earns a separate page.rationale.md: optional still-relevant tradeoffs and rejected approaches.When To Update Topic Shelves
For every nontrivial behavior, contract, workflow, release, schema, validation,
or public-surface change:
- Identify the owning topic shelf before editing code.
- If no shelf owns durable behavior, create one.
- Update
test-plan.mdbefore or alongside tests with requirement IDs, case
IDs,...
Files:
docs/topics/release-process/policy.tomldocs/topics/release-process/runbook.mdxtask/src/main.rs
🪛 zizmor (1.26.1)
.github/workflows/auto-release-tag.yml
[warning] 23-23: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
[warning] 99-102: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[warning] 96-96: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
[warning] 158-158: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
🔇 Additional comments (3)
.github/workflows/auto-release-tag.yml (2)
10-88: LGTM!
150-168: LGTM!.github/workflows/release.yml (1)
65-87: LGTM!Also applies to: 95-142
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7aafe0c052
ℹ️ 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".
Self-Discovered Issue@codex second opinion requested.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7aafe0c052
ℹ️ 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".
|
@codex Activity Summary for the latest Code Lawyer pass.
Validation run on the final head
All previously unresolved PR review threads were resolved via GraphQL after the fixes landed. |
Summary
Testing
|
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/topics/release-process/policy.toml (1)
47-54: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winMake
auto_release_tag_runconditional or define a fallback evidence artifact.The manual path in
docs/topics/release-process/runbook.mdLines 103-113 explicitly allows release publication when auto-tagging never ran, but this policy now requiresauto_release_tag_rununconditionally. That makes the documented fallback non-compliant with the machine-checkable contract.🤖 Prompt for 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. In `@docs/topics/release-process/policy.toml` around lines 47 - 54, The release policy currently requires auto_release_tag_run unconditionally, which conflicts with the documented manual release path in the release process runbook. Update the required_evidence list in policy.toml to make auto_release_tag_run conditional or add an explicit fallback evidence artifact for manual publication, and ensure the contract still references the existing release evidence symbols like release_issue, release_prep_pull_request, main_ci_run, tag_object, and github_release_url.
🤖 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 `@xtask/src/main.rs`:
- Around line 949-956: The release milestone lookup test only checks the policy
text, so it won’t catch workflow regressions that truncate the paginated
milestone stream. Update the existing test function
release_milestone_lookup_consumes_complete_paginated_stream to also inspect the
workflow definitions in .github/workflows/release.yml and
.github/workflows/auto-release-tag.yml, asserting the milestone lookup block
uses the full-stream jq -s '.[0] // empty' pattern and does not include head -n
1 or any equivalent truncation.
---
Outside diff comments:
In `@docs/topics/release-process/policy.toml`:
- Around line 47-54: The release policy currently requires auto_release_tag_run
unconditionally, which conflicts with the documented manual release path in the
release process runbook. Update the required_evidence list in policy.toml to
make auto_release_tag_run conditional or add an explicit fallback evidence
artifact for manual publication, and ensure the contract still references the
existing release evidence symbols like release_issue, release_prep_pull_request,
main_ci_run, tag_object, and github_release_url.
🪄 Autofix (Beta)
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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: d7341a97-9596-41e8-9b7b-c8ab8fd80e15
📒 Files selected for processing (5)
.github/workflows/auto-release-tag.yml.github/workflows/release.ymldocs/topics/release-process/policy.tomldocs/topics/release-process/runbook.mdxtask/src/main.rs
📜 Review details
🧰 Additional context used
📓 Path-based instructions (1)
**
⚙️ CodeRabbit configuration file
**: # AGENTSGit Rules
NEVER amend git commits. Make a new commit instead.
NEVER use
git rebaseunless the user explicitly approves a rare exception.
Use regular merge commits.NEVER force any git operation. If a force operation appears necessary, stop and
explain what happened and what options remain.NEVER create draft pull requests.
NEVER use a
codexprefix in branch names, PR titles, or commit messages.Pull request bodies for issue work MUST include GitHub auto-close text such as
Closes#123`` for every issue the PR is intended to close.Think
Think is durable memory for cross-session coordination.
- Use
codex-think --remember --jsonwhen starting a new session, changing into
this repository, or regaining context after a context shift.- Use
codex-think "..." --jsonwhen a cycle closes or a significant event
should survive across turns.- Treat Think as memory, not repo truth. Anchor strong claims back to files,
commits, commands, issues, or pull requests.- Claude memories are read-only. Use
claude-think --remember --jsononly for
additional context.Topic Shelves
docs/topics/contains the living contract graph for landed behavior. Topic
shelves are not proposals, retrospectives, or design archaeology.Each shelf may contain:
README.md: what is true in HEAD.test-plan.md: how those truths are verified, including requirements, cases,
fixtures, oracles, implemented evidence, planned cases, and known gaps.architecture.md: optional structure or dataflow notes when the machinery
earns a separate page.rationale.md: optional still-relevant tradeoffs and rejected approaches.When To Update Topic Shelves
For every nontrivial behavior, contract, workflow, release, schema, validation,
or public-surface change:
- Identify the owning topic shelf before editing code.
- If no shelf owns durable behavior, create one.
- Update
test-plan.mdbefore or alongside tests with requirement IDs, case
IDs,...
Files:
docs/topics/release-process/policy.tomldocs/topics/release-process/runbook.mdxtask/src/main.rs
🔇 Additional comments (3)
.github/workflows/auto-release-tag.yml (2)
103-149: Finish the explicit git-auth hardening.This still leaves the earlier hardening incomplete: after
persist-credentials: false,git ls-remoteandgit fetchrely on unauthenticatedorigin, whilepushembeds the token in the remote URL. Use per-command auth for all three git network calls.
119-120: LGTM!Also applies to: 165-171
.github/workflows/release.yml (1)
32-32: LGTM!Also applies to: 66-68, 126-144
|
@codex Activity Summary for the duplicate-thread Code Lawyer pass.
No new code commits were required in this pass because each unresolved thread was a duplicate of already-landed behavior on head Validation run in this pass:
All unresolved duplicate threads were resolved via GraphQL after verification. |
|
@codex Activity Summary for the latest CodeRabbit follow-up.
RED evidence:
GREEN/VERIFY evidence:
Resolved review thread: |
Summary
Testing
|
Summary
Testing
|
1 participant
Summary
Prepare
v0.5.0-alpha.1for release and automate the post-merge release path.What changed
crates/edict-syntaxandCargo.lockto0.5.0-alpha.1.CHANGELOG.mdentries into the datedv0.5.0-alpha.1section.docs/releases/v0.5.0-alpha.1.mdfor the Gate C admission-boundary alpha..github/workflows/auto-release-tag.ymlto create immutable release tags after successfulmainCI on mergedrelease/*-prepPRs.workflow_dispatch, verify zero-open matching milestones, publish the GitHub prerelease, and close the matching milestone.Validation
actionlintgit diff --checkcargo test -p xtask release_cargo xtask verifyCloses #42