feat(ci): publish signed Gateway MSIX releases

[RomneyDa]

Summary

• publish signed x64, ARM64, and multi-architecture MSIX assets on a permanent GitHub Release
• create the release tag and generate GitHub release notes
• authorize the bundle contents against the approved standalone packages before Azure login
• use explicit v0.0.0.0 / 0.0.0.0 policy values for the initial signing proof while keeping the Gateway payload pinned to its approved commit

Validation

• prior stacked PR passed the Windows host suite and full x64/ARM64 MakeAppx composition
• fresh exact-head CI must pass before merge
• local PowerShell tests unavailable on this macOS host (pwsh is not installed)

Supersedes closed stacked PR #32 after #24 merged.

[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 12, 2026, 3:36 AM ET / 07:36 UTC.

ClawSweeper review

What this changes

The PR bundles x64 and ARM64 Windows packages, validates and signs them, and publishes permanent GitHub Release downloads using explicit release-policy versions.

Merge readiness

⛔ Blocked before merge - 4 items remain

Keep open: permanent signed releases remain absent from main, and the prerequisite signing setup has merged. This member-authored successor contains useful, distinct work.

Priority: P2
Reviewed head: 97a4922c03b620ae52c3f92ec86345abb12a2e2d
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	The implementation is focused and contains meaningful content-validation coverage; initial release staging needs an explicit owner decision.
Proof confidence	🌊 off-meta tidepool	Not applicable: The member author is exempt from ordinary contributor proof. The body reports prior Windows composition and policy validation; those do not establish signed-package installation, which remains a release-readiness consideration.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: The member author is exempt from ordinary contributor proof. The body reports prior Windows composition and policy validation; those do not establish signed-package installation, which remains a release-readiness consideration.
Evidence reviewed	9 items	Current-main boundary: The pinned main workflow signs standalone packages and uploads seven-day artifacts; it has neither bundle composition nor permanent release publication. The host-verified introduction delta contains these additions. Bundle authorization: The validator checks bundle identity, exactly two distinct architecture entries, filenames, versions, and embedded-package SHA-256 equality against authorized standalone packages. Signing requires authorization success and retrieves the same run-scoped artifacts. The added substituted-package test exercises rejection through this validator. Initial proof becomes latest stable: release-policy.json selects package version 0.0.0.0 and tag v0.0.0.0. The publication step explicitly sets prerelease false and make_latest true, without an installation-verification gate. README.md describes this version as the initial signing proof.
Findings	None	None.
Security	None	None.

How this fits together

This repository packages OpenClaw Gateway for Windows. Its workflow turns an approved upstream revision into installation packages, validates their contents, and passes authorized artifacts through signing to downloadable releases.

flowchart TD
  A[Approved Gateway revision] --> B[x64 and ARM64 packages]
  B --> C[Combined installation bundle]
  B --> D[Release policy and content validation]
  C --> D
  D --> E[Protected Azure signing]
  E --> F[GitHub Release downloads]
  F --> G[Windows installation]

Loading

Decision needed

Question	Recommendation
Should the v0.0.0.0 signing proof become latest stable immediately, or remain staged until Windows installation is verified?	Stage the signing proof: Keep the initial release as a draft until fresh-install verification and the treatment of higher-version test installations are recorded.

Why: The existing discussion schedules verification after the first official run, while this workflow publishes automatically; choosing the acceptable exposure and test-install transition requires release-owner intent.

Before merge

• Resolve merge risk (P1) - The initial signing proof is automatically published as latest stable before the planned Windows fresh-install verification, exposing the recommended download before installation compatibility is established.
• Resolve merge risk (P1) - Version 0.0.0.0 is below existing local/test package versions; moving those installations to this proof release may require explicit recovery rather than an ordinary upgrade. No prior official release exists, so an official-to-official upgrade test is not applicable.
• Complete next step (P2) - Resolve whether the initial v0.0.0.0 proof stays staged or becomes latest stable, including the installation-validation gate and treatment of higher-version test installations.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Code growth	Production scripts +260/-1; tests and workflow checks +269/-3; workflow +212/-4	The growth supports the stated bundle construction, authorization, versioning, and publication scope.

Root-cause cluster

Relationship: canonical
Canonical: #33
Summary: This is the declared successor for permanent-release work after the signing prerequisite merged.

Members:

• superseded: feat(ci): publish Gateway MSIX releases #32 - The prior stacked implementation is closed unmerged, and this PR explicitly replaces it.
• adjacent_distinct: chore(ci): finalize Artifact Signing setup #24 - The merged prerequisite configures signing infrastructure but does not provide permanent release downloads.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge-risk options

Maintainer options:

1. Separate signing from release promotion (recommended)
   Use a draft for the initial signed artifacts and promote them after installation validation and test-install transition guidance.
2. Own the initial-release limitation
   Approve immediate publication with an explicit statement that the zero-version proof is not a normal upgrade from higher-version test packages.

Technical review

Best possible solution:

Stage the initial signed assets as a draft, then promote verified Windows downloads with an explicit transition policy for existing test installations.

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

Not applicable: this adds release distribution, and source review established no discrete introduced runtime defect; Windows installation was not executed.

Is this the best way to solve the issue?

Yes, extending the existing packaging pipeline is appropriate; separating initial signing from public promotion would better support the documented first-run validation plan.

AGENTS.md: not found in the target repository.

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

Labels

Label changes:

• add P2: Permanent Windows release distribution is a bounded improvement without an established urgent production failure.
• add merge-risk: 🚨 compatibility: The recommended download becomes a zero-version bundle before Windows installation and the transition from higher-version test packages are established.
• 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 author is exempt from ordinary contributor proof. The body reports prior Windows composition and policy validation; those do not establish signed-package installation, which remains a release-readiness consideration.

Label justifications:

• P2: Permanent Windows release distribution is a bounded improvement without an established urgent production failure.
• merge-risk: 🚨 compatibility: The recommended download becomes a zero-version bundle before Windows installation and the transition from higher-version test packages are established.
• 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 author is exempt from ordinary contributor proof. The body reports prior Windows composition and policy validation; those do not establish signed-package installation, which remains a release-readiness consideration.

Evidence

What I checked:

• Current-main boundary: The pinned main workflow signs standalone packages and uploads seven-day artifacts; it has neither bundle composition nor permanent release publication. The host-verified introduction delta contains these additions. (.github/workflows/gateway-msix.yml, cc1d83318281)
• Bundle authorization: The validator checks bundle identity, exactly two distinct architecture entries, filenames, versions, and embedded-package SHA-256 equality against authorized standalone packages. Signing requires authorization success and retrieves the same run-scoped artifacts. The added substituted-package test exercises rejection through this validator. (scripts/Test-SigningInputs.ps1:346, 97a4922c03b6)
• Initial proof becomes latest stable: release-policy.json selects package version 0.0.0.0 and tag v0.0.0.0. The publication step explicitly sets prerelease false and make_latest true, without an installation-verification gate. README.md describes this version as the initial signing proof. (.github/workflows/gateway-msix.yml:669, 97a4922c03b6)
• Maintainer-provided first-release context: The member comment confirms configured signing infrastructure, no previously official-signed packages, and planned fresh-install verification on the first official main run before announcement. Its earlier upgrade rationale assumed a greater 2026.x version; this PR instead selects 0.0.0.0. See chore(ci): finalize Artifact Signing setup #24 (comment).
• Release availability: The releases endpoint returned zero releases, corroborating the first-release context; there is no shipped implementation to supersede this PR.
• Merged signing prerequisite: GitHub confirms chore(ci): finalize Artifact Signing setup #24 merged at the pinned main SHA. Its changes configure Azure environment variables and recursive standalone-package discovery, rather than implementing this PR's permanent releases. (.github/workflows/gateway-msix.yml, cc1d83318281)

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)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Record fresh-install results before promoting the initial signed downloads, and document how higher-version local/test installations should transition.

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.

[RomneyDa]

Owner decision: publish the initial v0.0.0.0 signing proof immediately after merge. This is intentionally a plumbing/signing validation release, not an upgrade-compatible production version. Existing higher-version unsigned or test-signed installations may require uninstall before installing it; there is no prior official release to upgrade from. Exact-head CI passed standalone x64/ARM64 MakeAppx composition and bundle composition.

@clawsweeper re-review