[RomneyDa]

What Problem This Solves

Gateway MSIX builds were pinned to 2026.9.5 while Store and official publication still required the approved 2026.9.4 commit. Operators could not publish the current stable Gateway without editing version-specific policy fields.

User Impact

New builds and manually dispatched Store/official releases follow the moving Gateway stable channel (openclaw@latest), not a fixed 2026.9.7 pin. Publication modes accept an empty openclaw_ref or a full SHA matching the captured stable release. A full SHA remains an assertion, never an arbitrary source override. Publication remains manual and restricted to main.

The release trust decision deliberately changes from a separately reviewed upstream commit to the stable release captured by that workflow run, as explicitly requested by the operator for both default builds and official publication. Exceptional reviewed stableVersion pins remain supported. MSIX rebuild revision resets to zero for the new Gateway train; package-only rebuilds still need a revision increment.

Why This Change Was Made

Remove static source approval fields and use the existing immutable source snapshot throughout authorization. The signing validator restores the same-run artifact and verifies run ID, packaging commit, signing mode, and channel provenance before checking package identities, payload commits/versions, hashes, inventories, and bundle contents. Retries never re-resolve latest.

Migrate launcher build metadata and the runtime proof fixture off the removed pins; packaged builds retain their supplied identity, while ordinary builds report unknown for unspecified payload identity. Update release documentation.

Built on merged #138. The separate signature-restoration PR #139 would independently restore rejection of unsigned stable tags.

Evidence

Current head: 748227a, rebased onto main 7d7acad (#141). Source/signing tests below were run on 2b00cb3; the follow-up changes only fixture metadata path containment.

• 48 source-resolution tests passed, including stable advancement, immutable replay, matching full-SHA assertions and mismatched/tag/branch input rejection, and channel provenance. The advancing-stable regression fails at static approval on the prior implementation.
• Signing-input, workflow-signing configuration, and MSIX release-identity suites passed. Signing tests reject missing/foreign snapshots and mismatched package inputs.
• Live authenticated official-mode source resolution and replay selected v2026.9.7 at c074824a27c96d3983043f9eeb33823cd1772d8c and derived MSIX 2026.9.700.0. This was read-only upstream; no signing or publication occurred.
• MSBuild property evaluation verified unknown local defaults and explicit packaged identity. JavaScript syntax, documentation references, and git diff --check passed.
• Independent autoreview found no actionable P0/P1 issues.
• Full .NET quality was attempted but blocked on macOS by NETSDK1100 (Windows targeting). Windows build/NativeAOT, real runtime proof, MSIX installation/upgrade, and signing/publication were not run locally; Windows CI remains required.

Review feedback and CI repair

• Preserve full-SHA dispatch: a matching stable SHA is accepted at initial selection, replay, and final signing-input validation. Nonmatching SHAs fail before source snapshot creation or package authorization; branches/tags fail before source HTTP requests. Offline signing-input fixtures exercise the actual validator and retain missing/foreign snapshot, wrong payload, and integrity rejection coverage.
• Dynamic stable publication is the explicitly requested policy, including the already merged unsigned-tag admission change. Adding another per-release commit approval would restore the bottleneck this PR is intended to remove. Main-only manual dispatch and the separate protected signing environment remain in place.
• Snapshot replay intentionally preserves the admitted source. A later upstream channel change or tag deletion is not an automatic revocation signal. Operators must stop a run whose captured release should not be published; this is now explicit in the release guide. No new live withdrawal/revocation mechanism is claimed.
• Prior Windows CI completed .NET static analysis successfully and passed 1,274 of 1,275 tests. The one failure searched the whole version output twice when both values were unknown. The repaired test scopes both Package and Payload rows and checks the ANSI transition at each parenthetical commit, preserving the style contract. The fresh Windows host job passed, including static analysis, managed tests, NativeAOT CLI proof, and PowerShell policy suites: run 36805244776. Both architecture builds and bundles also passed on that head; its upgrade lane was superseded by the fixture-fix pushes. Exact-head CI is rerunning.

ClawSweeper revision 2 for head 2b00cb3b9fbdd9faa6dbf9deed6276c289fe26cc confirms the full-SHA finding is resolved and reports no actionable code or security findings. Its remaining compatibility qualification request is tracked by the ongoing Windows package build/upgrade lanes and the documented release proof requirements.

CodeQL repair (92fa7ae): the runtime fixture accepts the prepared payload root, validates normalized metadata and application child paths before filesystem access, and rejects symlinked metadata. The PowerShell entry point retains its application-directory parameter and checks the expected app layout. Focused local probes verified regular metadata, escaping-symlink rejection, payload-root forwarding, and invalid-layout rejection. JavaScript syntax, diff checks, and independent P0/P1 review passed. All three CodeQL analyses and the aggregate check passed on pre-rebase head 92fa7ae, with no open branch scanning alerts. That head also passed host, architecture builds, bundles, and the identity-reset scenario; the remaining serial upgrade scenarios were superseded by this rebase.

Rebase validation: only docs/release-process.md conflicted. Preserved main's parallel upgrade matrix and current Store-baseline behavior. Git range-diff confirms the PR code patches are unchanged. Workflow signing configuration, upgrade matrix tests, documentation references, and diff checks pass after rebase. Fresh CI uses main's parallel upgrade scenarios.

[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 30, 2026, 11:04 PM ET / October 1, 2026, 03:04 UTC (Revision 4).

ClawSweeper review

What this changes

The branch makes MSIX publication follow a captured stable Gateway release and updates signing validation, launcher metadata, runtime fixtures, tests, and release guidance.

Merge readiness

⛔ Blocked before merge - 2 items remain

The publication change remains necessary: current main still requires fixed release approval fields. No actionable patch defect was found, but the previously requested package and runtime qualification remains incomplete.

Priority: P2
Reviewed head: 92fa7ae0c1363d422ae2653dabb7a9af0d2f903c

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	The coordinated patch has no actionable findings and strong focused validation, with captured-payload compatibility qualification still outstanding.
Proof confidence	🌊 off-meta tidepool	Not applicable: The MEMBER-authored PR is exempt from ordinary contributor proof. Its body reports live official-mode source selection and replay, while exact-head Windows policy and NativeAOT steps pass; installed-upgrade and separate prepared-runtime request-boundary qualification remain compatibility work. No stored-data format changes.
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 ordinary contributor proof. Its body reports live official-mode source selection and replay, while exact-head Windows policy and NativeAOT steps pass; installed-upgrade and separate prepared-runtime request-boundary qualification remain compatibility work. No stored-data format changes.
Evidence reviewed	10 items	Current main still needs this change: Main retains stableVersion 2026.9.5 alongside approval for Gateway 2026.9.4, commit 3a9d69db306cd7f081e06254cb89c4bcc14a7107, and MSIX revision 6. The latest published release remains v2026.9.4-msix.6 at f2f4930. Release provenance check: GitHub reports v2026.9.4-msix.6 as the latest release, published September 30, 2026. No merged related PR implements the moving-stable publication change. Full-SHA finding resolved: Publication resolves the stable channel even when a full SHA is supplied, then checks that assertion against the captured commit. Replay validates the workflow run, packaging commit, signing mode, and channel provenance without resolving latest again. Matching, mismatched, override, and foreign-snapshot cases exercise the production scripts.
Findings	None	None.
Security	None	None.

How this fits together

The Windows packaging workflow selects upstream OpenClaw, builds x64 and ARM64 packages, and validates them before signing or retaining Store submission assets. The captured source snapshot now supplies the release identity throughout that process.

flowchart LR
  A[Stable release and dispatch input] --> B[Capture immutable source]
  B --> C[Build Windows packages]
  B --> D[Validate release inputs]
  C --> D
  D --> E[Protected signing]
  D --> F[Store submission bundle]
  E --> G[GitHub release]

Loading

Before merge

• Resolve merge risk (P1) - Replacing the qualified fixed payload with moving stable selection can expose installed users to runtime or upgrade incompatibility. Completed fresh-install, LocalState-retention upgrade, and Gateway request-boundary evidence identifying the captured payload remains unavailable.
• Complete next step (P2) - Retain completed fresh-install and LocalState-retention upgrade evidence and separate Gateway request-boundary results for the captured payload.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Production and test LOC	production +17 net, tests +66 net; documentation +10 net	Production growth supports snapshot-based authorization and payload-aware proof while removing static metadata fallback logic.

Merge-risk options

Maintainer options:

1. Complete captured-payload qualification (recommended)
   Retain the Windows fresh-install and state-retention upgrade artifacts and the separate Gateway request-boundary results for the captured payload before landing.

Technical review

Best possible solution:

Keep one immutable stable-source snapshot throughout publication, with package upgrade and runtime qualification tied to its exact payload commit.

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

Not applicable to this publication-policy improvement; current main's fixed approval fields and the introduced resolver changes establish the before/after behavior from source.

Is this the best way to solve the issue?

Yes, reusing the existing immutable source owner avoids competing release identity logic; qualification must still establish compatibility for the selected payload.

AGENTS.md: found and applied where relevant.

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

Labels

Label changes:

No label changes.

Label justifications:

• P2: This is a bounded publication improvement with release qualification concerns, without evidence of an urgent deployed regression.
• merge-risk: 🚨 compatibility: Moving stable selection replaces a fixed qualified payload, and captured-payload runtime and installed-upgrade qualification remains incomplete.
• 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 ordinary contributor proof. Its body reports live official-mode source selection and replay, while exact-head Windows policy and NativeAOT steps pass; installed-upgrade and separate prepared-runtime request-boundary qualification remain compatibility work. No stored-data format changes.

Evidence

What I checked:

• Current main still needs this change: Main retains stableVersion 2026.9.5 alongside approval for Gateway 2026.9.4, commit 3a9d69db306cd7f081e06254cb89c4bcc14a7107, and MSIX revision 6. The latest published release remains v2026.9.4-msix.6 at f2f4930. (release-policy.json:3, 11f19be0e863)
• Release provenance check: GitHub reports v2026.9.4-msix.6 as the latest release, published September 30, 2026. No merged related PR implements the moving-stable publication change. (f2f4930d858f)
• Full-SHA finding resolved: Publication resolves the stable channel even when a full SHA is supplied, then checks that assertion against the captured commit. Replay validates the workflow run, packaging commit, signing mode, and channel provenance without resolving latest again. Matching, mismatched, override, and foreign-snapshot cases exercise the production scripts. (scripts/Get-WorkflowSource.ps1:17, 92fa7ae0c136)
• Authorization reaches the signing boundary: The signing validator replays the same-run snapshot and checks both architecture packages, identities, inventories, hashes, and bundled bytes. The workflow requires successful authorization before Azure login, retains main-only manual publication, and preserves the protected release-signing environment. No concrete unauthorized final-effect path was found. (scripts/Test-SigningInputs.ps1:192, 92fa7ae0c136)
• Qualification remains source-specific: The release guide requires current-source upgrade evidence when stable advances. Local development guidance separately requires repeating the request-boundary proof when the runtime changes. The fixture executes prepared app/openclaw.mjs, checks its identity against payload metadata, and observes actual requests through compaction and plugin opt-outs; therefore upstream runtime compatibility is an affirmative dependency of this qualification claim. (docs/local-development.md:386, 92fa7ae0c136)
• Exact-head validation progress: Run https://github.com/openclaw/openclaw-windows-packaging/actions/runs/36808241764 had completed static analysis, managed tests, NativeAOT CLI execution, signing policy, source-selection, and release-identity steps successfully. Both expanded payload builds succeeded, but package composition and the subsequent installed-upgrade lane were unfinished. The workflow does not invoke the separate Gateway request-boundary fixture. (.github/workflows/gateway-msix.yml:793, 92fa7ae0c136)

Likely related people:

• RomneyDa: 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)
• paulcam206: 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.

• Retain completed Windows fresh-install and LocalState-retention upgrade evidence, plus Gateway request-boundary results identifying the captured payload.

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 (3 earlier review cycles)

• reviewed 2026-10-01T02:01:41.320Z sha 64cfb87 :: needs real behavior proof before merge. :: [P1] Preserve the documented full-SHA release dispatch path
• reviewed 2026-10-01T02:24:01.291Z sha 2b00cb3 :: blocked before merge. :: none
• reviewed 2026-10-01T02:31:14.535Z sha 2b00cb3 :: blocked before merge. :: none