Use stable OpenClaw releases as the source channel for MSIX releases

[xlinush]

Summary

Gateway MSIX releases will follow OpenClaw's stable releases only. This agreed requirement supersedes the earlier proposal to use extended-stable.

Implementation PR: #42

Agreed release policy

• Select the upstream stable release through npm openclaw@latest.
• Resolve the selected release once, verify its version, Git tag, and source commit, and keep that immutable selection fixed across the complete build/signing run, both architectures, and retries.
• Reject extended-stable and prerelease versions, including through manual source overrides and legacy payload metadata.
• Do not automatically fall back to another version or channel on failure. A reviewed stableVersion policy pin may explicitly select an older known-good stable release when compatibility requires it; the review must establish that required behavior is preserved.
• Keep official releases manually dispatched from main and gated by the protected signing environment. Manual source overrides remain limited to unsigned/test builds and must still select regular-stable versions.

This replaces per-release source-commit approval with an explicit stable-channel policy. Source selection follows upstream release publication, while each MSIX still contains an immutable source snapshot. Existing signing authorization and content-integrity requirements remain in force.

Implementation requirements

• Use one source resolver and make Linux, x64, and ARM64 jobs consume the same frozen version, tag, and commit.
• Preserve source-selection and release evidence through source.json, payload-metadata.json, msix-metadata.json, and final release assets; reject inconsistent, stale, or wrong-policy metadata.
• Retain package hashes, manifests, inventory, architecture, clean-tree, publisher, packaging-commit, and signing-input checks.
• Support stable numeric corrections in the four-part MSIX version while retaining overflow and duplicate/downgrade checks.
• Cover rejected extended-stable/prerelease inputs, explicit older-stable pins, pin/snapshot mismatches, version/tag/commit disagreement, cross-architecture disagreement, retry snapshot reuse, and the absence of automatic fallback.
• Document stable-only selection, the reviewed compatibility-pin process, and upstream cadence/support expectations without implying an additional MSIX support guarantee.

Acceptance criteria

• Agree to use stable OpenClaw releases instead of extended-stable.
• Stable selection resolves once and records an immutable version, tag, and commit for the complete build/signing run and its retries.
• Official x64 and ARM64 packages cannot be produced from different source resolutions.
• Extended-stable and prerelease inputs are rejected; failures never silently select another version or channel.
• Any older-stable compatibility pin is explicit, reviewed, and supported by evidence that required behavior is preserved.
• Existing MSIX content-integrity and signing checks remain enforced, and release-governance/signing-authorization questions are reviewed.
• Stable-channel behavior and accepted upstream cadence/support expectations are documented for partners.

References

• Implementation: feat: track stable OpenClaw releases for MSIX builds #42
• https://github.com/openclaw/openclaw/blob/main/docs/reference/RELEASING.md
• https://github.com/openclaw/openclaw/blob/main/docs/install/development-channels.md

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 15, 2026, 7:09 PM ET / 23:09 UTC.

Summary
Stable-only selection is now agreed, but current main and the latest release still require an individually approved source commit. The collaborator-authored issue remains necessary and is owned by the open implementation PR: #42.

Reproducibility: not applicable. this is an agreed release-policy change, and current source directly establishes the existing per-commit approval behavior.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
When signing authorization is withdrawn after source resolution, should waiting or retried official runs be rejected before signing and publication?	Require current authorization: Keep the frozen source selection while rejecting withdrawn authorization before signing or publication, including retries.

Why: The channel choice is settled, but the issue and implementation explicitly retain this release-governance question; source immutability does not define the lifetime of signing permission.

Next step
Review the signing-governance acceptance and implementation in #42; the open paired PR and no-new-fix-PR signal exclude another repair branch.

Security
Needs attention: The request changes official source authorization, and the linked implementation explicitly leaves withdrawal semantics for review.

Review details

Best possible solution:

Use one frozen, verified stable source across the entire release, with explicit compatibility pins and current signing authorization enforced before signing or publication.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is an agreed release-policy change, and current source directly establishes the existing per-commit approval behavior.

Is this the best way to solve the issue?

Yes: a shared immutable stable selection is consistent with the existing cross-architecture metadata trust chain; the linked implementation still needs its signing-governance acceptance completed.

AGENTS.md: not found in the target repository.

Remaining risk / open question:

• The linked implementation acknowledges unresolved signing/publication evidence and signing-authorization withdrawal semantics; resolving a stable source alone does not settle those acceptance criteria.

Codex review notes: model internal, reasoning medium; reviewed against 3e5b1fff078e.

Label changes

Label justifications:

• P2: This is a bounded release-policy improvement with an active implementation, without evidence of an emergency user-facing failure.
• impact:security: The request changes which upstream sources qualify for official signing while preserving signing authorization and content integrity.

Evidence reviewed

Security concerns:

• [medium] Define authorization lifetime across release retries
  The agreed immutable source snapshot must not implicitly establish perpetual signing permission; withdrawal handling remains an explicit acceptance question, not a demonstrated exploit.
  Confidence: 0.9

What I checked:

• Current source selection remains pinned: The workflow dispatch default and automatic-build fallback select commit 0965053fe6b9341776df147a6934b7485c60b5ca; release policy approves that commit and payload version 2026.8.2 rather than resolving npm latest. (release-policy.json:5, 3e5b1fff078e)
• Existing signing contract: Signing validation requires the requested ref and both architecture metadata records to match the policy-approved immutable commit. The inspected regression suite also rejects a tag as the official requested ref. The workflow separately restricts official dispatch to main and uses the protected release-signing environment. (scripts/Test-SigningInputs.ps1:173, 3e5b1fff078e)
• Latest release still has the existing policy: GitHub identifies v0.0.0.1, published September 15, 2026, as the latest release and targets the inspected main revision. The tag also points at this revision locally; stable-channel resolution has not landed there. (release-policy.json:3, 3e5b1fff078e)
• Open implementation owns the remaining work: feat: track stable OpenClaw releases for MSIX builds #42 is open, draft, and unmerged at d11d1e0. The supplied body explicitly closes this issue, adopts stable-only selection, reports successful source resolution and focused checks, and acknowledges that Azure signing/publication and signing-authorization withdrawal remain unproven. These are contributor-reported results, not independently executed proof in this issue review. (d11d1e09388b)
• Updated agreement supersedes earlier triage: The captured issue body explicitly agrees to stable releases, replacing extended-stable and per-release source-commit approval. The earlier review's unresolved channel-choice conclusion is therefore obsolete; remaining review concerns are implementation acceptance and signing governance.
• Release and signing routing history: Path history identifies Dallin Romney's signing-publication and release-policy work and Linus Huang's bundled-runtime and source-selection work. GitHub maps the recent release and signing-publication commits to RomneyDa. Historical blame could not complete because a required blob was unavailable; these are routing candidates, not verified source-line introduction claims. (scripts/Test-SigningInputs.ps1, 54d4c43adfd8)

Likely related people:

• RomneyDa: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Linus Huang: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.