chore(release): sync manifests to 4.1.27 (publish pushed to npm, version commit lost to a race)

[khaliqgant]

What happened

The 4.1.27 publish (workflow_dispatch, run 29573660080) published all packages to npm successfully and pushed all 12 tags, then failed on its final Tag + push step:

 * [new tag]         runtime-v4.1.27 -> runtime-v4.1.27
 ...
 ! [rejected]        HEAD -> main (fetch first)
error: failed to push some refs

PR #283 merged to main while the release job was running, so the workflow's version-bump commit could not fast-forward.

Resulting drift

	version
npm (all 12 packages)	4.1.27
git tags *-v4.1.27	exist, pointing at 7fe85f78 — not an ancestor of main
main's manifests	4.1.26

The published artifacts are correct and verified — @agentworkforce/runtime@4.1.27 contains dist/no-reply.js and the NO_REPLY marker (#278). Only the repo's record of the release is missing.

Left unfixed, the next publish would try to bump 4.1.26 → 4.1.27 again and collide with what's already on npm.

This PR

A clean cherry-pick of the lost release commit 7fe85f78 onto current main — the same 16 files (12 package.json version bumps + 4 CHANGELOG entries), nothing else.

Follow-up worth considering

The Tag + push step pushes tags before pushing the commit, so a race leaves tags published against a commit that never lands — the repo ends up in this split state rather than failing cleanly. Making that step git pull --rebase before pushing (or pushing the commit before the tags) would make the release idempotent under concurrent merges.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[coderabbitai]

Warning

Review limit reached

@khaliqgant, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 16 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: d123eb06-00d8-4093-93c3-95b29a912b58

📥 Commits

Reviewing files that changed from the base of the PR and between e1f60c4 and c12d8c1.

📒 Files selected for processing (16)

• packages/agentworkforce/package.json
• packages/cli/CHANGELOG.md
• packages/cli/package.json
• packages/compose/package.json
• packages/daytona-runner/package.json
• packages/delivery/package.json
• packages/deploy/CHANGELOG.md
• packages/deploy/package.json
• packages/events/package.json
• packages/local-surface/package.json
• packages/mcp-workforce/package.json
• packages/persona-kit/CHANGELOG.md
• packages/persona-kit/package.json
• packages/runtime/CHANGELOG.md
• packages/runtime/package.json
• packages/workload-router/package.json

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/release-4.1.27-manifest-sync

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gemini-code-assist]

Code Review

This pull request bumps the version of various packages in the repository from 4.1.26 to 4.1.27 and updates the corresponding CHANGELOG.md files to document the release. I have no feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[khaliqgant]

Closing as obsolete — the drift this fixed no longer exists, and merging it now would re-create it in the opposite direction.

Releases 4.1.28 and 4.1.29 ran after the failed 4.1.27 job and their version commits landed on main cleanly. Current state:

	version
main's manifests	4.1.29
npm latest	4.1.29
published	…4.1.27, 4.1.28, 4.1.29

main and npm are back in sync, and main is now ahead of this PR. Resolving the conflicts in favour of this branch would downgrade main's manifests 4.1.29 → 4.1.27 and break the next release; resolving in favour of main leaves the PR empty. Nothing of substance was lost — the orphaned commit 7fe85f78 contained only version bumps, and the actual #278 code has been on main since 4034d097.

Verified @agentworkforce/runtime@4.1.29 ships dist/no-reply.js with NO_REPLY_MARKER = '[[NO_REPLY]]', so #277 is fully published.

Residue: the 12 *-v4.1.27 tags still point at 7fe85f78, which is not an ancestor of main. Harmless but misleading — worth deleting if you keep tags meaningful.

The real follow-up stands: the Tag + push step pushes tags before the version commit, so any concurrent merge splits a release exactly like this — npm and tags advance, main doesn't, and the job reports failure after the irreversible part already succeeded. A git pull --rebase before the push (or pushing the commit first) would make releases idempotent under concurrent merges. Given how fast main moves here, this will recur.