Projects and work

Guildhall is easiest to understand once you see how projects and work relate. The app starts at the service home, then narrows into the project shell where project survey, task blueprints, live agent work, inspections, and release readiness play out. It keeps the current state visible so you do not have to hold the whole run in your head.

What it does well

• Service over projects: Projects & Workspaces is not married to one repo. It runs as a local service and keeps multiple projects available from one place.
• Current labels match the app: the service row is Guild hall (the shared room for all registered projects), Work mix, Attention, and Running now; the project cards carry state chips such as Paused, Queued, Needs task briefs, Mixed, Stable, and Inspect.
• File-backed, not hidden: the shared contract lives in ./guildhall.yaml, shared Guildhall metadata can live in committed ./.guildhall/*.yaml files, project memory lives in ./memory/*, and local/private overrides live in ./.guildhall/config.yaml. Machine-wide state such as the registry and provider credentials lives in ~/.guildhall/. The UI is a clearer window into that state, not a secret second database.
• One operating place: the service home gets you into the right project, and the shell carries the detailed state without feeling like a separate product.
• Memory you can inspect: Settings -> Memory shows project habits, cross-project preferences, project playbooks, and Guildhall product ideas without adding a new approval step to every task.

Most of the real loop lives in the browser

• Attach and configure: bring a project into the service, choose a provider path, and get the shell into a state where agents can work without tripping over setup debris.
• Shape and launch tasks: create work, review the blueprint, answer the awkward questions, then hit Start when the task is ready to move.
• Inspect the run: read the queue, open the drawer, follow the transcript, and decide whether Guildhall is making durable progress or just generating noise.
• Judge release readiness: keep reviewer verdicts and release checks visible so “probably fine” does not become your deployment methodology.