v0.2.2 builds and runs on Windows, but the release ships no windows artifact

[allenliang2022]

Summary

v0.2.2 builds and runs correctly on Windows, but the release publishes no Windows artifact. .goreleaser.yml still lists only linux and darwin, so the Windows support restored in #103 does not reach users who install from Releases.

This is scoped strictly to the core memory product. Agency stays out of scope, fail-closed on Windows, exactly as #103 decided and as #101 continues to track.

Timeline that produced the gap

When	What
2026-08-15T00:02:13Z	#103 merged: Windows build restored, Agency gated, native Windows CI job added
2026-08-15T00:04:32Z	v0.2.2 published — two minutes later

v0.2.2 therefore contains the Windows fix, but its five release assets are:

mnemon_0.2.2_darwin_amd64.tar.gz
mnemon_0.2.2_darwin_arm64.tar.gz
mnemon_0.2.2_linux_amd64.tar.gz
mnemon_0.2.2_linux_arm64.tar.gz
checksums.txt

The cause is one unchanged list in .goreleaser.yml:

builds:
  - id: mnemon
    main: .
    binary: mnemon
    env:
      - CGO_ENABLED=0
    goos:
      - linux
      - darwin        # windows is absent
    goarch:
      - amd64
      - arm64

Nothing else blocks it: the build is already CGO_ENABLED=0, SQLite is the pure-Go modernc.org/sqlite v1.45.0, and #103 added the CI job that proves the target compiles.

End-user verification on Windows

Built from the published module, on a machine with no Go toolchain beforehand:

go version go1.26.5 windows/amd64
go install github.com/mnemon-dev/mnemon@latest   # resolved v0.2.2

Produces %USERPROFILE%\go\bin\mnemon.exe, 20,289,536 bytes.

mnemon status creates and reads the store correctly — pure-Go SQLite works on Windows:

{
  "by_category": {},
  "db_path": "C:\\Users\\liang\\.mnemon\\data\\default\\mnemon.db",
  "db_size_bytes": 4096,
  "deleted_insights": 0,
  "edge_count": 0,
  "oplog_count": 0,
  "top_entities": [],
  "total_insights": 0
}

It is also live behind dsh-mnemon in DeepSeek Harness, which reports healthy: true, commandFound: true, and a healthy default store.

This is an end-user path rather than a CI target: it confirms that what #103 restored is usable in practice, not only that it compiles.

Downstream impact

dsh-mnemon documents brew and go install as the two ways to obtain the CLI, and neither is a normal Windows path. Its binary discovery falls back to four hardcoded candidates:

const COMMON_CLI_PATHS = [
  "~/.local/bin/mnemon",
  "/opt/homebrew/bin/mnemon",
  "/usr/local/bin/mnemon",
  "/usr/bin/mnemon",
]

None can match on Windows, so every Windows user who installs that plugin gets:

failed to launch mnemon ("mnemon"): spawn mnemon ENOENT

The plugin reads as broken, when in fact no Windows binary was ever published. Shipping the artifact removes the whole class of report. (Filed separately against omdsh-dev/dsh-mnemon for the discovery and documentation side.)

Suggested change

     goos:
       - linux
       - darwin
+      - windows

Two details worth deciding at the same time:

1. Archive format. archives.formats is tar.gz for everything. zip for Windows is the more common expectation; goreleaser expresses that with a format_overrides entry.
2. Version stamping. The ldflags -X ...cmd.version={{.Version}} only applies to goreleaser builds, so a go install binary reports mnemon version dev. That is expected for source installs, but it does mean the version string cannot currently distinguish "built from v0.2.2" from "built from an arbitrary commit". Not a blocker; just visible while no Windows release exists.

Happy to verify a Windows artifact from a draft release if that is useful.

Environment

• Windows 11, amd64
• Go 1.26.5
• mnemon v0.2.2 via go install
• Consumer: dsh-mnemon 0.1.4 on DeepSeek Harness 0.1.0-rc.5