Altar / Nexus — capabilities & runtime transitions #12

Planning representation replaced — 6 November 2026. The accepted Altar instruments and validated settings outcome is retained in #62. Reopen one bounded task when selected. This closure does not mean the capability is complete or cancelled. The original scope and evidence below remain preserved; current selected work starts at #52.

See configured capabilities and request a supported local runtime transition.

Checklist

• Show Soulstones/Animators, declared models/capabilities and timestamped observed readiness.
• Display relevant non-secret configuration and distinguish declarations from live observations.
• Preview the target, affected runtimes, waiting/drain requirements and blockers.
• Submit an explicit transition through the backend; show its ticket, progress and settled outcome.
• Handle unknown outcomes, refresh and retries without duplicate activation; never control systemd directly from the browser.
• Verify one local activation and clear unavailable/error states. An operator can follow a wait/refusal reason to the same Run and back; model-generated descriptions cannot override timestamped backend observations.

Part of: #9 — later instrument delivery; not a prerequisite for first conversation.
Starting point: reuse the existing screen/contracts and delivery evidence. Verify the named screen journey; share #10's accessibility and error states.

Integration: screen-to-screen links are tested when both destinations are available, not treated as circular implementation blockers.
References: Frontend (ADR 15) · Orchestrator (ADR 23) · Dispatcher (ADR 22).

Contribution entry: Implement or verify one capability/transition display against existing projections.
Verification: UI/API fixtures; one real activation for closure. Shared contribution and touched-docs rules: #52.

Delivery review — 12 October 2026

Published source: a913bff.

Nexus shows declared/observed capability facts and typed transition previews, preserves uncertain request identities and durably reserves admission before launch. UI/API fixtures cover target-specific loading, late-response fencing, containment and no-op refusal. Only admission is durable: a lost process-local ticket cannot prove an outcome or safely relaunch it, and the real activation plus same-Run browser review remains open.

Delivery evidence