[0.12] Adapt the Facility UI to the persistent workspace model

Goal

Keep the Facility UI and adapt it to the persistent workspace model. MCP is the main automation interface, while the UI remains the place where people can see, continue, configure, and clean up work.

Product areas

The UI needs to cover:

• project setup and connected repositories
• the agent catalog loaded from .agents/
• engine, model, reasoning effort, and trigger configuration
• stories and attention state
• the shared conversation and active turn
• workspace, active compute, and retained storage status
• project cost, monthly budget, operational health, delivery analytics, and audit history
• the mirrored GitHub issue, pull request, and CI pipeline
• development services, readiness, and recent logs
• authenticated preview links
• branch, commit, CI, and pull request state
• archive, restore, suspend, and explicit deletion

Remove screens and language that present runs, receipts, proposals, the legacy budget gateway, registry versions, agent permission profiles, or separate preview sandboxes as the current model. Keep project budget controls and cost analysis in the Insights surface.

Agent editing

The catalog shows the repository commit and manifest hash. Editing an agent uses the shared manifest schema and writes the .agents/ file through Git. The UI cannot save an engine, model, prompt, or trigger override in a database row.

The interface should show validation errors before a change is submitted. The implementation decision for direct commit versus pull request belongs to the architecture issue and must be visible to the user.

Story view

The story view combines conversation, typed attention items, worktree branch, pull request, services, preview, artifacts, and workspace status. It shows whether attention came from an agent wait or a recoverable failure, and exposes the reply, retry, and dismiss actions defined by the story model. It should make a running turn visible without requiring the user to read raw logs. It should also provide the logs when setup or execution fails.

After merge or archive, the page still allows restore, conversation access, and workspace wake. It must not imply that durable state was deleted.

Deletion has a separate confirmation that names the workspace and describes the session files, worktree, local data, and previews that will be removed.

Shared behavior

UI actions call the same application services as MCP. Loading the same story through both interfaces should return the same state and available operations.

Keep existing components and navigation where they fit. This work is a product migration, not a visual redesign.

Acceptance criteria

• Users can list and open projects, agents, and stories.
• Agent pages show source commit, engine, model, options, and triggers from .agents/.
• Editing an agent changes the repository file and passes the shared validator.
• Users can start a story, choose an agent, send messages, and follow a running turn.
• Workspace state, active compute, retained storage, services, logs, and preview are visible.
• Insights shows token use, attributed cost, monthly budget state, operational health, delivery analytics, and recent audit activity.
• Pipeline shows the project-scoped GitHub issue, pull request, story, and CI mirror and can request reconciliation.
• Attention items show their type and history, and offer only the resolution actions allowed by the story model.
• Merge and archive views state that sessions and the worktree remain stored.
• Archive and restore keep the same story and workspace identity.
• Explicit deletion names what will be removed and cannot be confused with suspension.
• Legacy run, receipt, budget gateway, proposal, permission profile, and preview sandbox navigation is removed without removing the new project budget controls.
• MCP and UI parity has an integration test.
• Empty, loading, running, attention, failure, done, archived, and deleted states are covered.
• The main flows are verified in a real browser at desktop and narrow widths.

Accessibility

Keyboard use, focus order, labels, status announcements, color contrast, and destructive confirmation must meet STANDARD.md and the repository's existing browser conventions.

Start by mapping the existing Facility UI, navigation, and shared application services, then inspect the .agents/ manifest flow and STANDARD.md. Use the acceptance criteria to define completion: UI and MCP parity, covered lifecycle states, integration and browser verification, and accessible destructive actions.