Skip to content

v0.10.1

Choose a tag to compare

View all tags
@initializ-mk initializ-mk released this 19 May 04:54
v0.10.1
2aa422c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Forge v0.10.1 — Windows Agent Start Fix, Documentation Link Cleanup

Release Date: May 19, 2026
Full Changelog: v0.10.0...v0.10.1

Forge v0.10.1 is a patch release containing one user-facing reliability fix on Windows and a comprehensive documentation link cleanup. Three pull requests, 24 files changed, no breaking changes — drop-in upgrade from v0.10.0.

Highlights

# Area Change Issue / PR
1 Windows forge ui no longer falsely reports agent failed to start for healthy daemons. Cause: Signal(0) is unsupported on Windows; the cross-platform process-liveness check is now centralized. #59 / #60
2 Documentation All 21 broken doc links in the main README.md are fixed. New CI workflow gates future README link breakage. #58 / #61
3 Documentation All 34 broken in-doc cross-references across 14 doc files are fixed. The CI link check is extended to cover docs/**. #62 / #63

What's Fixed

Windows: forge ui Recognizes Healthy Daemons (PR #60, closes #59)

Symptom: On Windows, starting an agent from forge ui produced a red banner reading agent failed to start: REST: http://localhost:<port>/tasks/send ... — but the backend agent was actually running successfully. The same flow worked correctly on macOS and Linux.

Cause: forge-ui/process.go's pidAlive function used os.Process.Signal(syscall.Signal(0)) — the standard Unix idiom for liveness checking. On Windows, Go's stdlib only translates os.Interrupt and os.Kill; every other signal (including Signal(0)) returns "operating system does not support signal". So pidAlive returned false for every PID on Windows regardless of whether the process was alive.

The waitForPort poll loop interpreted that as "child crashed", fast-failed, and surfaced whatever was already in serve.log as the supposed error — which by that point contained the daemon's normal startup banner.

A second occurrence of the same broken check in forge-ui/discovery.go was actively deleting .forge/serve.json for still-running daemons on every page-load — orphaning them from the dashboard. Both are fixed.

Fix: New shared helper forge-core/util/process/{process_unix.go, process_windows.go} with IsAlive(pid int) bool. Unix path uses FindProcess + Signal(0); Windows path uses OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION) + CloseHandle — the same pattern forge-cli/cmd/serve_windows.go already shipped for daemon-lifecycle checks. The duplicate implementations in forge-cli and forge-ui are deleted in favor of the single shared helper.

// One implementation, build-tag split, consumed by both forge-cli and forge-ui.
import "github.com/initializ/forge/forge-core/util/process"

if !process.IsAlive(pid) {
    // accurate on every supported platform
}

There is now exactly one implementation of "is this PID alive" in the repo. CI runs GOOS=windows go build to catch future build-tag drift.

README Doc Links Fixed (PR #61, closes #58)

The top-level README.md referenced 25 relative .md files. 21 of them were 404s — the README linked to canonical flat names (docs/runtime.md, docs/security/secrets.md, …) but the actual docs lived under subdirectories with different filenames (docs/core-concepts/runtime-engine.md, docs/security/secret-management.md, …). Every newcomer clicking "Quick Start", "Installation", "Architecture", "Skills", "Runtime", "Memory", "Channels", or any of 12 other top-level doc links from the README landed on a GitHub 404.

After the fix:

before: BROKEN 21, OK 4
after:  BROKEN 0,  OK 25

A new .github/workflows/docs-links.yaml runs on every push/PR touching README.md, docs/**, or the workflow itself — fails the build if any relative .md link doesn't resolve. Prevents this from regressing.

In-Doc Cross-References Fixed (PR #63, closes #62)

The same pattern that broke the README also broke 34 in-doc cross-references across 14 doc files. The heaviest hitter was docs/security/overview.md (10 broken links — the file pre-dated the rename of egress.md → egress-control.md, secrets.md → secret-management.md, signing.md → build-signing.md). Other files used paths like security/guardrails.md from within docs/core-concepts/ which resolved to docs/core-concepts/security/guardrails.md (does not exist) instead of docs/security/guardrails.md.

All 34 fixed via mechanical substitution with #anchor preservation. The CI link check is extended to walk docs/**/*.md in addition to README.md:

before: 34 broken in-doc links across 14 files
after:   0 broken; 37 files checked (1 README + 36 docs)

Upgrade Notes

Drop-in patch upgrade — no forge.yaml changes, no API changes, no behavior changes for healthy installs.

  • Windows users on v0.10.0: this release fixes the "agent failed to start" red banner. Highly recommended.
  • forge-core/util/process is a new package. If you import forge-core directly in your own Go projects, the new package is available but doesn't change any existing API.

Install

# Homebrew
brew upgrade initializ/tap/forge

# One-line install/upgrade
curl -sSL https://raw.githubusercontent.com/initializ/forge/main/install.sh | bash

# Docker
docker pull ghcr.io/initializ/forge:v0.10.1
docker pull ghcr.io/initializ/forge:latest

Reference

Assets 9
Loading