[rares04]

What

In a live build session (LUA_BUILD_SESSION=1), confirm-deploy blocked lua version promote <N> and told Claude to call request_release. A release ships the session's files, so asking to go back to version N produced a release of the session's code, not version N (LUA-1861).

The platform now runs version promote <N> from a session as one approval card that puts the existing version N back live: nothing is rebuilt and the session's files don't change. This PR routes the command there:

• lib/session-mode.mjs: lua version promote leaves RELEASE_LABELS, so the block names request_action with command: "version promote".
• lib/session-commands.mjs: the vendored row's note matches the monorepo table ("Puts that version back live.").
• lib/knowledge/build-session.md and docs/BUILD_SESSION.md say the same.
• Version 1.17.1 with a CHANGELOG entry.

I checked the whole list against the platform's routes. Every other verb in RELEASE_LABELS (lua deploy, the per-primitive deploys, lua persona production deploy, lua workflows deploy) is still a release on the server. version promote was the only one on the wrong route.

Nothing changes outside session mode.

Proof

• Live on staging (2026-10-29), with the pod on 1.17.0: lua version promote 14 in a session was denied by this hook with DEPLOY_DENIED_SESSION … call mcp__lua-session__request_release. The same request through request_action produced the right card: "Puts version 14 back live in place of version 15. Nothing is rebuilt; Changes the skill …; Your session's files don't change …". I declined it, and v15 is still live.
• Tests: the changed hook and lib tests fail on main (3 failed) and pass with the fix. Full suite: 72 suites, 2546 tests passed.

After merge

The session pod image pins the plugin. The pin bump goes on the lua-core-services staging follow-up, then image re-pins on staging and prod. The Job tier pins 1.12.0, which has no session mode, so it isn't affected.

🤖 Generated with Claude Code

[selcuk-lua]

Code review — LOW risk

Narrow, well-targeted fix: lua version promote <N> in a build session is re-routed from request_release to request_action by dropping it from RELEASE_LABELS, so sessionDeployBlockReason now emits the action-request guidance (promote puts the existing version N back live, nothing rebuilt). The change is consistently mirrored across the vendored classifier note, build-session.md, docs/BUILD_SESSION.md, the CHANGELOG, and updated tests, and the tokenizer/confirm-deploy gate logic is untouched so non-session behavior is unchanged. The remaining nits are internal comments and one session-guard advisory path that still describe the old "promote is a release" behavior.

Minor

• plugins/lua-agent-builder/lib/session-mode.mjs:16 — The module header comment still says "lua deploy / lua version promote become a RELEASE … never a bare promote", contradicting the new routing. Update it to reflect that version promote <N> is now an action request.
• plugins/lua-agent-builder/lib/session-mode.mjs:243 — approvalNote() still groups version.promote with deploy/push.auto_deploy and appends "Making code live is a release: call request_release instead." The test/lib/session-mode.test.mjs test (deploy, promote and --auto-deploy at request_release) still pins this, so the session-guard warning now contradicts the confirm-deploy block and the docs for the same command. Move version.promote to request_action wording and update the test.
• plugins/lua-agent-builder/mcp/lua-platform/dist/server.js:1 — Regenerated minified bundle committed with the version bump; confirm it was produced by the standard npm run build and the diff is limited to the version string.

---

_{PR Risk Reviewer — automated senior review of fb8266d · risk: low · confidence: 0.86}