fix(ci): publish from release branch instead of base branch

[aidandaly24]

Description

The publish jobs were checking out main/preview which could serve a stale git ref that didn't include the version bump commit. This caused 0.12.1 to be published with the 0.12.0 package.json.

Now the publish jobs checkout release/v<version> directly, which is guaranteed to have the correct version. Added a version verification step before npm publish as a safety check.

Prior art — how other OSS repos handle this

Repo	Pattern	Publishes from main?
Turborepo	Creates a staging branch, publishes from it	No — staging branch
Nx	Dynamic ref resolution, dedicated publish branch	No — PR branch or publish branch
Next.js	Clones canary branch explicitly	No — canary branch
Vite	Tag-triggered, checks out tag ref	No — tag ref
Vue.js	Tag-triggered, checks out tag ref	No — tag ref

None of these projects publish from the base branch HEAD — they all publish from a release branch, staging branch, or tag ref.

Related Issue

Closes #

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	43%	7778 / 18086
🔵	Statements	42.4%	8230 / 19407
🔵	Functions	40.33%	1340 / 3322
🔵	Branches	40.66%	5103 / 12548

Generated in workflow #2159 for commit a0eb504 by the Vitest Coverage Report Action

[agentcore-cli-automation]

Publish will fail if the release branch is deleted after merge

Looking at recent merged release PRs, the release/v<version> branches are deleted after merge — only release/v0.9.2 remains out of all past releases. So this is either auto-delete-on-merge being enabled, or reviewers manually deleting the branch when clicking Merge (both are very common defaults).

The new publish flow depends on the release branch still existing at publish time:

- name: Checkout release branchuses: actions/checkout@v6with:
ref: release/v${{ needs.prepare-main.outputs.version }}

But publish-main runs after verify-merges, which only passes once the release PR has been merged into main. If the branch gets deleted as part of (or right after) that merge, actions/checkout won't be able to resolve the ref and the publish step will fail — right after the approval gate, with a released-but-unpublished state that's annoying to recover from.

Since verify-merges already confirms the bump commit is on origin/main, a few ways to fix this:

Option 1 — Pin to a SHA captured at prepare time. Have prepare-main/prepare-preview output the SHA of the bump commit they pushed, then check that out in the publish jobs. This is the most robust — the SHA stays reachable from main (merge-commit strategy is in use, so the release-branch tip is preserved) even after the branch is deleted.

# in prepare-main, after git push origin $BRANCH_NAMEecho "sha=$(git rev-parse HEAD)" >> $GITHUB_OUTPUT

# in publish-mainwith:
ref: ${{ needs.prepare-main.outputs.sha }}

Option 2 — Go back to checking out main/preview but force a fresh fetch. Since verify-merges has already proven origin/main contains the bump commit, checking out main should be safe. The original stale-ref problem can be avoided by setting fetch-depth: 0 and explicitly git fetch origin main && git reset --hard origin/main in a follow-up step, or by using the merge commit SHA of the release PR.

Option 3 — Keep this PR's approach but prevent branch deletion. Disable auto-delete-on-merge for the repo, and/or add a note/comment on the release PR asking reviewers not to delete the branch. This is the most fragile option since it relies on human discipline.

I'd recommend Option 1 — it's the smallest change and doesn't depend on branch retention or repo settings.

---

A related but smaller concern: the tag creation step also runs against the release-branch checkout, so the tag ends up on the bump commit (e.g. c097232) rather than on the merge commit on main. Since merge-commit strategy is in use, that commit is reachable from main, so this is fine in practice — just worth being aware of if you ever switch to squash merges.

[aidandaly24]

Closing: fresh run with CI fix improvements

[aidandaly24]

Description

The publish jobs were checking out main/preview which could serve a stale git ref that didn't include the version bump commit. This caused 0.12.1 to be published with the 0.12.0 package.json.

Now the publish jobs checkout release/v<version> directly, which is guaranteed to have the correct version. Added a version verification step before npm publish as a safety check.

Prior art — how other OSS repos handle this

Repo	Pattern	Publishes from main?
Turborepo	Creates a staging branch, publishes from it	No — staging branch
Nx	Dynamic ref resolution, dedicated publish branch	No — PR branch or publish branch
Next.js	Clones canary branch explicitly	No — canary branch
Vite	Tag-triggered, checks out tag ref	No — tag ref
Vue.js	Tag-triggered, checks out tag ref	No — tag ref

None of these projects publish from the base branch HEAD — they all publish from a release branch, staging branch, or tag ref.

Related Issue

Closes #

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	43%	7778 / 18086
🔵	Statements	42.4%	8230 / 19407
🔵	Functions	40.33%	1340 / 3322
🔵	Branches	40.66%	5103 / 12548

Generated in workflow #2159 for commit a0eb504 by the Vitest Coverage Report Action

[agentcore-cli-automation]

Publish will fail if the release branch is deleted after merge

Looking at recent merged release PRs, the release/v<version> branches are deleted after merge — only release/v0.9.2 remains out of all past releases. So this is either auto-delete-on-merge being enabled, or reviewers manually deleting the branch when clicking Merge (both are very common defaults).

The new publish flow depends on the release branch still existing at publish time:

- name: Checkout release branchuses: actions/checkout@v6with:
ref: release/v${{ needs.prepare-main.outputs.version }}

But publish-main runs after verify-merges, which only passes once the release PR has been merged into main. If the branch gets deleted as part of (or right after) that merge, actions/checkout won't be able to resolve the ref and the publish step will fail — right after the approval gate, with a released-but-unpublished state that's annoying to recover from.

Since verify-merges already confirms the bump commit is on origin/main, a few ways to fix this:

Option 1 — Pin to a SHA captured at prepare time. Have prepare-main/prepare-preview output the SHA of the bump commit they pushed, then check that out in the publish jobs. This is the most robust — the SHA stays reachable from main (merge-commit strategy is in use, so the release-branch tip is preserved) even after the branch is deleted.

# in prepare-main, after git push origin $BRANCH_NAMEecho "sha=$(git rev-parse HEAD)" >> $GITHUB_OUTPUT

# in publish-mainwith:
ref: ${{ needs.prepare-main.outputs.sha }}

Option 2 — Go back to checking out main/preview but force a fresh fetch. Since verify-merges has already proven origin/main contains the bump commit, checking out main should be safe. The original stale-ref problem can be avoided by setting fetch-depth: 0 and explicitly git fetch origin main && git reset --hard origin/main in a follow-up step, or by using the merge commit SHA of the release PR.

Option 3 — Keep this PR's approach but prevent branch deletion. Disable auto-delete-on-merge for the repo, and/or add a note/comment on the release PR asking reviewers not to delete the branch. This is the most fragile option since it relies on human discipline.

I'd recommend Option 1 — it's the smallest change and doesn't depend on branch retention or repo settings.

---

A related but smaller concern: the tag creation step also runs against the release-branch checkout, so the tag ends up on the bump commit (e.g. c097232) rather than on the merge commit on main. Since merge-commit strategy is in use, that commit is reachable from main, so this is fine in practice — just worth being aware of if you ever switch to squash merges.

[aidandaly24]

Closing: fresh run with CI fix improvements

[aidandaly24]

Description

The publish jobs were checking out main/preview which could serve a stale git ref that didn't include the version bump commit. This caused 0.12.1 to be published with the 0.12.0 package.json.

Now the publish jobs checkout release/v<version> directly, which is guaranteed to have the correct version. Added a version verification step before npm publish as a safety check.

Prior art — how other OSS repos handle this

Repo	Pattern	Publishes from main?
Turborepo	Creates a staging branch, publishes from it	No — staging branch
Nx	Dynamic ref resolution, dedicated publish branch	No — PR branch or publish branch
Next.js	Clones canary branch explicitly	No — canary branch
Vite	Tag-triggered, checks out tag ref	No — tag ref
Vue.js	Tag-triggered, checks out tag ref	No — tag ref

None of these projects publish from the base branch HEAD — they all publish from a release branch, staging branch, or tag ref.

Related Issue

Closes #

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	43%	7778 / 18086
🔵	Statements	42.4%	8230 / 19407
🔵	Functions	40.33%	1340 / 3322
🔵	Branches	40.66%	5103 / 12548

Generated in workflow #2159 for commit a0eb504 by the Vitest Coverage Report Action

[agentcore-cli-automation]

Publish will fail if the release branch is deleted after merge

Looking at recent merged release PRs, the release/v<version> branches are deleted after merge — only release/v0.9.2 remains out of all past releases. So this is either auto-delete-on-merge being enabled, or reviewers manually deleting the branch when clicking Merge (both are very common defaults).

The new publish flow depends on the release branch still existing at publish time:

- name: Checkout release branchuses: actions/checkout@v6with:
ref: release/v${{ needs.prepare-main.outputs.version }}

But publish-main runs after verify-merges, which only passes once the release PR has been merged into main. If the branch gets deleted as part of (or right after) that merge, actions/checkout won't be able to resolve the ref and the publish step will fail — right after the approval gate, with a released-but-unpublished state that's annoying to recover from.

Since verify-merges already confirms the bump commit is on origin/main, a few ways to fix this:

Option 1 — Pin to a SHA captured at prepare time. Have prepare-main/prepare-preview output the SHA of the bump commit they pushed, then check that out in the publish jobs. This is the most robust — the SHA stays reachable from main (merge-commit strategy is in use, so the release-branch tip is preserved) even after the branch is deleted.

# in prepare-main, after git push origin $BRANCH_NAMEecho "sha=$(git rev-parse HEAD)" >> $GITHUB_OUTPUT

# in publish-mainwith:
ref: ${{ needs.prepare-main.outputs.sha }}

Option 2 — Go back to checking out main/preview but force a fresh fetch. Since verify-merges has already proven origin/main contains the bump commit, checking out main should be safe. The original stale-ref problem can be avoided by setting fetch-depth: 0 and explicitly git fetch origin main && git reset --hard origin/main in a follow-up step, or by using the merge commit SHA of the release PR.

Option 3 — Keep this PR's approach but prevent branch deletion. Disable auto-delete-on-merge for the repo, and/or add a note/comment on the release PR asking reviewers not to delete the branch. This is the most fragile option since it relies on human discipline.

I'd recommend Option 1 — it's the smallest change and doesn't depend on branch retention or repo settings.

---

A related but smaller concern: the tag creation step also runs against the release-branch checkout, so the tag ends up on the bump commit (e.g. c097232) rather than on the merge commit on main. Since merge-commit strategy is in use, that commit is reachable from main, so this is fine in practice — just worth being aware of if you ever switch to squash merges.

[aidandaly24]

Closing: fresh run with CI fix improvements

[aidandaly24]

Description

The publish jobs were checking out main/preview which could serve a stale git ref that didn't include the version bump commit. This caused 0.12.1 to be published with the 0.12.0 package.json.

Now the publish jobs checkout release/v<version> directly, which is guaranteed to have the correct version. Added a version verification step before npm publish as a safety check.

Prior art — how other OSS repos handle this

Repo	Pattern	Publishes from main?
Turborepo	Creates a staging branch, publishes from it	No — staging branch
Nx	Dynamic ref resolution, dedicated publish branch	No — PR branch or publish branch
Next.js	Clones canary branch explicitly	No — canary branch
Vite	Tag-triggered, checks out tag ref	No — tag ref
Vue.js	Tag-triggered, checks out tag ref	No — tag ref

None of these projects publish from the base branch HEAD — they all publish from a release branch, staging branch, or tag ref.

Related Issue

Closes #

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	43%	7778 / 18086
🔵	Statements	42.4%	8230 / 19407
🔵	Functions	40.33%	1340 / 3322
🔵	Branches	40.66%	5103 / 12548

Generated in workflow #2159 for commit a0eb504 by the Vitest Coverage Report Action

[agentcore-cli-automation]

Publish will fail if the release branch is deleted after merge

Looking at recent merged release PRs, the release/v<version> branches are deleted after merge — only release/v0.9.2 remains out of all past releases. So this is either auto-delete-on-merge being enabled, or reviewers manually deleting the branch when clicking Merge (both are very common defaults).

The new publish flow depends on the release branch still existing at publish time:

- name: Checkout release branchuses: actions/checkout@v6with:
ref: release/v${{ needs.prepare-main.outputs.version }}

But publish-main runs after verify-merges, which only passes once the release PR has been merged into main. If the branch gets deleted as part of (or right after) that merge, actions/checkout won't be able to resolve the ref and the publish step will fail — right after the approval gate, with a released-but-unpublished state that's annoying to recover from.

Since verify-merges already confirms the bump commit is on origin/main, a few ways to fix this:

Option 1 — Pin to a SHA captured at prepare time. Have prepare-main/prepare-preview output the SHA of the bump commit they pushed, then check that out in the publish jobs. This is the most robust — the SHA stays reachable from main (merge-commit strategy is in use, so the release-branch tip is preserved) even after the branch is deleted.

# in prepare-main, after git push origin $BRANCH_NAMEecho "sha=$(git rev-parse HEAD)" >> $GITHUB_OUTPUT

# in publish-mainwith:
ref: ${{ needs.prepare-main.outputs.sha }}

Option 2 — Go back to checking out main/preview but force a fresh fetch. Since verify-merges has already proven origin/main contains the bump commit, checking out main should be safe. The original stale-ref problem can be avoided by setting fetch-depth: 0 and explicitly git fetch origin main && git reset --hard origin/main in a follow-up step, or by using the merge commit SHA of the release PR.

Option 3 — Keep this PR's approach but prevent branch deletion. Disable auto-delete-on-merge for the repo, and/or add a note/comment on the release PR asking reviewers not to delete the branch. This is the most fragile option since it relies on human discipline.

I'd recommend Option 1 — it's the smallest change and doesn't depend on branch retention or repo settings.

---

A related but smaller concern: the tag creation step also runs against the release-branch checkout, so the tag ends up on the bump commit (e.g. c097232) rather than on the merge commit on main. Since merge-commit strategy is in use, that commit is reachable from main, so this is fine in practice — just worth being aware of if you ever switch to squash merges.

[aidandaly24]

Closing: fresh run with CI fix improvements

[aidandaly24]

Description

The publish jobs were checking out main/preview which could serve a stale git ref that didn't include the version bump commit. This caused 0.12.1 to be published with the 0.12.0 package.json.

Now the publish jobs checkout release/v<version> directly, which is guaranteed to have the correct version. Added a version verification step before npm publish as a safety check.

Prior art — how other OSS repos handle this

Repo	Pattern	Publishes from main?
Turborepo	Creates a staging branch, publishes from it	No — staging branch
Nx	Dynamic ref resolution, dedicated publish branch	No — PR branch or publish branch
Next.js	Clones canary branch explicitly	No — canary branch
Vite	Tag-triggered, checks out tag ref	No — tag ref
Vue.js	Tag-triggered, checks out tag ref	No — tag ref

None of these projects publish from the base branch HEAD — they all publish from a release branch, staging branch, or tag ref.

Related Issue

Closes #

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	43%	7778 / 18086
🔵	Statements	42.4%	8230 / 19407
🔵	Functions	40.33%	1340 / 3322
🔵	Branches	40.66%	5103 / 12548

Generated in workflow #2159 for commit a0eb504 by the Vitest Coverage Report Action

[agentcore-cli-automation]

Publish will fail if the release branch is deleted after merge

Looking at recent merged release PRs, the release/v<version> branches are deleted after merge — only release/v0.9.2 remains out of all past releases. So this is either auto-delete-on-merge being enabled, or reviewers manually deleting the branch when clicking Merge (both are very common defaults).

The new publish flow depends on the release branch still existing at publish time:

- name: Checkout release branchuses: actions/checkout@v6with:
ref: release/v${{ needs.prepare-main.outputs.version }}

But publish-main runs after verify-merges, which only passes once the release PR has been merged into main. If the branch gets deleted as part of (or right after) that merge, actions/checkout won't be able to resolve the ref and the publish step will fail — right after the approval gate, with a released-but-unpublished state that's annoying to recover from.

Since verify-merges already confirms the bump commit is on origin/main, a few ways to fix this:

Option 1 — Pin to a SHA captured at prepare time. Have prepare-main/prepare-preview output the SHA of the bump commit they pushed, then check that out in the publish jobs. This is the most robust — the SHA stays reachable from main (merge-commit strategy is in use, so the release-branch tip is preserved) even after the branch is deleted.

# in prepare-main, after git push origin $BRANCH_NAMEecho "sha=$(git rev-parse HEAD)" >> $GITHUB_OUTPUT

# in publish-mainwith:
ref: ${{ needs.prepare-main.outputs.sha }}

Option 2 — Go back to checking out main/preview but force a fresh fetch. Since verify-merges has already proven origin/main contains the bump commit, checking out main should be safe. The original stale-ref problem can be avoided by setting fetch-depth: 0 and explicitly git fetch origin main && git reset --hard origin/main in a follow-up step, or by using the merge commit SHA of the release PR.

Option 3 — Keep this PR's approach but prevent branch deletion. Disable auto-delete-on-merge for the repo, and/or add a note/comment on the release PR asking reviewers not to delete the branch. This is the most fragile option since it relies on human discipline.

I'd recommend Option 1 — it's the smallest change and doesn't depend on branch retention or repo settings.

---

A related but smaller concern: the tag creation step also runs against the release-branch checkout, so the tag ends up on the bump commit (e.g. c097232) rather than on the merge commit on main. Since merge-commit strategy is in use, that commit is reachable from main, so this is fine in practice — just worth being aware of if you ever switch to squash merges.

[aidandaly24]

Closing: fresh run with CI fix improvements

[aidandaly24]

Description

The publish jobs were checking out main/preview which could serve a stale git ref that didn't include the version bump commit. This caused 0.12.1 to be published with the 0.12.0 package.json.

Now the publish jobs checkout release/v<version> directly, which is guaranteed to have the correct version. Added a version verification step before npm publish as a safety check.

Prior art — how other OSS repos handle this

Repo	Pattern	Publishes from main?
Turborepo	Creates a staging branch, publishes from it	No — staging branch
Nx	Dynamic ref resolution, dedicated publish branch	No — PR branch or publish branch
Next.js	Clones canary branch explicitly	No — canary branch
Vite	Tag-triggered, checks out tag ref	No — tag ref
Vue.js	Tag-triggered, checks out tag ref	No — tag ref

None of these projects publish from the base branch HEAD — they all publish from a release branch, staging branch, or tag ref.

Related Issue

Closes #

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	43%	7778 / 18086
🔵	Statements	42.4%	8230 / 19407
🔵	Functions	40.33%	1340 / 3322
🔵	Branches	40.66%	5103 / 12548

Generated in workflow #2159 for commit a0eb504 by the Vitest Coverage Report Action

[agentcore-cli-automation]

Publish will fail if the release branch is deleted after merge

Looking at recent merged release PRs, the release/v<version> branches are deleted after merge — only release/v0.9.2 remains out of all past releases. So this is either auto-delete-on-merge being enabled, or reviewers manually deleting the branch when clicking Merge (both are very common defaults).

The new publish flow depends on the release branch still existing at publish time:

- name: Checkout release branchuses: actions/checkout@v6with:
ref: release/v${{ needs.prepare-main.outputs.version }}

But publish-main runs after verify-merges, which only passes once the release PR has been merged into main. If the branch gets deleted as part of (or right after) that merge, actions/checkout won't be able to resolve the ref and the publish step will fail — right after the approval gate, with a released-but-unpublished state that's annoying to recover from.

Since verify-merges already confirms the bump commit is on origin/main, a few ways to fix this:

Option 1 — Pin to a SHA captured at prepare time. Have prepare-main/prepare-preview output the SHA of the bump commit they pushed, then check that out in the publish jobs. This is the most robust — the SHA stays reachable from main (merge-commit strategy is in use, so the release-branch tip is preserved) even after the branch is deleted.

# in prepare-main, after git push origin $BRANCH_NAMEecho "sha=$(git rev-parse HEAD)" >> $GITHUB_OUTPUT

# in publish-mainwith:
ref: ${{ needs.prepare-main.outputs.sha }}

Option 2 — Go back to checking out main/preview but force a fresh fetch. Since verify-merges has already proven origin/main contains the bump commit, checking out main should be safe. The original stale-ref problem can be avoided by setting fetch-depth: 0 and explicitly git fetch origin main && git reset --hard origin/main in a follow-up step, or by using the merge commit SHA of the release PR.

Option 3 — Keep this PR's approach but prevent branch deletion. Disable auto-delete-on-merge for the repo, and/or add a note/comment on the release PR asking reviewers not to delete the branch. This is the most fragile option since it relies on human discipline.

I'd recommend Option 1 — it's the smallest change and doesn't depend on branch retention or repo settings.

---

A related but smaller concern: the tag creation step also runs against the release-branch checkout, so the tag ends up on the bump commit (e.g. c097232) rather than on the merge commit on main. Since merge-commit strategy is in use, that commit is reachable from main, so this is fine in practice — just worth being aware of if you ever switch to squash merges.

[aidandaly24]

Closing: fresh run with CI fix improvements

[aidandaly24]

Description

The publish jobs were checking out main/preview which could serve a stale git ref that didn't include the version bump commit. This caused 0.12.1 to be published with the 0.12.0 package.json.

Now the publish jobs checkout release/v<version> directly, which is guaranteed to have the correct version. Added a version verification step before npm publish as a safety check.

Prior art — how other OSS repos handle this

Repo	Pattern	Publishes from main?
Turborepo	Creates a staging branch, publishes from it	No — staging branch
Nx	Dynamic ref resolution, dedicated publish branch	No — PR branch or publish branch
Next.js	Clones canary branch explicitly	No — canary branch
Vite	Tag-triggered, checks out tag ref	No — tag ref
Vue.js	Tag-triggered, checks out tag ref	No — tag ref

None of these projects publish from the base branch HEAD — they all publish from a release branch, staging branch, or tag ref.

Related Issue

Closes #

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	43%	7778 / 18086
🔵	Statements	42.4%	8230 / 19407
🔵	Functions	40.33%	1340 / 3322
🔵	Branches	40.66%	5103 / 12548

Generated in workflow #2159 for commit a0eb504 by the Vitest Coverage Report Action

[agentcore-cli-automation]

Publish will fail if the release branch is deleted after merge

Looking at recent merged release PRs, the release/v<version> branches are deleted after merge — only release/v0.9.2 remains out of all past releases. So this is either auto-delete-on-merge being enabled, or reviewers manually deleting the branch when clicking Merge (both are very common defaults).

The new publish flow depends on the release branch still existing at publish time:

- name: Checkout release branchuses: actions/checkout@v6with:
ref: release/v${{ needs.prepare-main.outputs.version }}

But publish-main runs after verify-merges, which only passes once the release PR has been merged into main. If the branch gets deleted as part of (or right after) that merge, actions/checkout won't be able to resolve the ref and the publish step will fail — right after the approval gate, with a released-but-unpublished state that's annoying to recover from.

Since verify-merges already confirms the bump commit is on origin/main, a few ways to fix this:

Option 1 — Pin to a SHA captured at prepare time. Have prepare-main/prepare-preview output the SHA of the bump commit they pushed, then check that out in the publish jobs. This is the most robust — the SHA stays reachable from main (merge-commit strategy is in use, so the release-branch tip is preserved) even after the branch is deleted.

# in prepare-main, after git push origin $BRANCH_NAMEecho "sha=$(git rev-parse HEAD)" >> $GITHUB_OUTPUT

# in publish-mainwith:
ref: ${{ needs.prepare-main.outputs.sha }}

Option 2 — Go back to checking out main/preview but force a fresh fetch. Since verify-merges has already proven origin/main contains the bump commit, checking out main should be safe. The original stale-ref problem can be avoided by setting fetch-depth: 0 and explicitly git fetch origin main && git reset --hard origin/main in a follow-up step, or by using the merge commit SHA of the release PR.

Option 3 — Keep this PR's approach but prevent branch deletion. Disable auto-delete-on-merge for the repo, and/or add a note/comment on the release PR asking reviewers not to delete the branch. This is the most fragile option since it relies on human discipline.

I'd recommend Option 1 — it's the smallest change and doesn't depend on branch retention or repo settings.

---

A related but smaller concern: the tag creation step also runs against the release-branch checkout, so the tag ends up on the bump commit (e.g. c097232) rather than on the merge commit on main. Since merge-commit strategy is in use, that commit is reachable from main, so this is fine in practice — just worth being aware of if you ever switch to squash merges.

[aidandaly24]

Closing: fresh run with CI fix improvements

[aidandaly24]

Description

The publish jobs were checking out main/preview which could serve a stale git ref that didn't include the version bump commit. This caused 0.12.1 to be published with the 0.12.0 package.json.

Now the publish jobs checkout release/v<version> directly, which is guaranteed to have the correct version. Added a version verification step before npm publish as a safety check.

Prior art — how other OSS repos handle this

Repo	Pattern	Publishes from main?
Turborepo	Creates a staging branch, publishes from it	No — staging branch
Nx	Dynamic ref resolution, dedicated publish branch	No — PR branch or publish branch
Next.js	Clones canary branch explicitly	No — canary branch
Vite	Tag-triggered, checks out tag ref	No — tag ref
Vue.js	Tag-triggered, checks out tag ref	No — tag ref

None of these projects publish from the base branch HEAD — they all publish from a release branch, staging branch, or tag ref.

Related Issue

Closes #

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	43%	7778 / 18086
🔵	Statements	42.4%	8230 / 19407
🔵	Functions	40.33%	1340 / 3322
🔵	Branches	40.66%	5103 / 12548

Generated in workflow #2159 for commit a0eb504 by the Vitest Coverage Report Action

[agentcore-cli-automation]

Publish will fail if the release branch is deleted after merge

Looking at recent merged release PRs, the release/v<version> branches are deleted after merge — only release/v0.9.2 remains out of all past releases. So this is either auto-delete-on-merge being enabled, or reviewers manually deleting the branch when clicking Merge (both are very common defaults).

The new publish flow depends on the release branch still existing at publish time:

- name: Checkout release branchuses: actions/checkout@v6with:
ref: release/v${{ needs.prepare-main.outputs.version }}

But publish-main runs after verify-merges, which only passes once the release PR has been merged into main. If the branch gets deleted as part of (or right after) that merge, actions/checkout won't be able to resolve the ref and the publish step will fail — right after the approval gate, with a released-but-unpublished state that's annoying to recover from.

Since verify-merges already confirms the bump commit is on origin/main, a few ways to fix this:

Option 1 — Pin to a SHA captured at prepare time. Have prepare-main/prepare-preview output the SHA of the bump commit they pushed, then check that out in the publish jobs. This is the most robust — the SHA stays reachable from main (merge-commit strategy is in use, so the release-branch tip is preserved) even after the branch is deleted.

# in prepare-main, after git push origin $BRANCH_NAMEecho "sha=$(git rev-parse HEAD)" >> $GITHUB_OUTPUT

# in publish-mainwith:
ref: ${{ needs.prepare-main.outputs.sha }}

Option 2 — Go back to checking out main/preview but force a fresh fetch. Since verify-merges has already proven origin/main contains the bump commit, checking out main should be safe. The original stale-ref problem can be avoided by setting fetch-depth: 0 and explicitly git fetch origin main && git reset --hard origin/main in a follow-up step, or by using the merge commit SHA of the release PR.

Option 3 — Keep this PR's approach but prevent branch deletion. Disable auto-delete-on-merge for the repo, and/or add a note/comment on the release PR asking reviewers not to delete the branch. This is the most fragile option since it relies on human discipline.

I'd recommend Option 1 — it's the smallest change and doesn't depend on branch retention or repo settings.

---

A related but smaller concern: the tag creation step also runs against the release-branch checkout, so the tag ends up on the bump commit (e.g. c097232) rather than on the merge commit on main. Since merge-commit strategy is in use, that commit is reachable from main, so this is fine in practice — just worth being aware of if you ever switch to squash merges.

[aidandaly24]

Closing: fresh run with CI fix improvements