Guildhall 0.5.0

Summary

Guildhall 0.5.0 is the release where the product finally pivots from "dashboard inside one repo" to local service over projects.

The important claim for this release is not just that the UI moved around. It is that the product, CLI, packaging story, and proof surface now all tell the same story:

• Guildhall runs as a user-local service
• the top level is a Projects view
• each project has its own lifecycle inside that service
• the previously proven narrow automation lane still survives inside the new nested project shell

What changed

Projects-first product shell

• the root experience is now a Projects home instead of assuming one selected workspace
• the current Guildhall app lives inside /project
• users can move up and back between the fleet view and a single project

Project attach and initialization flow

• Attach project starts from an existing folder
• existing Guildhall config is detected and registered
• folders without Guildhall config open as uninitialized projects
• setup now happens inside the project shell instead of as a detached first-run experience

Local service model

• guildhall serve is now the friendly entrypoint
• guildhall start, guildhall open, and guildhall stop support the background-service workflow explicitly
• service state is separated from project state

macOS-first installer story

• recommended install path: curl installer
• packaged artifact includes:
  • bundled Node runtime
  • packaged Guildhall app payload
  • LaunchAgent install/uninstall plumbing
• GitHub Releases include:
  • guildhall-macos.tar.gz
  • guildhall-macos.tar.gz.sha256
• the curl installer verifies the checksum before unpacking the downloaded package
• npm install -g guildhall is still supported, but it is no longer the lead story

UI structure cleanup

• shell and project surfaces were reorganized around reusable layouts and cleaner data shaping
• project cards now summarize:
  • current stage
  • recent activity
  • agent activity
  • recent completed or blocked work
  • a short project blurb

Proof behind this release

0.5.0 now has proof for the new service/project shape:

• service starts with no selected project
• an existing initialized project is visible from the fleet view
• attaching an existing folder without Guildhall config opens an uninitialized project shell
• completing setup promotes that folder into the registered project list
• per-project start and stop work from the service shell
• a project with the proven narrow automation lane still surfaces terminal success correctly inside the nested project shell

Focused proof coverage lives in:

• /Users/matthew/git/oss/guildhall/src/runtime/__tests__/e2e.test.ts
• /Users/matthew/git/oss/guildhall/src/runtime/__tests__/serve-release-readiness.test.ts
• /Users/matthew/git/oss/guildhall/scripts/release-artifacts.test.ts

The release artifact itself is produced by .github/workflows/release.yml when a v* tag is pushed. That workflow runs the release gates, builds the macOS package on a macOS runner, writes the checksum, and uploads both files to the matching GitHub Release.

Packaging decision

We explicitly compared Node-based packaging vs Deno packaging for this release.

0.5.0 keeps the Node-based packaged executable because it was:

• smaller in the shipped form
• faster to start
• compatible with the current runtime architecture
• already proven on the real install/start/stop path

The Deno experiment compiled only with --no-check, produced a larger binary, and failed the real serve --no-open startup path in our comparison.

Supported claim

For 0.5.0, the honest supported claim is:

Guildhall now behaves like a real local service over projects, with a packaged macOS install path and preserved end-to-end automation for its proven narrow task lane.

Still not the claim

This release still does not claim that Guildhall can autonomously complete every project task shape.

The proven automation lane remains the bounded one we already established in 0.4.0:

• narrow
• low-blast-radius
• locally scoped engineering tasks