Problem
go build ./... fails on Windows for v0.2.1. The internal/agency packages and internal/daemon use Unix-only APIs with no Windows build variants:
- syscall.Stat_t (owner/hard-link checks) in agency/{artifact,attach,authority,client} and daemon
- unix.Openat/Fstatat/Mkdirat/Renameat/Unlinkat, unix.Flock, unix.Wait4, SysProcAttr{Setsid} in agency/client and daemon
- peerUID (SO_PEERCRED) has darwin/linux variants only
Port status
A working local port exists (built from the v0.2.1 source tree): Unix-specific helpers were split into *_unix.go (unchanged) plus new *_windows.go implementations with identical signatures, covering 5 packages (agency/artifact, agency/attach, agency/authority, agency/client, daemon). Results:
- go build ./... / go vet ./... pass on Windows, Linux and macOS
- gofmt clean
- Core memory commands (status/remember/recall/search/link/related/forget/gc/log/receipt/store/viz) verified end-to-end on Windows, UTF-8 (Chinese) clean, plugin (dsh-mnemon) JSON contract aligned
Windows substitutions and documented degradations:
- flock -> LockFileEx/UnlockFileEx over byte range [0,1) (0-length range is rejected on Windows); busy error maps to ERROR_LOCK_VIOLATION
- openat/fstatat/mkdirat/renameat/unlinkat -> path-based os.* calls; rename-overwrite via MoveFileEx(MOVEFILE_REPLACE_EXISTING); symlink safety re-checked post-open with os.Lstat/os.SameFile (slightly larger TOCTOU window)
- owner UID / hard-link-count checks are pass-through on Windows (no UID/nlink in Win32FileAttributeData); NTFS ACLs govern access
- peerUID returns constant 0 (no SO_PEERCRED equivalent)
Security decision in the port
mnemon agency serve is refused on Windows via an explicit build-tagged gate: with peer UID/owner checks collapsed to 0==0 and os.Chmod(0o600) not constraining NTFS ACLs, an unauthenticated local control socket would hand full authority to any local process that can reach the socket path. Core memory commands do not use the daemon and are unaffected.
Ask
Would you accept this as a PR (possibly with adjustments)? Happy to prepare the full diff for review. Also worth deciding whether agency daemon support on Windows should be compiled out entirely rather than gated at runtime.
Problem
go build ./... fails on Windows for v0.2.1. The internal/agency packages and internal/daemon use Unix-only APIs with no Windows build variants:
Port status
A working local port exists (built from the v0.2.1 source tree): Unix-specific helpers were split into *_unix.go (unchanged) plus new *_windows.go implementations with identical signatures, covering 5 packages (agency/artifact, agency/attach, agency/authority, agency/client, daemon). Results:
Windows substitutions and documented degradations:
Security decision in the port
mnemon agency serve is refused on Windows via an explicit build-tagged gate: with peer UID/owner checks collapsed to 0==0 and os.Chmod(0o600) not constraining NTFS ACLs, an unauthenticated local control socket would hand full authority to any local process that can reach the socket path. Core memory commands do not use the daemon and are unaffected.
Ask
Would you accept this as a PR (possibly with adjustments)? Happy to prepare the full diff for review. Also worth deciding whether agency daemon support on Windows should be compiled out entirely rather than gated at runtime.