Guildhall 0.9.0
Guildhall 0.9.0 is about trust. It gives project work a clearer runtime boundary, makes finished work easier to inspect, gives memory a lifecycle, and lets MCP-aware tools read the same project context Guildhall is using.
It is still a local macOS app. Your projects can be web apps, libraries, docs, or native projects, but the Guildhall host for 0.9.0 is macOS.
What changed
- Runtime-backed execution: Guildhall can run project work in an on-demand Podman runtime. The runtime starts when work needs it, mounts the project and host
~/.guildhall, and leaves host-run compatibility available when setup is skipped or not ready. - Release-tied runtime image: the 0.9 runtime image is checked as part of the release. The manifest names the expected Debian, Node, Python, Playwright, runtime API, executable shape, and image tags. Final publication records the image digest before the package is shipped.
- Guided local runtime setup: Settings -> Ready shows whether Podman is missing, installed but not started, ready, or unsupported. Guildhall does not install Podman or pull images during package install; you choose when setup runs.
- Proof paths and completion handoffs: done work now has a clearer proof trail: what was changed, how to launch or inspect it, which commands passed, what could not be verified, and what residue remains.
- Clearer next action: the project shell keeps Start or Stop obvious. When work is blocked, the disabled action and notice point to the question, spec, migration, or task that needs attention.
- Project re-intake: Settings -> Re-intake can re-read a project, compare the current evidence with existing tasks and progress, and draft a cleaner plan without treating old cards as unquestionable truth.
- Memory lifecycle: accepted project facts, habits, playbooks, global preferences, and Guildhall product ideas are separated so learned behavior is inspectable and reversible.
- MCP context resources: external tools can inspect project state, runtime, memory, context health, codebase knowledge, feedback, design context, and capability requests without scraping internal files.
- Task shaping and flexible hierarchy: Guildhall can split broad work into containing tasks and nested runnable tasks, then start or inspect the selected task instead of treating all work as one flat queue.
- Design-quality proof: UI work now carries design guidance, preview or catalog context, feedback, and notes about what should be reusable so Guildhall aims for good results, not merely functional screens.
- Calibrated review: review plans now record risk, required evidence, and missed issues. UI review can require screenshots or other proof before a task is accepted.
Why it matters
Guildhall is meant to turn a pile of thoughts into work you can trust. That takes more than a worker loop. You need to know where the work ran, what changed, how it was checked, what Guildhall learned, and whether "works" is actually good enough.
0.9.0 is the foundation for that version of the product. The release check also covers different project shapes: a component-library integration, a broad software reframe, migration-blocked work, and a small single-edit task that should not be over-split.
The edges
The runtime path is guided and reversible. Host-run compatibility remains the fallback when Podman is unavailable, unsupported, or not yet approved for a project. The 0.9 docs snapshot is cut as part of the release process after the package version and runtime image digest are finalized.