feat(msix): publish multi-architecture Store bundle

[RomneyDa]

Summary

• compose a real x64/ARM64 OpenClaw.msixbundle after the standalone Store packages succeed
• require the bundle lane in CI Gate and tagged release publication
• verify the published bundle identity, version, architecture set, and embedded package hashes before staging release assets
• retain standalone MSIX files and provenance metadata as inspection and fallback assets

Required proof pools

• none: this changes release packaging and workflow contracts, not tray UX, MCP, node commands, permissions, or diagnostics

Validation

Passed locally:

• pwsh -NoProfile -File ./scripts/test-msix-bundle.ps1
• pwsh -NoProfile -File ./scripts/test-msix-alpha-release.ps1
• pwsh -NoProfile -File ./scripts/test-ci-gate-results.ps1
• pwsh -NoProfile -File ./scripts/test-ci-workflow-contract.ps1
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore --filter FullyQualifiedName~ReleaseSigningWorkflowTests.ReleaseWorkflow_PublishesOnlyUnsignedStoreMsixForAlphaTags
• pwsh -NoProfile -File ./scripts/test-msix-versioning.ps1
• pwsh -NoProfile -File ./scripts/test-msix-preview-source-version.ps1
• git diff --check

Local Windows-only closeout blockers on macOS:

• build.ps1 exits at its explicit Windows prerequisite
• shared and tray suites were attempted, but existing Windows path, process, GDI+, and source-newline assumptions fail on macOS
• test-msix-ci-artifacts.ps1 requires the Windows Export-Certificate cmdlet
• validate-docs.ps1 rejects a Windows-backslash proof-pool path on macOS

Real behavior proof

Not verified locally: MakeAppx.exe and the two real architecture packages require Windows. This PR adds a Windows CI bundle job that runs MakeAppx.exe against the exact x64 and ARM64 artifacts, uploads the resulting bundle, and makes both CI Gate and tag publication fail closed if that job does not succeed.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge. Reviewed September 19, 2026, 10:54 PM ET / September 20, 2026, 02:54 UTC (Revision 2).

ClawSweeper review

What this changes

Adds a single unsigned x64/ARM64 Store submission bundle, validates its embedded packages, and integrates it into CI and alpha release publication.

Merge readiness

⛔ Blocked before merge - 2 items remain

The previous version-boundary finding is resolved, and no additional actionable defect was found. Current main lacks bundle publication, so this member-authored PR remains useful.

Priority: P2
Reviewed head: 49d3a72beb5159f735a890dc10651663ae79832d

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused implementation with the prior finding fixed, appropriate regression coverage, and no remaining blocking correctness finding.
Proof confidence	🌊 off-meta tidepool	Not applicable: The member-authored PR is exempt from the external-contributor proof gate. GitHub confirms prior-head Windows bundle construction and upload succeeded; current-head packaging remains in progress, and real alpha staging was not demonstrated.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: The member-authored PR is exempt from the external-contributor proof gate. GitHub confirms prior-head Windows bundle construction and upload succeeded; current-head packaging remains in progress, and real alpha staging was not demonstrated.
Evidence reviewed	8 items	Previous finding resolved: GitHub's commit patch confirms that the latest commit removes only the incorrect 65534 ceiling from the builder and adds acceptance coverage for 2026.9.65535.0 and rejection coverage for 2026.9.65536.0. UInt16 parsing and the final .0 requirement remain. Matches the existing version contract: The standalone builder already uses UInt16 parsing, and the allocator regression explicitly accepts 2026.9.65535.0. The corrected bundle builder now agrees with both. Still distinct from main and the latest release: The main-branch stager publishes standalone packages and metadata without a bundle. The main-tree bundle search found no implementation, and the supplied latest-release commit has no bundle builder. The merged packaging and version-allocation PRs are prerequisites, not replacements.
Findings	None	None.
Security	None	None.

How this fits together

The release pipeline builds architecture-specific Windows packages using one allocated version. Bundle construction combines those packages, and alpha release staging checks their identity and hashes before publishing submission assets.

flowchart LR
  A[Shared package version] --> B[x64 and ARM64 packages]
  B --> C[Windows bundle builder]
  C --> D[CI release gate]
  C --> E[Identity and hash checks]
  B --> E
  E --> F[Alpha submission assets]
  D --> F

Loading

Before merge

• Resolve merge risk (P1) - Bundle failures will also stop stable EXE/ZIP publication, despite stable releases carrying no bundle attachment; this broader release dependency is intentional.
• Resolve merge risk (P1) - The supplied Windows success covers bundle construction at the previous head, not alpha-only staging of a genuine reserved bundle through publication.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Production and test growth	Release scripts +179 net lines; tests +176; workflow +59	Production growth implements bundle construction and pre-publication validation, with focused boundary and workflow coverage.

Merge-risk options

Maintainer options:

1. Retain the declared release dependency (recommended)
   Accept that bundle failures stop all tagged publication, consistent with the member author's stated design and the existing release gate.

Technical review

Best possible solution:

Preserve the member-requested release gate, shared version allocation, and byte-preserving bundle validation while retaining standalone submission assets.

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

Not applicable to the feature itself. Source inspection confirms the previous version-boundary defect is removed and both requested boundary cases are covered.

Is this the best way to solve the issue?

Yes. Composing existing validated packages with MakeAppx avoids duplicating package production and preserves the existing allocation and provenance contracts.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 8ed7c56dfd02.

Labels

Label changes:

• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The member-authored PR is exempt from the external-contributor proof gate. GitHub confirms prior-head Windows bundle construction and upload succeeded; current-head packaging remains in progress, and real alpha staging was not demonstrated.
• remove rating: 🦐 gold shrimp: Current PR rating is rating: 🐚 platinum hermit, so this older rating label is no longer current.
• remove status: ⏳ waiting on author: Current PR status label is status: 👀 ready for maintainer look.

Label justifications:

• P2: This is a bounded release-packaging improvement without an established urgent user regression.
• merge-risk: 🚨 automation: The new bundle job becomes a mandatory dependency for every tagged release, including stable EXE/ZIP publication.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The member-authored PR is exempt from the external-contributor proof gate. GitHub confirms prior-head Windows bundle construction and upload succeeded; current-head packaging remains in progress, and real alpha staging was not demonstrated.

Evidence

What I checked:

• Previous finding resolved: GitHub's commit patch confirms that the latest commit removes only the incorrect 65534 ceiling from the builder and adds acceptance coverage for 2026.9.65535.0 and rejection coverage for 2026.9.65536.0. UInt16 parsing and the final .0 requirement remain. (scripts/Build-StoreMsixBundle.ps1:59, 49d3a72beb51)
• Matches the existing version contract: The standalone builder already uses UInt16 parsing, and the allocator regression explicitly accepts 2026.9.65535.0. The corrected bundle builder now agrees with both. (scripts/test-msix-versioning.ps1:302, 49d3a72beb51)
• Still distinct from main and the latest release: The main-branch stager publishes standalone packages and metadata without a bundle. The main-tree bundle search found no implementation, and the supplied latest-release commit has no bundle builder. The merged packaging and version-allocation PRs are prerequisites, not replacements. (scripts/Stage-StoreMsixReleaseAssets.ps1:80, 8ed7c56dfd02)
• Bundle validation precedes publication: The stager checks bundle identity and version, requires both architecture entries, and compares each embedded package hash with the already validated standalone artifact before creating release output. The existing alpha-only download pattern includes the new bundle artifact. (scripts/Stage-StoreMsixReleaseAssets.ps1:87, 49d3a72beb51)
• Historical Windows bundle execution: The linked Windows job reports successful architecture downloads, version validation, bundle composition, and artifact upload at the prior reviewed head: https://github.com/openclaw/openclaw-windows-node/actions/runs/35482955166/job/106005091185. Raw log retrieval was blocked by the reviewer network allowlist, so execution details and real alpha staging were not independently inspected. Related-PR screenshots were inspected and show earlier installation/version behavior, not this bundle path. (.github/workflows/ci.yml:1020, bfc34c2d905c)
• Current validation state: Current-head fast validation and release metadata succeeded; Windows packaging and broader test jobs were still running when inspected. No build or test was executed during this read-only review, and the checkout remained clean. (.github/workflows/ci.yml:117, 49d3a72beb51)

Likely related people:

• unknown: The claimed source-line change could not be verified from bounded local history. (role: source history unknown; confidence: low)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• 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.

History

Review history (1 earlier review cycle)

• reviewed 2026-09-20T02:11:07.104Z sha bfc34c2 :: blocked before merge. :: [P2] Accept the allocator's valid 65535 version component

[RomneyDa]

@clawsweeper re-review

Addressed the actionable finding in 49d3a72:

• removed the incorrect 65534 ceiling while retaining UInt16 parsing and the Store-required .0 revision rule
• added acceptance coverage for 2026.9.65535.0
• added rejection coverage for 2026.9.65536.0

Focused bundle, alpha staging, CI Gate, and workflow contract tests pass. The prior reviewed head also completed the real Windows MakeAppx bundle job successfully: https://github.com/openclaw/openclaw-windows-node/actions/runs/35482955166/job/106005091185. Exact-head CI is running now.

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/35485268591
• Updated: 2026-09-20T02:56:10.682Z