feat(ci): derive deterministic MSIX release versions

[RomneyDa]

Summary

• replace the one-time 0.0.0.1 policy with a Gateway tag plus an independent MSIX-only rebuild number
• advance the approved Gateway payload to stable v2026.9.4
• derive deterministic four-part MSIX identities with 1,000 rebuild slots per Gateway release sequence
• preserve exact Gateway provenance in the GitHub release tag and package metadata
• require the outer bundle identity to match the approved package version
• prove clean installation and state-preserving upgrades from both published proof-release delivery formats

Version mapping

Gateway	MSIX rebuild	GitHub release tag	MSIX identity
v2026.7.1	0	v2026.7.1-msix.0	2026.7.1.1000
v2026.7.1-2	0	v2026.7.1-2-msix.0	2026.7.1.2000
same correction repackaged	1	v2026.7.1-2-msix.1	2026.7.1.2001
v2026.7.2	0	v2026.7.2-msix.0	2026.7.2.1000

The unsuffixed Gateway tag is release sequence 1; correction tags use their numeric suffix. The fourth component is gateway release sequence * 1000 + MSIX rebuild. An MSIX-only rebuild therefore cannot consume or shift the version assigned to a later Gateway correction. msixRevision is constrained to 0..999, and Gateway correction suffixes to 2..64, giving every supported sequence a complete 1,000-number block beneath the MSIX component ceiling.

The policy resolves pinned Gateway v2026.9.4 at immutable commit 3a9d69db306cd7f081e06254cb89c4bcc14a7107, rebuild 0, to release tag v2026.9.4-msix.0 and MSIX identity 2026.9.4.1000.

Compatibility validation

Versioning changes run on a clean GitHub-hosted Windows account and test:

• fresh installation of the standalone x64 MSIX and recommended .msixbundle candidate;
• upgrades from hash-pinned v0.0.0.0 and v0.0.0.1 standalone x64 assets;
• upgrades from the recommended v0.0.0.0 and v0.0.0.1 bundle assets;
• stable package family identity and retained package LocalState across every transition.

The harness refuses pre-existing OpenClaw.Gateway registrations before importing a test certificate and removes only a package installed by its own invocation.

Validation

• workflow YAML parses
• release-policy.json and transition-baseline JSON parse
• git diff --check
• Windows PowerShell coverage for stable tags, multi-digit Gateway patches, correction/rebuild isolation, ordering, component boundaries, downstream workflow validation, signing policy, and bundle-version authorization
• exact-head Windows fresh-install and standalone/bundle transition evidence (required before merge)

Microsoft Store submissions reserve the fourth package-version component as zero. Store publication is explicitly out of scope here and will need a separate version policy when introduced.

[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: needs maintainer review before merge. Reviewed September 17, 2026, 2:40 AM ET / 06:40 UTC (Revision 13).

ClawSweeper review

What this changes

Derive Windows package and release versions from Gateway tags and packaging revisions, advance the payload to 2026.9.4, and add fresh-install and state-preserving upgrade checks.

Merge readiness

✅ Ready for maintainer review

The previous upgrade-proof blocker is resolved by candidate-specific Windows acceptance results. No blocking defect remains; this maintainer-authored PR remains useful because main still uses the proof-release version policy.

Priority: P2
Reviewed head: b0bbae78871c730a13b98a9c53ace3f5b3aa4f6b

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused release-policy implementation with strong candidate-specific Windows acceptance evidence and no remaining blocking findings.
Proof confidence	🦞 diamond lobster (5/6)	Sufficient (live_output): For the current head, the Windows deployment harness exercises real standalone and bundle installation to 2026.9.4.1000: two fresh installs and four upgrades report Ok, stable package family, and retained LocalState. The explicit contributor results and verified successful run resolve the previous rank-up request; the proxy prevented independent reading of the linked JSON artifact.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (live_output): For the current head, the Windows deployment harness exercises real standalone and bundle installation to 2026.9.4.1000: two fresh installs and four upgrades report Ok, stable package family, and retained LocalState. The explicit contributor results and verified successful run resolve the previous rank-up request; the proxy prevented independent reading of the linked JSON artifact.
Evidence reviewed	10 items	Main still uses the previous policy: The fetched main policy assigns packageVersion 0.0.0.1 and payload 2026.8.2 explicitly; it does not contain the proposed Gateway-tag derivation. Latest published release: GitHub identifies v0.0.0.1, published September 15, as the latest release, targeting 3e5b1ff. Deterministic identity and signing validation: The helper reserves 1,000 revisions per Gateway sequence. Package composition, bundle composition, and signing validation use that identity; signing additionally requires the outer bundle version to equal the approved version.
Findings	None	None.
Security	None	None.

How this fits together

The packaging pipeline combines an approved OpenClaw payload with the Windows launcher to produce MSIX packages and bundles. Release policy supplies the identities checked before signing and publication.

flowchart TD
  A[Approved Gateway tag and commit] --> C[Derive release identity]
  B[Packaging revision] --> C
  C --> D[Build MSIX packages and bundle]
  D --> E[Fresh install and upgrade checks]
  D --> F[Validate official signing inputs]
  F --> G[Protected signing and release publication]

Loading

Before merge

None.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Install and upgrade acceptance	2 fresh installs; 4 retained-state upgrades	The current candidate covers both delivery formats and both published proof-release baselines.
Net line growth	Build/release code and configuration +252; tests and fixtures +575; documentation +57	Production growth implements shared version derivation and workflow wiring; most added lines establish acceptance coverage.

Technical review

Best possible solution:

Use one deterministic release identity throughout composition and signing, retaining the demonstrated proof-release transitions as the compatibility gate.

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

Not applicable: this proposes a release-version policy rather than reporting a reproducible runtime defect.

Is this the best way to solve the issue?

Yes. A shared derivation helper avoids competing version assignments, and the current-candidate acceptance results address the earlier upgrade concern.

AGENTS.md: not found in the target repository.

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

Labels

Label changes:

• remove merge-risk: 🚨 compatibility: Current PR review selected no merge-risk labels.

Label justifications:

• P2: Deterministic release identities are a bounded packaging improvement with demonstrated upgrade compatibility.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): For the current head, the Windows deployment harness exercises real standalone and bundle installation to 2026.9.4.1000: two fresh installs and four upgrades report Ok, stable package family, and retained LocalState. The explicit contributor results and verified successful run resolve the previous rank-up request; the proxy prevented independent reading of the linked JSON artifact.
• proof: sufficient: Contributor real behavior proof is sufficient. For the current head, the Windows deployment harness exercises real standalone and bundle installation to 2026.9.4.1000: two fresh installs and four upgrades report Ok, stable package family, and retained LocalState. The explicit contributor results and verified successful run resolve the previous rank-up request; the proxy prevented independent reading of the linked JSON artifact.

Evidence

What I checked:

• Main still uses the previous policy: The fetched main policy assigns packageVersion 0.0.0.1 and payload 2026.8.2 explicitly; it does not contain the proposed Gateway-tag derivation. (release-policy.json:3, e6cac4e1091f)
• Latest published release: GitHub identifies v0.0.0.1, published September 15, as the latest release, targeting 3e5b1ff. (3e5b1fff078e)
• Deterministic identity and signing validation: The helper reserves 1,000 revisions per Gateway sequence. Package composition, bundle composition, and signing validation use that identity; signing additionally requires the outer bundle version to equal the approved version. (scripts/Get-MSIXReleaseIdentity.ps1:55, b0bbae78871c)
• Current-candidate Windows acceptance: The contributor reports two successful fresh installs and four successful proof-release upgrades to 2026.9.4.1000, preserving LocalState and package family with status Ok: feat(ci): derive deterministic MSIX release versions #36 (comment). GitHub independently confirms run 35187010781 succeeded for the pinned head. (b0bbae78871c)
• Evidence artifact identity and inspection limit: GitHub confirms artifact 10483992717 belongs to the same run and head, with digest sha256:0a0ef9374ef835585102ae75b14ca52aa1ad515e6def2125c1b4729b3b5faed5. Downloading its ZIP was blocked at productionresultssa19.blob.core.windows.net by the proxy, so its JSON was not independently read; the assessment uses the explicit acceptance report, verified run, and inspected harness. (b0bbae78871c)
• Real deployment checks and prior fixes: The harness invokes Windows Add-AppxPackage, checks installed versions and status, and verifies a retained LocalState marker. It rejects pre-existing registrations before importing the certificate, guards cleanup with invocation ownership, and wraps package-query results as arrays. The workflow references the actual release-identity test filename, resolving the retained earlier findings. (scripts/Test-MSIXUpgrade.ps1:188, b0bbae78871c)

Likely related people:

• RomneyDa: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• paulcam206: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• xlinush: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; 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 (12 earlier review cycles; latest 8 shown)

• reviewed 2026-09-17T02:14:44.440Z sha 1575053 :: blocked before merge. :: none
• reviewed 2026-09-17T02:22:34.775Z sha 51c31d2 :: blocked before merge. :: [P1] [P1] Refuse pre-existing installations before upgrade-test cleanup | [P3] [P3] Match the actual release-identity test filename
• reviewed 2026-09-17T02:34:14.633Z sha 9bd9eb7 :: blocked before merge. :: [P2] [P2] Preserve package-query arrays across the function boundary
• reviewed 2026-09-17T02:59:41.214Z sha adefcce :: blocked before merge. :: none
• reviewed 2026-09-17T03:52:47.718Z sha b4a4b86 :: blocked before merge. :: none
• reviewed 2026-09-17T04:30:38.351Z sha b4a4b86 :: needs maintainer review before merge. :: none
• reviewed 2026-09-17T05:31:24.503Z sha 56de740 :: blocked before merge. :: none
• reviewed 2026-09-17T05:50:11.563Z sha b0bbae7 :: blocked before merge. :: none

[xlinush]

lgtm. cc @paulcam206

[RomneyDa]

@clawsweeper re-review

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

[RomneyDa]

Exact-head Windows acceptance evidence is now complete on b4a4b86990d79582133cf0df546a597adde5056a:

• Build and compatibility run 35179573458 is green.
• Fresh standalone x64 install: 2026.8.2.1000, package family OpenClaw.Gateway_kaa03rpbbqef6, status Ok.
• Fresh bundle install: 2026.8.2.1000, same package family, status Ok.
• v0.0.0.0 standalone → candidate: passed; LocalState retained.
• v0.0.0.1 standalone → candidate: passed; LocalState retained.
• v0.0.0.0 recommended bundle → candidate bundle: passed; LocalState retained.
• v0.0.0.1 recommended bundle → candidate bundle: passed; LocalState retained.

The JSON artifact openclaw-gateway-msix-upgrade-evidence is attached to that run with 90-day retention. All six scenarios report package family OpenClaw.Gateway_kaa03rpbbqef6 and status Ok.

@clawsweeper re-review

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

[RomneyDa]

Candidate-specific Windows acceptance is now complete on exact head b0bbae78871c730a13b98a9c53ace3f5b3aa4f6b.

• Run: https://github.com/openclaw/openclaw-windows-packaging/actions/runs/35187010781
• Evidence artifact: openclaw-gateway-msix-upgrade-evidence (artifact ID 10483992717)
• Candidate: 2026.9.4.1000
• Fresh installs: standalone ✅, bundle ✅
• Upgrades: v0.0.0.0 standalone ✅, v0.0.0.1 standalone ✅, v0.0.0.0 bundle ✅, v0.0.0.1 bundle ✅
• All four upgrades retained LocalState, preserved package family OpenClaw.Gateway_kaa03rpbbqef6, and finished with status Ok.

The full host suite, pinned v2026.9.4 payload build, x64/ARM64 MSIX composition, bundle composition, acceptance matrix, and aggregate CI are green on the same head.

@clawsweeper re-review

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