chore: experiment with trimmed winnode publishing

[shanselman]

What Problem This Solves

This draft explores whether the standalone winnode CLI can be safely tree-trimmed before we decide to distribute it independently. Today, winnode is not included in the GitHub release installer or portable ZIP, so this experiment does not reduce current OpenClaw Companion release assets.

Why This Change Was Made

The experiment enables conservative partial trimming for winnode while copying OpenClaw.Shared.dll unchanged. It removes the CLI's reflection-based JSON pretty-print call and adds an independent x64/ARM64 CI job that publishes the trimmed CLI, verifies the Shared assembly remains byte-identical, and smoke-runs the executable.

The WinNode CI job is separate from Tray artifact publishing and is not a dependency of the release job. This PR intentionally does not trim or otherwise alter the Tray application.

User Impact

No current user-visible impact. This is an experiment for a possible future standalone winnode distribution.

Measured standalone x64 output:

Variant	Folder	ZIP
Self-contained, untrimmed	115.73 MiB	50.87 MiB
Self-contained, partial trim	60.24 MiB	25.56 MiB
Savings	55.49 MiB (47.9%)	25.31 MiB (49.8%)

Latest GitHub release v0.6.12 remains unchanged: x64 installer 114.12 MiB, ARM64 installer 99.90 MiB, x64 ZIP 141.64 MiB, ARM64 ZIP 133.04 MiB.

Evidence

• x64 trimmed publish: 60.24 MiB, 112 files, winnode.exe --help exited 0.
• ARM64 trimmed publish: 61.71 MiB, 112 files, winnode.exe --help exited 0 on an ARM64 host.
• OpenClaw.Shared.dll SHA-256 matched its pre-link build output immediately after both publish sequences.
• Publish completed with trim diagnostics treated as errors; no trim warnings were suppressed.
• Final rubber-duck review found no blocking or non-blocking issues after the WinNode CI gate was separated from Tray publishing.

Change Type

• Bug fix
• Feature
• Refactor
• Docs or instructions
• Tests or validation
• Security hardening
• Chore or infrastructure

Scope

• Tray or WinUI UX
• Windows node capability
• Local MCP or winnode
• Gateway, connection, or pairing
• Setup or onboarding
• Permissions, privacy, or security
• Tests, CI, or docs

Validation

• ./build.ps1 — passed; Shared, CLI, WinNode CLI, SetupEngine, and WinUI built successfully for win-arm64.
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore — 2,863 passed, 31 skipped, 0 failed.
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore — 1,717 passed, 0 failed.
• dotnet test ./tests/OpenClaw.WinNode.Cli.Tests/OpenClaw.WinNode.Cli.Tests.csproj --no-restore — 127 passed, 0 failed.
• dotnet publish ./src/OpenClaw.WinNode.Cli/OpenClaw.WinNode.Cli.csproj -c Release -r win-x64 --self-contained true — passed; Shared hash matched; --help passed.
• dotnet publish ./src/OpenClaw.WinNode.Cli/OpenClaw.WinNode.Cli.csproj -c Release -r win-arm64 --self-contained true — passed; Shared hash matched; --help passed.

Real Behavior Proof

• Environment tested: Windows 11 ARM64, .NET SDK 10.0.302; x64 publish exercised under Windows emulation and ARM64 publish exercised natively.
• PR head or commit tested: af85963f
• Exact steps or command run: publish each RID self-contained, compare SHA-256 of built and published OpenClaw.Shared.dll, then run the published winnode.exe --help.
• Evidence after fix: x64 60.24 MiB; ARM64 61.71 MiB; hash comparisons true; both executables exited 0.
• Observed result: conservative trimming removes about 48% of the standalone folder while preserving Shared byte-for-byte.
• Screenshot or artifact links verified? N/A
• Not verified or blocked: no live isolated-Tray MCP roundtrip was available locally. Before promotion from experiment, test the published binary on a clean second machine with no .NET SDK/runtime, run winnode --list-tools, and invoke a safe command such as system.which against an isolated Tray profile.

Security Impact

• New permissions or capabilities? No
• Secrets or tokens handling changed? No
• New or changed network calls? No
• Command or tool execution surface changed? No
• Data access scope changed? No
• If any answer is Yes, explain the risk and mitigation: N/A

Compatibility and Migration

• Backward compatible? Expected yes; still experimental pending clean-machine proof.
• Config or environment changes? No
• Migration needed? No
• If yes, list the exact upgrade steps: N/A

Experiment Risks

• The preservation hook attaches to the SDK-private _ComputeManagedAssemblyToLink target; a future SDK update could change that ordering. CI therefore verifies OpenClaw.Shared.dll byte-for-byte on both RIDs.
• Existing unit tests execute the normal test assembly, not every path through the published executable.
• Future winnode code that calls additional Shared functionality may require new published-binary tests.
• The CLI still carries speech/ONNX/native assets inherited from OpenClaw.Shared; trimming does not solve that dependency-boundary problem.
• The structured autoreview helper could not run because its secret scanner treated the existing OPENCLAW_MCP_TOKEN identifier in Program.cs as secret-like content. No secrets were added or changed.

Second-Machine Test Plan

1. Download or build the x64/ARM64 publish-winnode output on a clean Windows machine without the .NET runtime installed.
2. Run winnode.exe --help.
3. Launch the Tray with isolated data and enable Local MCP Server.
4. Set OPENCLAW_TRAY_DATA_DIR to that isolated profile.
5. Run winnode.exe --list-tools.
6. Run winnode.exe --command system.which --params '{"bins":["git","node","powershell"]}'.
7. Confirm output and exit codes match an untrimmed publish.

Review Conversations

• I replied to or resolved every bot review conversation addressed by this PR.
• I left unresolved only conversations that still need maintainer judgment.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 16, 2026, 4:34 PM ET / 20:34 UTC.

Summary
The draft PR enables partial trimming for standalone winnode, preserves OpenClaw.Shared.dll unchanged, replaces reflection-based JSON formatting, and adds x64/ARM64 publish smoke validation.

Reproducibility: not applicable. This PR is a packaging and CI experiment rather than a report of broken existing behavior.

Review metrics: 3 noteworthy metrics.

• Standalone size: 47.9% folder reduction; 49.8% ZIP reduction. The reported packaging benefit is substantial enough to justify completing the runtime proof.
• Publish matrix: 2 architectures added. The new x64 and ARM64 job becomes ongoing CI surface and runner cost.
• Patch scope: 4 files; 125 additions, 1 deletion. The experiment is bounded and does not alter current Tray release artifacts.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦐 gold shrimp
Patch quality: 🐚 platinum hermit
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Post redacted x64 and ARM64 clean-machine output for winnode --list-tools and one safe command against an isolated Tray profile.

Proof guidance:

• [P1] Needs stronger real behavior proof before merge: Dual-architecture publish sizes, hashes, and --help exits are useful live output, but add redacted clean-machine --list-tools and safe command output from the trimmed binaries; updating the PR body should trigger re-review, or a maintainer can comment @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

• [P1] The published executable has only been smoke-tested with --help; trimming could still break MCP discovery or command execution paths that load Shared dependencies at runtime.
• [P1] The preservation mechanism attaches to the SDK-private _ComputeManagedAssemblyToLink target, so a future .NET SDK update could invalidate the hook and make the new CI job fail until maintainers update it.

Maintainer options:

1. Prove the published CLI before merge (recommended)
   Add clean-machine x64 and ARM64 --list-tools plus safe command evidence, then retain the hash and startup checks as the permanent CI gate.
2. Pause the experiment
   Close or defer the draft if maintainers do not want to own an SDK-private trimming hook and a permanent dual-architecture CI job before standalone distribution is approved.

Next step before merge

• [P1] Keep the draft in human review until the contributor supplies live trimmed-binary MCP proof; there is no concrete code defect suitable for automated repair.

Security
Cleared: The diff adds no new dependency source, secret access, workflow permission, network endpoint, or command capability, and reuses existing action families.

Review details

Best possible solution:

Retain the isolated partial-trim design only if clean-machine x64 and ARM64 runs prove --list-tools and a safe command against an isolated Tray profile, then keep the hash assertion as an SDK-drift guard.

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

Not applicable: this PR is a packaging and CI experiment rather than a report of broken existing behavior.

Is this the best way to solve the issue?

Unclear: conservative partial trimming with a byte-identical Shared assembly is a reasonable boundary, but --help alone does not validate the real MCP paths that the standalone binary exists to run.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against e0afbc425fb7.

Label changes

Label changes:

• add P3: This is a low-urgency packaging and CI experiment with no current user-visible release impact.
• add merge-risk: 🚨 automation: Merging adds a permanent dual-architecture CI job whose correctness depends on an acknowledged SDK-private linker target.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🐚 platinum hermit.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: Dual-architecture publish sizes, hashes, and --help exits are useful live output, but add redacted clean-machine --list-tools and safe command output from the trimmed binaries; updating the PR body should trigger re-review, or a maintainer can comment @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Label justifications:

• P3: This is a low-urgency packaging and CI experiment with no current user-visible release impact.
• merge-risk: 🚨 automation: Merging adds a permanent dual-architecture CI job whose correctness depends on an acknowledged SDK-private linker target.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: Dual-architecture publish sizes, hashes, and --help exits are useful live output, but add redacted clean-machine --list-tools and safe command output from the trimmed binaries; updating the PR body should trigger re-review, or a maintainer can comment @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Current-main comparison: Current main still uses JsonSerializer.Serialize for PrettyPrint and does not contain the trimming configuration, so this PR provides unique work rather than duplicating an existing implementation. (src/OpenClaw.WinNode.Cli/Program.cs:459, e0afbc425fb7)
• Trim boundary: The branch enables partial trimming while setting PostprocessAssembly=false for OpenClaw.Shared; the PR reports byte-identical Shared hashes on both target architectures. (src/OpenClaw.WinNode.Cli/OpenClaw.WinNode.Cli.csproj:8, af85963fe755)
• Automation scope: The branch adds a separate two-RID WinNode publish job that is independent of Tray publishing and smoke-runs only winnode.exe --help. (.github/workflows/ci.yml:528, af85963fe755)
• Repository proof policy: The full AGENTS.md requires WinNode and MCP changes to prove discovery and invocation with winnode --list-tools plus winnode --command ..., while this PR explicitly says that roundtrip was not verified. (AGENTS.md:58, e0afbc425fb7)
• Feature provenance: Repository release history identifies the original winnode CLI feature as merged through feat: winnode CLI for invoking node commands over local MCP #250, which is the strongest available routing signal for the affected code. (src/OpenClaw.WinNode.Cli/Program.cs:1)

Likely related people:

• codemonkeychris: Repository release history credits the merged winnode CLI feature to feat: winnode CLI for invoking node commands over local MCP #250, making this the strongest current-main ownership signal. (role: feature introducer; confidence: high; files: src/OpenClaw.WinNode.Cli/Program.cs, src/OpenClaw.WinNode.Cli/OpenClaw.WinNode.Cli.csproj, tests/OpenClaw.WinNode.Cli.Tests)
• shanselman: Prior merged release history shows repeated work on Windows CI, ARM64 runners, NuGet caching, and WinNode performance, so this person is relevant to the packaging experiment beyond authoring this PR. (role: recent adjacent contributor; confidence: medium; files: .github/workflows/ci.yml, src/OpenClaw.WinNode.Cli/Program.cs)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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.

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.