openrig/docs/releases/v0.5.11.md

OpenRig v0.5.11 — clearer first use, workflows, and everyday operation

Status: release candidate. Publication and final release verification are separate steps.

OpenRig 0.5.11 makes it easier to start useful work in an ordinary repository, understand the team and its workflow in the TUI, and diagnose configuration or lifecycle failures without mistaking uncertain state for success.

First useful work and a shared view

• The first-project starter provides a focused Codex owner/checker pair for one repository. The README follows that path from launch through a useful change, independent checking, and returning to the work.
• A new kernel includes a shared TUI terminal. rig tui --shared attaches to that existing view; plain rig tui opens a standalone view. Joining the shared view does not silently launch a missing terminal or agent.
• Herdr users can follow the same repository and terminal journey. This is preparation for useful operation without a plugin; no Herdr plugin or community-adoption result is part of this release.

Understand work in the ordinary TUI

• Mission views expose workflows, their current step and owner, waits, and the work packet behind a transition. Source navigation connects the view to the authored work and specs.
• Specs presents the declared purpose, including a rig's summary, and distinguishes missing content from a failed read.
• Connections shows the running daemon and CLI identities, effective instance settings, configured and applied gateway state, and registered human routes. It is a passive inspection surface; a configured connector is not proof that a person received a message.
• Command completion, readable Recent activity, and a persistent configurable timezone make daily navigation easier. The default display timezone is America/Los_Angeles.
• A timed-out daemon probe stays unverified throughout the TUI chrome instead of being labeled as a confirmed outage.

More reliable coordination and lifecycle

• Project-owned release profiles provide reusable ceremony and post-release boundary steps. Current-release closure does not depend on inventing a successor mission. Agents still judge the evidence behind each obligation.
• Workflow exception recovery preserves the correct owner and clears resolved exception state. Stuck-work findings retain the source evidence needed to route them honestly.
• Terminal delivery preserves long authored context; paced-walk verification checks the intended piece and the applicable runtime/generation record. Delivery and native-turn completion remain distinct from comprehension.
• Context profile and work-install commands accept consistent Claude runtime spellings (claude-code and claude) alongside codex, with invalid explicit values rejected before projection.
• Startup uses the selected authored proof. It does not add an unrequested exercise, and terminal-only members do not receive agent proof challenges.
• Daemon shutdown has a bounded budget and an attributed outcome receipt. Failed or missing receipts remain visible on the supported stop paths.
• Daemon startup binds success and state publication to its actual child, handles competing starts, and retains uncertainty when child liveness cannot be established. Cross-host request attribution identifies the origin independently of the selected destination.

Operator notes

Root, CLI, daemon, and web-UI package versions are 0.5.11. The terminal TUI retains its independent 0.1.0 package version. Node requirements are unchanged. The ordered database migration head remains 079_workflow_lifecycle_parallel; this release adds no migration beyond the 0.5.10 source baseline.

Diagnosis show and list now return summary-depth --json, retaining current state and decisions while identifying omitted evidence. Consumers needing the complete record must use --full --json, or execute the printed expansion command. Queue show retains its 512-codepoint body preview and adds explicit size, completeness, and expansion metadata. HTTP responses and mutation JSON remain complete. These defaults are not a global output-size cap.

Use the supported upgrade procedure with a database backup and continuity checks. A daemon restart and a rig shutdown have different effects; the latter stops seats. Existing kernels are not automatically rebuilt to acquire the new shared terminal.

Validation scope and limitations

The candidate retains earlier isolated, installed-package evidence for the connected first-project/workflow/TUI journey and focused verification of the purpose and unverified-state corrections. Those earlier runs are attributed prior evidence, not new end-to-end or provider enrollment tests for this cut. Package identity and bounded installed rendering checks accompany candidate preparation; exact-cut substance and final release verification remain required before publication.

• First-use evidence includes fresh re-entry; it does not establish same-conversation resume or complete mixed-runtime enrollment.
• Controlled Connections evidence and passive inspection do not establish external human delivery. Transient probe latency and delayed view population remain observed qualifications, with no universal responsiveness claim.
• Authored completion, legacy provenance, and proof pairing are separate readers. Updating a declaration does not create missing provenance or an execution-wave history.
• A bounded health-analysis proof of concept produced an attributed diagnosis and exited. It is research evidence, not a shipped cold-agent/run API, provider abstraction, or proof of a cost or latency advantage over residency.