[v0.5.0] Windows team: build, upload and native run (not yet certified)

@kurtatwork

Team: Windows team (@kurtatwork, @RDCTart69). Hub: see the v0.5.0 release alignment issue linked below. Windows ships in 0.5.0 as a downloadable, not-yet-certified build: on the mirror and the website, no in-app updater entry (manual installer only).

Review the Windows pieces already merged on release/0.5.0-hermes-upskill: the NSIS pre-install hook that stops this installation's own sidecars (SCL-S0.5 + S0.7 + S1.6a: shutdown coverage, Windows installer stops own sidecars, Windows CI job #255) and the Windows CI job; comms IPC timeouts (fix(windows): comms IPC sets socket timeouts best-effort (named pipes reject them) #180).
D4 Build the Windows x64 NSIS installer from the release head the Mac lane tags v0.5.0-rc (docs/RELEASE_WINDOWS.md), including the Windows sidecars built from citrate-chain 2979a157 and runtime main. Authenticode-sign it if the certificate is available; if not, ship unsigned and tell us so the website notes the SmartScreen prompt.
Name it Citrate-Core-windows-x86_64-setup.exe, post its sha256, and upload it to the GitHub release (or hand it to the DGX for the mirror).
C4 Native run ([SCL v0.5.0] S0 pre-cut safety: Windows native run of the installer fix (S0.7) #249): a machine running 0.4.2 with the app and Hermes open, run the 0.5.0 installer; confirm no locked-file errors, the old sidecars are stopped, 0.5.0 launches, the node resets its old chain DB (keys kept) and syncs on the new chain. Attach the before/after process lists from the steps in SCL-S0.5 + S0.7 + S1.6a: shutdown coverage, Windows installer stops own sidecars, Windows CI job #255.
Report on [SCL v0.5.0] S0 pre-cut safety: Windows native run of the installer fix (S0.7) #249 and tick here.

🤖 Generated with Claude Code

https://claude.ai/code/session_018wWZZ8GRVU9USh3kKQHsFe

Hub: #266 (definition of done, sequence, status).

Windows D4 alignment check — 2026-10-06

I reviewed the live release inputs before starting the Windows build.

Satisfied prerequisites

release/0.5.0-hermes-upskill currently resolves to verified commit 98c846aedd615042b795b130a079955a793babdc.
The release line contains the merged comms IPC timeout work from fix(windows): comms IPC sets socket timeouts best-effort (named pipes reject them) #180: merge commit 30c789e844ae98f9e4730012ae7d1c6f8fb75b98 is an ancestor of the current release head.
The NSIS pre-install hook from SCL-S0.5 + S0.7 + S1.6a: shutdown coverage, Windows installer stops own sidecars, Windows CI job #255 is merged, and docs/RELEASE_WINDOWS.md defines the required artifact name and manual-install/no-updater behavior.
The required chain provenance commit exists as CitrateNetwork/citrate-chain@2979a1576d12dc75375ae30be5c37a2cdd866c87.

Current D4 blockers

No v0.5.0-rc tag or GitHub release exists in citrate-core, so there is not yet an immutable source ref from which to build D4.
This issue says runtime main, but does not identify an exact citrate-agent-runtime commit. The release branch's eval/sidecar-runtime.rev currently pins 45fceda902dcaaec29060a82ffeba705dc12b0a6, but that file documents the eval-suite sidecar pin rather than explicitly declaring the D4 release artifact input.

Release-owner decision requested

Please confirm the authoritative exact citrate-agent-runtime SHA for the Windows release artifact and create/announce v0.5.0-rc when the release gates are ready. I will build from that immutable tag and exact pin rather than from moving branches.

No installer has been built or published yet, and no checkbox is being marked complete. Authenticode availability will be checked at build time; if the certificate is unavailable, the artifact will be reported explicitly as unsigned so the website can warn about SmartScreen.

C4 host readiness — additional blocker

Non-destructive inspection of the available Windows host found:

Windows 10 Home 22H2 (10.0.19045), x64.
Citrate Core is installed and running from %LOCALAPPDATA%\Citrate Core, but the installed version is 0.4.3, not the required 0.4.2 baseline.
The app, node, IPFS, and memory sidecars are running. No Hermes process was visible, so the required “app and Hermes open” starting state is not established.
Only 4.61 GiB is currently free on C:; this host is not ready for a fresh release build without additional workspace capacity or cleanup.
No usable local Authenticode code-signing certificate and no signtool.exe were detected. Unless signing is provided elsewhere, D4 must be reported and shipped as unsigned with the SmartScreen warning.
The public citrate-core v0.4.2 release contains only macOS assets, and no 0.4.2 Windows installer was found in this host's Downloads folder.

C4 blocker: please provide an authoritative 0.4.2 Windows installer/artifact and its provenance, or designate a Windows machine that already has the required 0.4.2 app/Hermes baseline. I will not destructively replace this working 0.4.3 installation or claim its process snapshot as the required C4 “before” evidence.

Windows D4 MSVC blocker (runtime pin c2f394c) The exact pinned citrate-agent-runtime commit c2f394c973a617c8144fd0bca7821c13e882d365 does not build agent-sidecar for x86_64-pc-windows-msvc. cargo +1.98.1 build --release --locked -p agent-sidecar --target x86_64-pc-windows-msvc reaches citrate-agent-shell, then fails with 11 Windows compile errors: std::os::unix imports are unconditional; libc::pid_t/kill/SIGKILL are unavailable; and Unix-only mode/process_group/signal APIs are called. I did not patch the tagged source, swap the runtime pin, or insert a stub. Other exact-pin Windows builds completed for node-agent, cluster-daemon, comms-member-daemon, and mem-mcp; chain is next. Please provide an owner-approved Windows-capable runtime commit/tag or disposition for the RC build.

Windows D4 progress: 7/8 sidecars ready The exact citrate-chain 2979a157 node now builds on MSVC. The initial vendored OpenSSL failure was caused by the long Cargo target path/Perl environment; a short target mapping plus explicit native Strawberry Perl and VS 2022 x64 environment completed the locked release build. Chain lineage constants were both 0 before build. Windows SHA-256: citrate.exe 4dd5c793ea19400c5777e5281f73784b95a979970877e1a06fc2cf20421b69c3. The other completed exact-pin hashes are node-agent 79f9c652f887fc8ea97f095427570a33465ae2f43d929bb9de4689903d09244e, mem-mcp d86f532c188a7ca9479a7d58a56fb6a56b8862274a1475fad675d8804d322c81, comms-member-daemon 630a912ec0e960f50b51fee1340a49b960d21a44afe0fe5d3ae24cbb25c20b4d, cluster-daemon a630dda936d1335cb8421b9b087576a7d80976d76b6528d650f8f75e0383227c. llama.cpp b10909 is staged. The old runtime-deps Windows ipfs asset identifies as Kubo 0.32.1, so it was rejected; official Kubo 0.42.0 from ipfs/kubo v0.42.0 was SHA-512 verified and staged (ipfs.exe SHA-256 9e63e925e3ee0697446448b119f47d731b7ee55ce74e4c53d7d2b647bb3a9f56). Remaining sidecar: Hermes from runtime #72 after approval/merge and rc.2 pin.

@kurtatwork

[Mac → Windows] D4 final: build from `v0.5.0-rc.2`

@kurtatwork, runtime #72 is merged. The Windows-capable runtime pin is citrate-agent-runtime 626486b8a7db0ab85cbe62f8a251abfd30677c3d, tagged in core as v0.5.0-rc.2 (ca18684e).

Build the remaining Hermes sidecar: cargo +1.98.1 build --release --locked -p agent-sidecar --target x86_64-pc-windows-msvc at 626486b8. Invites: direct invite = self-admit (token is standing approval; relay auto-completes when acceptee is offline) #72's windows-latest CI job builds exactly this.
Your other 7 exact-pin sidecars (posted above) are still the right inputs: citrate 2979a157, node-agent, mem-mcp, comms, cluster, Kubo 0.42.0, llama.cpp b10909.
Produce the x64 NSIS installer from the tag. Unsigned is OK; say so, and the website will note the SmartScreen prompt. Name it Citrate-Core-windows-x86_64-setup.exe and post its sha256, plus the Windows Hermes sha256.
Note in the evidence that Hermes shell runs which require a sandbox are refused on Windows. That is intended for 0.5.0.

`v0.5.0-rc.2` is tagged: final build inputs (all platforms)

Tag: v0.5.0-rc.2 (annotated, SSH-signed by Larry Klosowski; tag object 0cb3e924633eb8565848045003c1d84cf5357fd1)
Commit: ca18684edd234d53578863093cd54a9908e7d026, the head of release/0.5.0-hermes-upskill after release(rc.2): pin citrate-agent-runtime 626486b8 (#72) for Hermes; record gates #273. The only change from 2d3de50 is docs (runtime pin + gates recorded in SCL-S0 EVIDENCE.md, "v0.5.0-rc.2").
No GitHub release was created.

Source revisions (build every sidecar from exactly these)

Component	Source	Rev
node (`citrate`)	citrate-chain	`2979a1576d12dc75375ae30be5c37a2cdd866c87` (G; fingerprint `0x0daa463069843ea3884371baf903ddf7`, genesis `1dcfc4909dd9fdcb…`)
hermes (`agent-sidecar`)	citrate-agent-runtime	`626486b8a7db0ab85cbe62f8a251abfd30677c3d` (#72 merge, Windows agent-shell; one pin for every OS)
mem-mcp	citrate-memories	`0e9d488` (`--features rocksdb,transformer`, implements `import-corpus`)
comms-member-daemon	citrate-comms	`9cd12c4`
cluster-daemon	citrate-cluster	`755cf21`
node-agent	citrate-node-agent	`1d8cb8e`
ipfs	Kubo	`0.42.0` (official ipfs/kubo release, verify upstream digest)
llama-server + runtime	llama.cpp	macOS: the llama.cpp build staged for 0.4.x (libllama 0.4.0 / ggml 0.23.0, unchanged); BGE GGUF converter tag `b8640`; Windows: `b10909` as staged on #263. Build with `-DLLAMA_BUILD_WEBUI=OFF` where you build from source (licences.json gap)

Hermes from 626486b8 on macOS arm64 (scripts/build-hermes.sh, --locked, stripped): 3d68420d08ddc3e2d4aa9eeee293e785e834de1ed8b22a3682c36eaa049af99e.

`runtime-deps` assets (pinned in `src-tauri/runtime-deps.sha256` at the tag)

91de29274251aa0e7d0934ebb2e2c8b3ebf3d010804ed6a798eef8c4655acd9b  knowledge-corpus.tar.gz      (bundle_digest 815eda93…754b9a, 32,754 nodes)
ea95d49d2a01e1ff8f4d161413bca7746712dac36aa99f79b85ebc3ee9561cb0  skills-bundle.tar.gz
fa9e1f6c0109aa2507a09d97d02aad84774d5b2ba6d3199f7af7e0fba4c6eaee  bge-base-en-v1.5-f16.gguf
cea05ebe680cf315e41c965caec9d8e009dd9085b622d4cb9c62fe4faf026c3b  bge-base-en-v1.5.tar.gz      (model.safetensors c7c1988a…)
9ad56eda5af2dbdd8f1bef44a890f3adb23cdcfba4c75774bb72ea47763736e8  citrate-aarch64-apple-darwin
315984355eb9652118c457248d907661f877d8516f7fe0193f01dc85e29bf8e6  mem-mcp-aarch64-apple-darwin
2435a484c54deb2d7c93180d3a8c1534cc68ec825b24719829139e1d3af177c7  node-agent-aarch64-apple-darwin
ff931bc315f7cea369ad7d0b25024311df8c3e3352c1273f17abf7953c8ea2d4  llama-server-aarch64-apple-darwin

Freshly downloaded today, all 8 pass scripts/ci/verify-runtime-deps.sh.

Staging (from the tag, on every platform)

Build or stage the platform sidecars from the revisions above. Hermes must come from 626486b8.
Hermes resources: skills-bundle.tar.gz → node scripts/stage-skills-bundle.mjs from-tarball <tar>, and the GGUF → src-tauri/models/bge-base-en-v1.5-gguf/.
Step 2b (docs/RELEASE_LINUX.md / docs/RELEASE_WINDOWS.md):
- download bge-base-en-v1.5.tar.gz and knowledge-corpus.tar.gz, then scripts/ci/verify-runtime-deps.sh src-tauri/runtime-deps.sha256 "$DL" bge-base-en-v1.5.tar.gz knowledge-corpus.tar.gz;
- extract the full BGE (config, tokenizer, model.safetensors) into src-tauri/models/bge-base-en-v1.5/;
- node scripts/stage-knowledge-corpus.mjs "$DL/knowledge-corpus.tar.gz" --bge-dir src-tauri/models/bge-base-en-v1.5 --mem-mcp src-tauri/binaries/mem-mcp-$TRIPLE (your platform's mem-mcp, no --allow-* flag).
Immediately before tauri build: node scripts/check-staged-corpus.mjs --pins src-tauri/runtime-deps.sha256. It must exit 0.

🤖 Generated with Claude Code

https://claude.ai/code/session_018wWZZ8GRVU9USh3kKQHsFe

@kurtatwork

@kurtatwork: please build the final installer from v0.5.0-rc.3 (coming soon; only core changes vs rc.2). Sidecar builds at the rc.2 inputs stay valid.

@kurtatwork

@kurtatwork Windows rebuild for rc.3. The inputs are below; only citrate-core changed since rc.2.

v0.5.0-rc.3 cut: inputs (Mac lane)

Tag: v0.5.0-rc.3 (signed annotated) → commit 02cc32814e58af4f9b384b1b2136e67c50e26495, the merge of #275 on release/0.5.0-hermes-upskill.

Only citrate-core changed. #275 fixes C3 findings 1 and 2:

Quitting now stops the mem-mcp import-corpus importer: SIGTERM, then SIGKILL after 5 s, then reaped.
An interrupted import continues on the next launch and skips the corpus tenants that already finished.
The genesis-reset log line now lists the removed and kept files correctly.

Every other input is identical to rc.2:

Input	Pin
citrate-agent-runtime (Hermes)	`626486b8`
citrate-chain (node)	`2979a157`
citrate-memories (mem-mcp)	`0e9d488`
citrate-comms (comms-member-daemon)	`9cd12c4`
citrate-cluster (cluster-daemon)	`755cf21`
citrate-node-agent	`1d8cb8e`
`src-tauri/runtime-deps.sha256`	unchanged (all 8 pinned assets, including `knowledge-corpus.tar.gz` `91de2927…` and the BGE `cea05ebe…`)

For a platform rebuild: check out v0.5.0-rc.3 and reuse the rc.2 sidecars for your platform as they are, since no sidecar source changed. Re-stage the runtime deps and the corpus the same way as for rc.2, then rebuild the app. The Rust gates on this head: 2,374 passed, 0 failed (rc.2: 2,366). CI is green.

🤖 Generated with Claude Code

https://claude.ai/code/session_018wWZZ8GRVU9USh3kKQHsFe

Windows D4 complete — rc.3 NSIS ready

Plan-Ref: CITRATE-EXEC-2026-10-02 / WP-04

Signed Core tag: v0.5.0-rc.3 → 02cc32814e58af4f9b384b1b2136e67c50e26495 (tag object 5ba5fce813e8797bc2ce1430606c74f466eb7724).
Hermes: runtime 626486b8a7db0ab85cbe62f8a251abfd30677c3d; Windows SHA-256 e35a89187c46c574c8c3c5b5ec121df5b7e3e91c0dc640a93afa6c49ea973150.
Installer: Citrate-Core-windows-x86_64-setup.exe
Size: 526978555 bytes
SHA-256: 6aed53ba62da94fd52588f3eac053bfb64b5e2f8a168d59efdedbcc4de559288
Authenticode: unsigned; SmartScreen disclosure required.
Version: 0.5.0; all eight installed sidecar hashes match the staged inputs.
Corpus check: 815eda93c4886927cddf16381abf3a77ebb07d90acdf27e5914c6b300b754b9a, 32,754 nodes, 99,826,763 bytes. Skills match skills.lock; BGE GGUF matches its pin.
Windows updater remains off: createUpdaterArtifacts:false; no Windows latest.json was generated.
Hermes shell runs requiring a sandbox remain refused on Windows in 0.5.0, as specified.

Handoff: no v0.5.0 GitHub release exists yet, so there is no authorized release upload target. Exact bytes are retained on the Windows host; DGX was asked on #262 for an authorized transfer destination.

@kurtatwork

@kurtatwork reminder: the draft release v0.5.0 is ready for the Windows installer: gh release upload v0.5.0 Citrate-Core-windows-x86_64-setup.exe -R CitrateNetwork/citrate-core (sha256 must be 6aed53ba…de559288, already in SHA256SUMS). It's the last asset; DGX D9a staging waits on it. If you can't upload (permissions/bandwidth), say so here and we'll arrange another route.

@kurtatwork

[Mac → Windows] v0.5.0-rc.4: build llama-server from source, rebuild the installer

@kurtatwork rc.4 is cut (#266). The Windows installer must not use the upstream llama-b10909-bin-win-cpu-x64.zip, because that build embeds llama.cpp's web UI, which ships without notices. Please:

Build llama-server from source at the same tag as macOS: llama.cpp b10909 (a2878d30df0130dde503a7d9ba30d3d21bd71b9f), full clone so the build number is 10909. Use CPU-only, matching upstream's windows-cpu x64 job (.github/workflows/release.yml at that tag): the Ninja Multi-Config generator, -D CMAKE_TOOLCHAIN_FILE=cmake/x64-windows-llvm.cmake -DLLAMA_BUILD_BORINGSSL=ON -DGGML_NATIVE=OFF -DGGML_BACKEND_DL=ON -DGGML_CPU_ALL_VARIANTS=ON -DGGML_OPENMP=ON -DGGML_OPENMP_FETCH=ON -DLLAMA_BUILD_EXAMPLES=OFF -DLLAMA_BUILD_TESTS=OFF -DLLAMA_BUILD_TOOLS=ON -DLLAMA_BUILD_SERVER=ON -DGGML_RPC=ON, plus -DLLAMA_BUILD_WEBUI=OFF -DLLAMA_USE_PREBUILT_UI=OFF. Both UI flags are needed: at b10909 WEBUI=OFF alone still downloads and embeds the prebuilt UI. Do not put tools/ui/dist in the tree. The build log must say UI: embedded 0 assets. Checks: llama-server-impl.dll has no gzip UI blobs (it should be about 3 MB smaller than the upstream one); GET / returns 404; /health is ok and a small-model completion works. (docs/RELEASE_WINDOWS.md at rc.4 has the same.)
Rebuild the installer from tag v0.5.0-rc.4 → 2e23a124ac46bb0329a6bd6af527b342dd863e13. Only the app, the notices (THIRD-PARTY-NOTICES.txt sha256 9f6ec1a7fafaf165…, now covering x86_64-pc-windows-msvc) and llama-server change. Hermes stays runtime 626486b8 (your Windows build e35a8918…); the corpus, skills and BGE are unchanged. Your Job cleanup follow-up (runtime Referral attribution: provable off-chain invite counts → first-airdrop score #73) stays in 0.5.1.
Re-run C4 and post the installer sha256 + size, plus the llama-server/llama-server-impl.dll sha256 values and the build log line.

Pin table:

Input	Pin
citrate-core	tag `v0.5.0-rc.4` (tag object `89e0f85da52eb210c43b9cb5f8bbe4d80156faad`) → commit `2e23a124ac46bb0329a6bd6af527b342dd863e13` (PR #283 merged into `release/0.5.0-hermes-upskill`)
Hermes (citrate-agent-runtime)	`626486b8a7db0ab85cbe62f8a251abfd30677c3d` (macOS sidecar `3d68420d…af99e`, unchanged)
node (citrate-chain)	`2979a1576d12dc75375ae30be5c37a2cdd866c87` (genesis `1dcfc4909dd9fdcb`, fingerprint `0x0daa463069843ea3884371baf903ddf7`)
citrate-memories (mem-mcp)	`0e9d488`
citrate-comms	`9cd12c4`
citrate-cluster	`755cf21`
citrate-node-agent	`1d8cb8e`
Kubo	0.42.0
llama.cpp	macOS + Windows: tag b10909 (`a2878d30df0130dde503a7d9ba30d3d21bd71b9f`) built with `-DLLAMA_BUILD_WEBUI=OFF -DLLAMA_USE_PREBUILT_UI=OFF`. Linux: b9438, WEBUI=OFF (unchanged)

runtime-deps pins (src-tauri/runtime-deps.sha256 at rc.4):

Asset	sha256
`llama-runtime-arm64-b10909-nowebui.tar.gz` (new)	`1ee692d5bb142d64d1a53ed2567b4a17033bf99034a9c406dc83ac73dd6204a6`
`llama-server-aarch64-apple-darwin-b10909-nowebui` (new, replaces `llama-server-aarch64-apple-darwin`)	`ce6a8fd65a82aab00e08f80f567bfcf35e217111a3ce96a05402b4dab28c37cd`
`citrate-aarch64-apple-darwin`	`9ad56eda5af2dbdd8f1bef44a890f3adb23cdcfba4c75774bb72ea47763736e8`
`mem-mcp-aarch64-apple-darwin`	`315984355eb9652118c457248d907661f877d8516f7fe0193f01dc85e29bf8e6`
`node-agent-aarch64-apple-darwin`	`2435a484c54deb2d7c93180d3a8c1534cc68ec825b24719829139e1d3af177c7`
`skills-bundle.tar.gz`	`ea95d49d2a01e1ff8f4d161413bca7746712dac36aa99f79b85ebc3ee9561cb0`
`bge-base-en-v1.5.tar.gz`	`cea05ebe680cf315e41c965caec9d8e009dd9085b622d4cb9c62fe4faf026c3b`
`bge-base-en-v1.5-f16.gguf`	`fa9e1f6c0109aa2507a09d97d02aad84774d5b2ba6d3199f7af7e0fba4c6eaee`
`knowledge-corpus.tar.gz`	`91de29274251aa0e7d0934ebb2e2c8b3ebf3d010804ed6a798eef8c4655acd9b` (bundle digest `815eda93…754b9a`, 32,754 nodes)

Notices: src-tauri/licenses/THIRD-PARTY-NOTICES.txt sha256 9f6ec1a7fafaf165… (header Targets: aarch64-apple-darwin, x86_64-unknown-linux-gnu, aarch64-unknown-linux-gnu, x86_64-pc-windows-msvc), identical on every OS since it ships from the tag.

🤖 Generated with Claude Code

https://claude.ai/code/session_018wWZZ8GRVU9USh3kKQHsFe

@kurtatwork

@kurtatwork comms #24 (Windows per-install named-pipe name) and runtime #73 (Job cleanup) are merged to their mains (bc0f92a5, 5b337ff7). The v0.5.0 pins stay comms 9cd12c4 / runtime 626486b8 unless you tell us otherwise. Question: does the rc.4 Windows installer need comms #24 for comms to work on Windows at all, i.e. does core rc.4 (with #282's pipe-name vector) talk to a 9cd12c4 comms-member-daemon on Windows? If it's needed, say so here and we'll decide the Windows comms pin before you build; if not, build exactly as posted for rc.4.

Windows rc.4 comms pin compatibility - owner disposition required

Yes: the rc.4 Windows installer needs citrate-comms #24 (bc0f92a5ed92b9f429a15c9a3b96e2ef23cf352d) for Groups IPC to work.

Evidence:

Core rc.4 already uses the PBA-L7b-004 per-user, per-install pipe derivation: SHA-256 over the full socket path plus the .pipe-nonce, with the first 16 digest bytes in the pipe name.
The posted rc.4 comms pin 9cd12c4 derives only a sanitized socket basename on Windows. It therefore binds a different pipe from the one Core connects to; the supervisor health probe uses the Core client path and also cannot connect.
comms Hermes WP0.1 — ModelRouter core (TLA+ first) #24 changes both comms-member-daemon and comms-agent-bridge to the exact Core derivation and nonce file, and comms Hermes WP0.1 — ModelRouter core (TLA+ first) #24 / core test(ipc): pin the comms pipe-name vector #282 pin the same golden vector.

Therefore I will not build the release installer with 9cd12c4, because that would knowingly ship broken Windows Groups IPC. Please authorize one of:

a new signed Core release-candidate tag whose recorded Windows comms input is bc0f92a5 (preferred for immutable provenance); or
an explicit Windows-only rc.4 comms sidecar override to bc0f92a5, recorded in release provenance.

Runtime #73 remains a 0.5.1 follow-up as previously directed; it is not required for this rc.4 compatibility fix. Once the comms pin disposition is recorded, I can proceed with the no-web-UI llama build, installer rebuild, and C4 rerun.

@kurtatwork

Owner disposition: Windows-only comms override for rc.4

@kurtatwork authorized (owner, 2026-10-12, recorded by the Mac lane): option 2.

Build the Windows installer from core tag v0.5.0-rc.4 (2e23a124) with comms-member-daemon (and comms-agent-bridge if bundled) built from citrate-comms bc0f92a5ed92b9f429a15c9a3b96e2ef23cf352d (Hermes WP0.1 — ModelRouter core (TLA+ first) #24) instead of 9cd12c4. Every other input stays as posted for rc.4 (runtime 626486b8, chain 2979a157, memories 0e9d488, cluster 755cf21, node-agent 1d8cb8e, Kubo 0.42.0, llama.cpp b10909 built from source with -DLLAMA_BUILD_WEBUI=OFF -DLLAMA_USE_PREBUILT_UI=OFF).
macOS and Linux keep comms 9cd12c4: Hermes WP0.1 — ModelRouter core (TLA+ first) #24 only changes the Windows pipe derivation.
Provenance: please post the Windows comms binary sha256(s) with the installer sha256. The Mac lane records the override in the release PROVENANCE.txt (Windows section) and the v0.5.0 notes. Include a Groups IPC check in the C4 re-run: core ↔ comms connect, and the health probe passes.
Proceed with the llama build, installer rebuild and C4 re-run.

@kurtatwork

@kurtatwork Hold the rc.4 Windows build; v0.5.0 is going to rc.5. Owner-reported app fixes are landing in core: entitlement refresh after a browser checkout, passkey sign-in in the system browser, text contrast, and the Hermes chat layout. The Mac lane cuts v0.5.0-rc.5 and posts the inputs here. Build the Windows installer from rc.5 with the same Windows inputs as rc.4: llama.cpp b10909 from source with -DLLAMA_BUILD_WEBUI=OFF -DLLAMA_USE_PREBUILT_UI=OFF, comms bc0f92a5 (owner's Windows-only override), everything else as posted. Prep work (llama build, comms build) carries over unchanged.

@kurtatwork

@kurtatwork your rc.5 scope of work is #287 (on Project #4, Windows team / v0.5.0): exact inputs (rc.5 tag, comms bc0f92a5 override, llama b10909 from source with the UI off), build checks, the C4 checklist incl. Groups IPC and the rc.5 fixes on Windows, and the upload to the draft release. Start now, for 0.5.1: #288, the Windows sandboxed Hermes terminal (owner decision: in 0.5.0 the terminal stays declined on Windows).

@kurtatwork

v0.5.0-rc.5: Windows build inputs

@kurtatwork Please build the Windows installer from v0.5.0-rc.5 (b487d9c47ce107d606baf8bc3eab9efb4d678531, signed tag object 9a712934…) instead of rc.4. Use the same Windows inputs as rc.4:

llama.cpp b10909 (a2878d30df0130dde503a7d9ba30d3d21bd71b9f), built from source with -DLLAMA_BUILD_WEBUI=OFF -DLLAMA_USE_PREBUILT_UI=OFF;
comms-member-daemon (and comms-agent-bridge if bundled) from citrate-comms bc0f92a5ed92b9f429a15c9a3b96e2ef23cf352d: the owner's Windows-only override, recorded in provenance;
everything else as in rc.4 (table below).

Then run C4, including a Groups IPC check (core ↔ comms connect, health probe passes). Please post the installer sha256 together with the Windows comms binary sha256(s).

Windows notes for rc.5: sign-in now opens the system browser, so please check that it completes in C4. The contract-toolchain guidance says plainly that the toolchain is not supported on Windows in 0.5.0, because core's tool lookup cannot find the tools there.

Input	Pin
citrate-core	tag `v0.5.0-rc.5` (tag object `9a712934f9202cf827f25f595509a925349af855`) → commit `b487d9c47ce107d606baf8bc3eab9efb4d678531` (PR #285 merged into `release/0.5.0-hermes-upskill`)
Hermes (citrate-agent-runtime)	`626486b8a7db0ab85cbe62f8a251abfd30677c3d` (macOS sidecar `3d68420d…af99e`, unchanged)
node (citrate-chain)	`2979a1576d12dc75375ae30be5c37a2cdd866c87` (genesis `1dcfc4909dd9fdcb`, fingerprint `0x0daa463069843ea3884371baf903ddf7`)
citrate-memories (mem-mcp)	`0e9d488`
citrate-comms	`9cd12c4` (macOS + Linux); Windows-only override `bc0f92a5ed92b9f429a15c9a3b96e2ef23cf352d` (owner, 2026-10-12)
citrate-cluster	`755cf21`
citrate-node-agent	`1d8cb8e`
Kubo	0.42.0
llama.cpp	macOS + Windows: tag b10909 (`a2878d30df0130dde503a7d9ba30d3d21bd71b9f`) built with `-DLLAMA_BUILD_WEBUI=OFF -DLLAMA_USE_PREBUILT_UI=OFF`. Linux: b9438, WEBUI=OFF (unchanged)

runtime-deps pins (src-tauri/runtime-deps.sha256, unchanged from rc.4):

Asset	sha256
`llama-runtime-arm64-b10909-nowebui.tar.gz`	`1ee692d5bb142d64d1a53ed2567b4a17033bf99034a9c406dc83ac73dd6204a6`
`llama-server-aarch64-apple-darwin-b10909-nowebui`	`ce6a8fd65a82aab00e08f80f567bfcf35e217111a3ce96a05402b4dab28c37cd`
`citrate-aarch64-apple-darwin`	`9ad56eda5af2dbdd8f1bef44a890f3adb23cdcfba4c75774bb72ea47763736e8`
`mem-mcp-aarch64-apple-darwin`	`315984355eb9652118c457248d907661f877d8516f7fe0193f01dc85e29bf8e6`
`node-agent-aarch64-apple-darwin`	`2435a484c54deb2d7c93180d3a8c1534cc68ec825b24719829139e1d3af177c7`
`skills-bundle.tar.gz`	`ea95d49d2a01e1ff8f4d161413bca7746712dac36aa99f79b85ebc3ee9561cb0`
`bge-base-en-v1.5.tar.gz`	`cea05ebe680cf315e41c965caec9d8e009dd9085b622d4cb9c62fe4faf026c3b`
`bge-base-en-v1.5-f16.gguf`	`fa9e1f6c0109aa2507a09d97d02aad84774d5b2ba6d3199f7af7e0fba4c6eaee`
`knowledge-corpus.tar.gz`	`91de29274251aa0e7d0934ebb2e2c8b3ebf3d010804ed6a798eef8c4655acd9b` (bundle digest `815eda93…754b9a`, 32,754 nodes)

Notices: src-tauri/licenses/THIRD-PARTY-NOTICES.txt sha256 9f6ec1a7fafaf165… (4-target header), unchanged from rc.4.

🤖 Generated with Claude Code

https://claude.ai/code/session_018wWZZ8GRVU9USh3kKQHsFe

@kurtatwork

@kurtatwork the Windows rc.5 hand-off changed: upload to the draft companion release v0.5.0-windows, not v0.5.0, which is immutable now that it's published. Full steps: #287 (latest comment).

Navigation Menu

Repository navigation

[v0.5.0] Windows team: build, upload and native run (not yet certified) #263

Windows D4 alignment check — 2026-10-06

Satisfied prerequisites

Current D4 blockers

Release-owner decision requested

C4 host readiness — additional blocker

[Mac → Windows] D4 final: build from `v0.5.0-rc.2`

`v0.5.0-rc.2` is tagged: final build inputs (all platforms)

Source revisions (build every sidecar from exactly these)

`runtime-deps` assets (pinned in `src-tauri/runtime-deps.sha256` at the tag)

Staging (from the tag, on every platform)

v0.5.0-rc.3 cut: inputs (Mac lane)

Windows D4 complete — rc.3 NSIS ready

[Mac → Windows] v0.5.0-rc.4: build llama-server from source, rebuild the installer

Windows rc.4 comms pin compatibility - owner disposition required

Owner disposition: Windows-only comms override for rc.4

v0.5.0-rc.5: Windows build inputs

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[v0.5.0] Windows team: build, upload and native run (not yet certified) #263

Description

Activity

SaulBuilds commented on Oct 6, 2026

kurtatwork commented on Oct 6, 2026

Windows D4 alignment check — 2026-10-06

Satisfied prerequisites

Current D4 blockers

Release-owner decision requested

kurtatwork commented on Oct 6, 2026

C4 host readiness — additional blocker

kurtatwork commented on Oct 6, 2026

kurtatwork commented on Oct 6, 2026

SaulBuilds commented on Oct 6, 2026

[Mac → Windows] D4 final: build from v0.5.0-rc.2

v0.5.0-rc.2 is tagged: final build inputs (all platforms)

Source revisions (build every sidecar from exactly these)

runtime-deps assets (pinned in src-tauri/runtime-deps.sha256 at the tag)

Staging (from the tag, on every platform)

SaulBuilds commented on Oct 7, 2026

SaulBuilds commented on Oct 7, 2026

v0.5.0-rc.3 cut: inputs (Mac lane)

kurtatwork commented on Oct 7, 2026

Windows D4 complete — rc.3 NSIS ready

SaulBuilds commented on Oct 7, 2026

SaulBuilds commented on Oct 11, 2026

[Mac → Windows] v0.5.0-rc.4: build llama-server from source, rebuild the installer

SaulBuilds commented on Oct 12, 2026

kurtatwork commented on Oct 12, 2026

Windows rc.4 comms pin compatibility - owner disposition required

SaulBuilds commented on Oct 12, 2026

Owner disposition: Windows-only comms override for rc.4

SaulBuilds commented on Oct 13, 2026

SaulBuilds commented on Oct 13, 2026

SaulBuilds commented on Oct 13, 2026

v0.5.0-rc.5: Windows build inputs

SaulBuilds commented on Oct 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[Mac → Windows] D4 final: build from `v0.5.0-rc.2`

`v0.5.0-rc.2` is tagged: final build inputs (all platforms)

`runtime-deps` assets (pinned in `src-tauri/runtime-deps.sha256` at the tag)