mirror of
https://github.com/mvschwarz/openrig.git
synced 2026-10-02 00:27:21 +08:00
docs: scrub internal-facing jargon from 0.4.7 / 0.4.8 / 0.5.0 release notes
Follow-up to a310c161 (the docs backfill for 0.4.7 / 0.4.8 / 0.5.0).
The backfilled release-notes surfaces (CHANGELOG entries +
docs/releases/*.md files + GitHub Release bodies) inherited more
internal-workstream jargon from the source commit-body prose than
should ship on user-facing surfaces.
Removed from all three surfaces:
- slice numbers as identifiers (e.g. "slice-12 gates policy")
- issue / seal codes (e.g. "GAP-7 seal CLEAR b7f4cb7d")
- tier / stage classifications (e.g. "Tier-A skill",
"maturation-gated", "0.5.2-lane")
- internal workflow terms (e.g. "back-merge", "release-artifact
history", "working lineage", "fold-wave enumeration", "census not
damage", "delivery-free-noun ruling", "post-cut docs pass",
"sibling of the slice-03 omission")
- internal module / function names (e.g. deliverInitialSessionPrompt,
permission-policy-discovery)
- internal API field names as bare tokens without a plain-language
gloss (lifecycleState / sessionStatus / attention_required /
session_missing)
Kept (still user-facing, still user-configurable):
- policy names: locked / standard / open / yolo / none
- config keys: dontAsk / acceptEdits / bypassPermissions /
--permission-mode / --policy / --context / --body-context
- CLI verbs and flags: rig context / rig walk / rig setup --policy /
rig ps / rig send / rig broadcast / rig scope slice approve
--re-approve --reason
- concrete file paths: ~/.claude/settings.json / config.toml /
docs/reference/developing.md
- Bash-rule patterns as they appear in Claude settings:
Bash(git push:*) / Bash(rig down:*)
Both the docs/releases/*.md files in this repo and the GitHub Release
bodies for v0.4.7 / v0.4.8 / v0.5.0 have been scrubbed to the same
content this commit lands. The older CHANGELOG entries (0.4.6 and
earlier) are left untouched — this pass targets the 0.4.7 / 0.4.8 /
0.5.0 backfill only.
The corresponding release-manager skill in the shared conventions
layer has been updated with an anti-jargon rule under Anti-patterns
so future release-notes writing catches this class before it ships;
that skill change lands separately in the substrate.
This commit is contained in:
mvschwarz
+63
-63
@@ -10,53 +10,53 @@ deprecations, and behavioral changes. Breaking changes are called out explicitly
|
||||
|
||||
## [0.5.0] - 2026-08-06
|
||||
|
||||
**Status**: shipped; mission control TUI + context library + permission-policy built-ins + provider usage observability + plan amendment + honest CLI + build discipline. **0.5.0 contains 0.4.8 in full** via the back-merge that reconciles the 0.4.8 release-artifact history with the 0.5.0 working lineage.
|
||||
**Status**: shipped; mission control TUI + context library + permission-policy built-ins + provider usage observability + plan amendment + honest CLI + build discipline. **v0.5.0 includes everything from v0.4.8** — there is no divergence between the two releases.
|
||||
|
||||
### Summary For Installing Agents
|
||||
|
||||
- **Package version**: bumps from `0.4.8`.
|
||||
- **Migrations**: additive only.
|
||||
- **Node engines**: unchanged.
|
||||
- **New bundled skills**: `applying-a-permission-policy` and `delegating-work` join the shipped set alongside the 0.4.8 skills. Two additional 0.5.2-lane maturation-gated skills (`retiring-and-inheriting-a-seat` and `oversight-team`) sit in the oracle at draft stage and are correctly deferred to a later release per the maturation-gate contract.
|
||||
- **Behavior change**: `rig.yaml` startup `context_pack` entries are no longer delivered at instantiation — they are rejected with a teaching error pointing at `rig context compose` + delivery verbs.
|
||||
- **New bundled skills**: `applying-a-permission-policy` and `delegating-work` join the shipped set alongside the v0.4.8 skills. Two additional skills (`retiring-and-inheriting-a-seat` and `oversight-team`) are still at draft stage and will land in a future release once they mature.
|
||||
- **Behavior change**: `rig.yaml` startup `context_pack` entries are no longer delivered at instantiation — they are rejected with a teaching error pointing at `rig context compose` + a delivery command.
|
||||
|
||||
### Headline
|
||||
|
||||
**Mission control in the terminal + context library + permission-policy built-ins.** Typing `rig` (or `rig tui`) opens the new TUI: file-tree navigator, dense agent detail (cwd, runtime as text, context %), topology graph with the whole fleet on one screen, honest status/activity language, motion design, working scrolling, and honest width-clip/scope indicators throughout. The context library ships as a first-class store-and-compose noun (`rig context`) with paced delivery via `rig walk` and attached-context on `send` / `broadcast` / `queue create` via `--context` / `--body-context`. The 0.4.8 permission-policy framework gets its **five built-in templates** (`locked | standard | open | yolo | none`) + an agent-driven translator skill.
|
||||
**Mission control in the terminal + context library + permission-policy built-ins.** Typing `rig` (or `rig tui`) opens the new TUI: file-tree navigator, dense agent detail (working directory, runtime, context %), a topology graph with the whole fleet on one screen, honest status/activity language, motion design, working scrolling, and honest width-clip indicators throughout. The context library ships as a first-class store-and-compose noun (`rig context`) with paced delivery via `rig walk` and attached-context on `rig send` / `rig broadcast` / `rig queue create` via `--context` / `--body-context`. The v0.4.8 permission-policy foundation gets its **four built-in templates** (`locked`, `standard`, `open`, `yolo`) plus `none` as a deliberate no-policy choice, plus an agent-driven translator skill.
|
||||
|
||||
### Permission policies — built-in templates + custom + agent-driven translation
|
||||
|
||||
Building on the v0.4.8 policy-spec system, v0.5.0 ships the built-in policy templates + the skill that applies them:
|
||||
Building on the v0.4.8 permission-policy foundation, v0.5.0 ships the built-in policy templates plus the skill that applies them:
|
||||
|
||||
- **Five built-in policy templates**: `locked`, `standard`, `open`, `yolo`, `none`. Read-only from the package; copy to customize.
|
||||
- **`rig setup --policy <name>`** — records the chosen policy into a rig spec. Takes a built-in name or a path to a custom policy file (`source: custom`).
|
||||
- **`applying-a-permission-policy` (bundled Tier-A skill)** — reads the policy spec at rig setup / preflight, grounds itself in the seat's current harness version (Claude 2.1.220 / Codex 0.120.0 / Pi 0.83.0 at ship time), shows the concrete diff before writing, and lands the config into Claude `~/.claude/settings.json` and/or Codex `config.toml`. Never blind writes.
|
||||
- **Two surfaces (unchanged from v0.4.8)** — LAUNCH-FLAG (stable, OpenRig-set deterministically): the FLOOR (Claude `acceptEdits`, Codex workspace-write) and YOLO (Claude `--dangerously-skip-permissions`, Codex full-bypass). CONFIG-FILE (chaotic, translated per harness version by the skill): the allow/ask/deny rules.
|
||||
- **Deterministic vs best-effort** — LAUNCH-FLAG floor + YOLO are deterministic. Fine-grained CONFIG-FILE rule translation is best-effort; the skill surfaces prefix-collision, target-first leaks, and Claude-only network-egress non-enforceability to the operator honestly via the diff-before-write flow.
|
||||
- **Four built-in policy templates**: `locked`, `standard`, `open`, `yolo`. Read-only from the package; copy to customize. Plus `none` as a deliberate no-policy choice.
|
||||
- **`rig setup --policy <name>`** — records the chosen policy into a rig spec. Takes a built-in name (`locked | standard | open | yolo | none`) or a path to a custom policy file (custom policies live as `.policy.md` files you author).
|
||||
- **`applying-a-permission-policy`** (bundled skill) — reads the policy spec at rig setup / preflight, checks the seat's current harness version, shows the concrete diff before writing, and lands the config into Claude `~/.claude/settings.json` and/or Codex `config.toml`. Never blind writes. Agent-driven on purpose — harness permission formats change frequently across versions, so a deterministic writer would break the moment the harness surface shifts.
|
||||
- **Two surfaces**: the **launch-flag** surface (Claude `--permission-mode`, Codex sandbox/bypass, Pi `--approve` / `--no-approve`) is stable and OpenRig-set for you — the floor (Claude `acceptEdits`, Codex workspace-write) and the full-bypass YOLO mode live here. The **config-file** surface (Claude `~/.claude/settings.json`, Codex `config.toml`) is where allow/ask/deny rules live and where the skill applies your chosen policy.
|
||||
- **Deterministic vs best-effort**: the launch-flag floor and YOLO are deterministic. Fine-grained config-file rules are best-effort because harness rule grammars vary; the skill surfaces the caveats (prefix collisions, target-first leaks, Claude's lack of a native network gate) via the diff-before-write flow. If a translation is uncertain, hand-editing the harness's own settings file — or falling back to YOLO / floor as blunt instruments — remains a valid path.
|
||||
|
||||
### Permission guarantee, now test-pinned
|
||||
### Permission-writer guarantee, now test-pinned
|
||||
|
||||
- **OpenRig writes zero permission entries into your `~/.claude/settings.json`** — pinned by a permanent guard test plus an empty-writer sweep. The one sanctioned exception is the project-local `acceptEdits` floor that 0.4.8 itself defines.
|
||||
- **Warning ordering in `permission-policy-discovery`** — emits pre-existing main-floor warnings first, then the permission-policy attachment warning. Presentation-only; semantic fence unchanged.
|
||||
- **OpenRig writes zero permission entries into your `~/.claude/settings.json`** — pinned by a permanent guard test plus an empty-writer sweep. The one sanctioned exception is the project-local `acceptEdits` floor that v0.4.8 itself defines.
|
||||
- **Warning ordering during permission-policy discovery** — pre-existing main-floor warnings emit first, then the permission-policy attachment warning. Presentation-only; semantic fence unchanged.
|
||||
|
||||
### Context library
|
||||
|
||||
- **`rig context`** — stores and composes context packs. Nouns store and compose; `rig context` never delivers.
|
||||
- **`rig context`** — stores and composes context packs. Nouns store and compose; `rig context` never delivers on its own.
|
||||
- **`rig walk`** — delivers a stored context pack paced.
|
||||
- **`--context` / `--body-context`** — attach a stored context pack (by ref) to `rig send`, `rig broadcast`, or `rig queue create`. Snapshot + provenance preserved.
|
||||
- **Grammar (strict)**: nouns store and compose; verbs deliver. The 0.4.x context-window usage viewer is removed; the `rig context` name now belongs to the library.
|
||||
- **`--context` / `--body-context`** — attach a stored context pack (by reference) to `rig send`, `rig broadcast`, or `rig queue create`. Snapshot + provenance preserved.
|
||||
- **Grammar (strict)**: nouns store and compose; verbs deliver. The old v0.4.x context-window usage viewer is removed; the `rig context` name now belongs to the library.
|
||||
|
||||
### Behavior change (0.4.8 → 0.5.0)
|
||||
### Behavior change (v0.4.8 → v0.5.0)
|
||||
|
||||
- **`rig.yaml` startup `context_pack` entries are no longer delivered at instantiation.** They are rejected with a teaching error pointing at `rig context compose` + a delivery verb (`rig send --context`, `rig broadcast --context`, `rig walk`, or `--context` / `--body-context` on `queue create`). The bundle router populates the library store without delivering (delivery-free-noun ruling applied at the startup surface). Users who adopted startup `context_pack` on 0.4.8 (shipped days ago; tiny exposure) should migrate to the compose + delivery-verb pattern.
|
||||
- **`rig.yaml` startup `context_pack` entries are no longer delivered at instantiation.** They are rejected with a teaching error pointing at `rig context compose` + a delivery command (`rig send --context`, `rig broadcast --context`, `rig walk`, or `--context` / `--body-context` on `rig queue create`). The bundle router still stores the pack; it just doesn't auto-deliver it at startup. Users who adopted startup `context_pack` on v0.4.8 (shipped days ago; small window) should migrate to the compose + delivery-command pattern.
|
||||
|
||||
### Provider usage observability
|
||||
|
||||
- **`GET /api/provider/usage`** + **`rig provider status`** — the daemon tracks account-level usage per host so operators can answer "am I about to hit a usage limit". Honest explicit-unknown and conflict-shows-both-facts semantics. Codex account-switch flows preserved.
|
||||
- **`GET /api/provider/usage`** + **`rig provider status`** — the daemon tracks account-level usage per host so operators can answer "am I about to hit a usage limit". Explicit-unknown when the provider doesn't report it; conflict-shows-both-facts when signals disagree. Codex account-switch flows are preserved.
|
||||
|
||||
### Plan amendment done right
|
||||
|
||||
- **`rig scope slice approve --re-approve --reason "..."`** — re-stamps a locked plan with an append-only audit trail, killing the old `already_approved` Status-note workaround.
|
||||
- **`rig scope slice approve --re-approve --reason "..."`** — re-stamps a locked plan with an append-only audit trail, replacing an earlier workaround where an already-approved status forced a Status-note edit.
|
||||
|
||||
### Honest CLI output
|
||||
|
||||
@@ -66,21 +66,21 @@ Building on the v0.4.8 policy-spec system, v0.5.0 ships the built-in policy temp
|
||||
|
||||
### Build discipline
|
||||
|
||||
- **Contributor gates/lanes SSOT** lives at `docs/reference/developing.md` (encoded by the slice-12 gates policy).
|
||||
- **Contributor gates and lanes** have a single source of truth at `docs/reference/developing.md`.
|
||||
|
||||
### UI status (unchanged from v0.4.7)
|
||||
|
||||
- **Web UI remains in maintenance mode** as introduced in v0.4.7 — still ships, still runs, no new feature work. CLI/TUI is the primary surface; v0.5.0's TUI (`rig` / `rig tui`) is where mission-control investment lands. Never "deprecated"; existing deployments continue to work.
|
||||
- **Web UI remains in maintenance mode** as introduced in v0.4.7 — still ships, still runs, no new feature work. CLI/TUI is the primary surface; v0.5.0's TUI (`rig` / `rig tui`) is where mission-control investment lands going forward. The UI is not deprecated and not removed; existing deployments continue to work.
|
||||
|
||||
### Known Issues
|
||||
|
||||
- **GAP-7 Codex-`HOME` product fix** (seal CLEAR `b7f4cb7d`) — accepted with fold-rides-release-sequencing but fell off the fold-wave enumeration and is **NOT in released 0.5.0 by content**. Ships in 0.5.1 as a ready-accepted early bugfix atom. Class: sibling of the slice-03 omission, caught by census not damage. Until 0.5.1 lands, the deployment invariant from v0.4.8 (daemon `HOME` == seat tmux `HOME`) remains the operator-side workaround for the permission-posture writes to reach Codex seats.
|
||||
- **Codex `HOME` fix not landed in v0.5.0** — a permission-posture fix that ensures the daemon and Codex seats agree on the `HOME` environment (so the posture writes reach the seat) was accepted for v0.5.0 but was inadvertently omitted from the shipped build. It ships as an early bug-fix in v0.5.1. In the meantime, the v0.4.8 deployment note applies: **the daemon's `HOME` must equal the seat's tmux `HOME`** for the permission-posture writes to reach Codex seats — verify this on any remote-host upgrade.
|
||||
|
||||
---
|
||||
|
||||
## [0.4.8] - 2026-08-05
|
||||
|
||||
**Status**: shipped; permission-posture fast-follow + permission-policy framework.
|
||||
**Status**: shipped; permission-posture fast-follow + permission-policy foundation.
|
||||
|
||||
### Summary For Installing Agents
|
||||
|
||||
@@ -91,80 +91,80 @@ Building on the v0.4.8 policy-spec system, v0.5.0 ships the built-in policy temp
|
||||
|
||||
### Headline
|
||||
|
||||
**Permission-posture fast-follow + permission-policy framework.** Launch posture is configurable, the deny set is clobber-resistant, and dangerous ops are bounded by an honest prefix-gate. The **permission-policy spec framework** (harness-neutral schema + `rig setup --policy` flag) lands as the foundation the built-in templates + `applying-a-permission-policy` skill ride on top of in v0.5.0.
|
||||
**Permission-posture fast-follow + permission-policy foundation.** Launch posture is configurable, the deny set writes at a level project-local approvals can't override, and dangerous operations are gated by explicit prefix rules that actually hold under the current Claude harness. The **permission-policy foundation** (harness-neutral schema + `rig setup --policy` flag) lands as the framework the built-in templates + `applying-a-permission-policy` skill ride on top of in v0.5.0.
|
||||
|
||||
### Configurable launch posture
|
||||
|
||||
- **`--permission-mode` no longer hardcoded** — replaced by a configurable posture defaulting to `dontAsk`. This kills the ask-hang / freeze class that could park an autonomous seat on a modal permission prompt with nobody to click through it. `dontAsk` is the default because it matches what an autonomous seat can actually respond to; `acceptEdits` remains selectable when a seat needs the prior behavior.
|
||||
- **`--permission-mode` no longer hardcoded** — replaced by a configurable posture defaulting to `dontAsk`. This closes the class of freezes where an autonomous seat could get stuck on a modal permission prompt with nobody to click through it. `dontAsk` is the default because it matches what an autonomous seat can actually respond to; `acceptEdits` remains selectable when a seat needs the prior behavior.
|
||||
|
||||
### Clobber-resistant deny set
|
||||
### Deny set that project-local approvals can't override
|
||||
|
||||
- **Writes go to user-level `~/.claude/settings.json`** instead of the project-local one-off approval surface — so **deny wins over project-local approvals**. Writes are additive (never destructive to sibling keys) and forward-migrate a legacy `acceptEdits` value into the new schema. A deliberate `bypassPermissions` value is preserved verbatim.
|
||||
- **Writes go to user-level `~/.claude/settings.json`** instead of the project-local approval file — so **deny wins over project-local approvals**. Writes are additive (never destructive to sibling keys) and forward-migrate a legacy `acceptEdits` value into the new schema. A deliberate `bypassPermissions` value is preserved.
|
||||
|
||||
### Bounded-dangerous deny set
|
||||
|
||||
- **Four bounded-dangerous ops gated by default**: `git push`, `gh pr create`, `npm publish`, and `rig down`.
|
||||
- **`rig down` gate via prefix superset `Bash(rig down:*)`** — harness rules at Claude 2.1.220 are prefix-only; flag-only patterns provably fail to gate target-first forms such as `rig down <rig> --force`, which were slipping through. The prefix gate is the only shape that actually holds at this harness version. Plain `rig down` is gated in 0.4.8; selective allowance (e.g. `rig down <rig>` for a specific target) is deferred to 0.5.0 server-side enforcement.
|
||||
- **Four dangerous operations gated by default**: `git push`, `gh pr create`, `npm publish`, and `rig down`.
|
||||
- **`rig down` gated via the prefix rule `Bash(rig down:*)`** — the current Claude harness (2.1.220) only supports prefix matches on Bash rules, and flag-only patterns provably don't gate target-first forms such as `rig down <rig> --force`. The prefix rule is the only shape that actually holds. Plain `rig down` is gated in v0.4.8; selective allowance (e.g. `rig down <rig>` for a specific target) is deferred to v0.5.0 server-side enforcement.
|
||||
|
||||
### `rig up` un-gated
|
||||
|
||||
- **`rig up`'s prior release ask-gate is superseded** — `rig up` is a reversible op and does not warrant an interactive gate.
|
||||
- **The prior release's ask-gate on `rig up` is removed** — `rig up` is a reversible operation and doesn't warrant an interactive gate.
|
||||
|
||||
### Permission-policy framework (foundation for the 0.5.0 built-ins + skill)
|
||||
### Permission-policy foundation (built-ins land in v0.5.0)
|
||||
|
||||
- **Harness-neutral policy schema** — the permission-policy spec ships as a harness-neutral surface with `default_posture`, `floor`, `allow`/`ask`/`deny` as **semantic actions** (`push_to_remote`, `force_push`, `delete_files`, `read_secrets`, `create_pr`, `publish_package`, `mutate_topology`, ...), `destructive_class`, and a `source: builtin|custom` marker.
|
||||
- **`rig setup --policy <name>`** — new flag on `rig setup` records a deliberate permission-policy choice into an existing rig spec. Takes a built-in name or a path to a custom spec. The **built-in policy files themselves land in v0.5.0**; 0.4.8 ships the framework that consumes them.
|
||||
- **Two surfaces documented** — LAUNCH-FLAG (Claude `--permission-mode`, Codex sandbox/bypass, Pi `--approve` / `--no-approve`) is stable and OpenRig-set deterministically — this is where the FLOOR and YOLO live. CONFIG-FILE (Claude `~/.claude/settings.json`, Codex `config.toml`) is chaotic across harness versions and translated interactively per harness version by an agent-driven skill (that skill lands as `applying-a-permission-policy` in v0.5.0).
|
||||
- **Harness-neutral policy schema** — the permission-policy spec is a harness-neutral surface with `default_posture`, `floor`, and `allow` / `ask` / `deny` expressed as **semantic actions** (`push_to_remote`, `force_push`, `delete_files`, `read_secrets`, `create_pr`, `publish_package`, and so on) rather than raw shell-command patterns.
|
||||
- **`rig setup --policy <name>`** — a new flag on `rig setup` records a permission-policy choice into an existing rig spec. Takes a built-in name or a path to a custom policy file. The **built-in policy files themselves land in v0.5.0**; v0.4.8 ships the framework that consumes them.
|
||||
- **Two surfaces**: the **launch-flag** surface (Claude `--permission-mode`, Codex sandbox / bypass flags, Pi `--approve` / `--no-approve`) is stable and OpenRig-set for you — the floor and full-bypass YOLO live here. The **config-file** surface (Claude `~/.claude/settings.json`, Codex `config.toml`) is where allow/ask/deny rules live; because harness rule grammars change frequently across versions, this surface is applied interactively by an agent-driven skill (that skill ships in v0.5.0 as `applying-a-permission-policy`).
|
||||
|
||||
### Deployment Invariant (operators read this)
|
||||
### Deployment Note (operators read this)
|
||||
|
||||
- **The daemon's `HOME` must equal the seat's tmux `HOME`** for the posture writes to reach seats. This is a 2.1.220 settings-path class invariant that operators need to know for the remote-host leg of any upgrade. Local-only hosts satisfy this automatically; remote-host upgrades should verify HOME parity between the daemon process and the tmux seat process before treating the upgrade as complete. (v0.5.0 documents this as a Known Issue for Codex-`HOME` divergence via GAP-7; the product fix ships in 0.5.1.)
|
||||
- **The daemon's `HOME` must equal the seat's tmux `HOME`** for the posture writes to reach seats. This is a Claude 2.1.220 settings-path invariant that matters for the remote-host leg of any upgrade. Local-only hosts satisfy this automatically; remote-host upgrades should verify HOME parity between the daemon process and the tmux seat process before treating the upgrade as complete. (v0.5.0 documents this as a Known Issue for Codex `HOME` divergence; the product fix ships in v0.5.1.)
|
||||
|
||||
### Superseded / Withdrawn
|
||||
### Superseded
|
||||
|
||||
- **Initial 0.4.8 attempt withdrawn pre-cut on final review** — the initial attempt baked `dontAsk` as a **platform default** across the product surface, which was rejected. The shipped 0.4.8 is a re-scoped permission-agnostic base + policy-spec system. Nothing from the withdrawn attempt shipped.
|
||||
- **An initial v0.4.8 attempt was withdrawn on final review** — it baked `dontAsk` as a **platform default** rather than an OpenRig-side default. The shipped v0.4.8 is a re-scoped permission-agnostic base plus a policy-spec system. Nothing from the withdrawn attempt shipped.
|
||||
|
||||
---
|
||||
|
||||
## [0.4.7] - 2026-08-03
|
||||
|
||||
**Status**: shipped; recovery honesty + starter bootstrap + skills wave + Slack connector + UI maintenance-mode.
|
||||
**Status**: shipped; recovery honesty + starter bootstrap + skills wave + Slack connector + UI maintenance-mode milestone.
|
||||
|
||||
### Summary For Installing Agents
|
||||
|
||||
- **Package version**: bumps from `0.4.6`.
|
||||
- **Migrations**: additive only. Existing v0.4.6 databases upgrade by running `rig daemon start` on the new daemon.
|
||||
- **Node engines**: unchanged.
|
||||
- **Rig-spec starter behavior change**: rigs instantiated before 0.4.7 need re-instantiation (or spec-level patching) to pick up the starter fixes — the loader and audit changes apply immediately, but starter-spec content lands at instantiation.
|
||||
- **Rig-spec starter behavior change**: rigs instantiated before v0.4.7 need re-instantiation (or spec-level patching) to pick up the starter fixes — the loader and audit changes apply immediately, but starter-spec content lands at instantiation.
|
||||
- **Web UI**: frozen in maintenance mode at this release (see below).
|
||||
|
||||
### Headline
|
||||
|
||||
**Recovery honesty is the through-line.** On a resumed restore, the startup orchestrator now bundles the applicable `after_ready` `send_text` preload action(s) in front of the first `send_text` post-launch file (`role.md`) and delivers them as the single leading turn — sequencing (not timing) guarantees the "load skills before doing anything" preload precedes the role-triggered first turn (the restore analogue of `deliverInitialSessionPrompt`'s fresh identity+`role.md` bundle). Compaction recovery and transcript ingest are honest; daemon liveness reporting is honest; CLI probes report uncertainty honestly. Alongside recovery, the release lands starter bootstrap hygiene, a broad skills-inventory wave, a first-class Slack connector, tightened CLI contract honesty, and the **UI maintenance-mode milestone** (CLI is primary from here forward).
|
||||
**Recovery honesty is the through-line.** On a resumed restore, the startup sequence now loads a seat's applicable skill preloads before the role-defining first message — so a resuming seat knows its skills before it starts working. Compaction recovery is honest: transcript ingest exposes degraded states explicitly, and a post-compact restore-and-audit is gated on the seat being idle so "restore-sent" actually means "delivered". Daemon liveness reporting is honest; CLI probes report uncertainty honestly. Alongside recovery, the release lands starter-bootstrap hygiene, a broad skills-inventory wave, a first-class Slack connector, tightened CLI contract honesty, and the **UI maintenance-mode milestone** (CLI is primary from here forward).
|
||||
|
||||
### Recovery honesty
|
||||
|
||||
- **Startup orchestrator preload bundling** — on a resumed restore, applicable `after_ready` `send_text` preload actions are bundled in front of the first `send_text` post-launch file (`role.md`) and delivered as the single leading turn. Sequencing guarantees the "load skills before doing anything" preload precedes the role-triggered first turn.
|
||||
- **Claude transcript ingest** — fixed with explicit degraded signals so a stale capture no longer looks like a quiet transcript.
|
||||
- **Post-compact restore/audit is idle-gated** — restore-sent actually means delivered.
|
||||
- **Seat liveness API** — consumers should key seat liveness off `lifecycleState` (honest ~3s) rather than `sessionStatus` (staleness cleanup tracked for a subsequent release).
|
||||
- **Daemon `rig ps` + daemon-status** — report liveness honestly: a dead tmux seat drops effective running to 0 with `attention_required`; `send` and `capture` return `session_missing` when the seat is gone.
|
||||
- **CLI probes report uncertainty honestly** — unconfirmable status returns `UNKNOWN` with no false start advice; confirmed-stopped still `FAIL`s with guidance.
|
||||
- **Startup skill-preload ordering** — on a resumed restore, applicable skill preloads are loaded before the seat's role-defining first message. The sequencing (not timing) guarantees the "load skills before doing anything" preload arrives first, before the seat starts working from its role.
|
||||
- **Claude transcript ingest** — exposes degraded states explicitly so a stale capture no longer looks like a quiet transcript.
|
||||
- **Post-compact restore-and-audit is idle-gated** — restore-sent actually means delivered.
|
||||
- **Seat-liveness API** — consumers should key seat liveness off the honest lifecycle state (updated every few seconds) rather than the older session-status field, whose staleness cleanup is tracked for a subsequent release.
|
||||
- **Daemon `rig ps` + daemon-status** — report liveness honestly: a dead seat drops effective running to 0 and reports `attention_required`; `rig send` and `rig capture` return an explicit "session missing" error when the seat is gone.
|
||||
- **CLI probes report uncertainty honestly** — unconfirmable status returns `UNKNOWN` with no false start advice; confirmed-stopped fails with actionable guidance.
|
||||
|
||||
### Starter bootstrap
|
||||
|
||||
- **Product-team starter bootstrap hygiene** — plus product-team `send_text` skill-preload on `fresh_start` and `restore`.
|
||||
- **Product-team starter bootstrap hygiene** — plus a skill-preload for starter seats on both fresh-start and restore.
|
||||
- **Default culture loads at startup** — rig specs are audited at load time.
|
||||
- **Rig-spec migration path** — rigs instantiated before 0.4.7 need re-instantiation (or spec-level patching) to pick up the starter fixes; loader and audit changes apply immediately, but starter-spec content lands at instantiation.
|
||||
- **Rig-spec migration path** — rigs instantiated before v0.4.7 need re-instantiation (or spec-level patching) to pick up the starter fixes; loader and audit changes apply immediately, but starter-spec content lands at instantiation.
|
||||
|
||||
### Skills wave
|
||||
|
||||
- **Bundled skill layer** — gains public routing + a default projection, plus public-skill strip and mirror controls, plus a plugin fix that keeps the documented skill count honest.
|
||||
- **Vendored skill inventory** — canonical, shared, and bundled plugin — grows from a handful to broad coverage across core, PM, pod, and process families.
|
||||
- **Bundled skill inventory** — grows substantially, from a handful to broad coverage across core, PM, pod, and process families.
|
||||
|
||||
### Slack connector + human queue
|
||||
|
||||
- **First-class Slack connector shape** — CLI `commands/slack.ts` + supporting library. Hosted create crosses an inconclusive local probe to the real configured-daemon result.
|
||||
- **First-class Slack connector** — CLI `rig slack` commands + supporting library. Hosted create crosses an inconclusive local probe to the real configured-daemon result.
|
||||
|
||||
### CLI contract honesty
|
||||
|
||||
@@ -173,25 +173,25 @@ Building on the v0.4.8 policy-spec system, v0.5.0 ships the built-in policy temp
|
||||
### UI — moved to maintenance mode (milestone)
|
||||
|
||||
- **The web UI is frozen at this release in maintenance mode.** Wording is CLI-primary — never "deprecated". The UI still ships and still runs; it is no longer receiving new feature work. CLI/TUI is the primary surface going forward.
|
||||
- What lands in 0.4.7 to make this explicit:
|
||||
- What lands in v0.4.7 to make this explicit:
|
||||
- A dismissible in-app banner in the web UI announcing the maintenance-mode status.
|
||||
- A `rig ui open` stderr notice at launch time, so operators driving the CLI see the status before they open the browser.
|
||||
- Documentation positioning updated across README / user-facing docs.
|
||||
- Existing 0.4.6 deployments keep working; nothing is removed. The substantive product investment shifts to the CLI and, from v0.5.0, the terminal TUI.
|
||||
- Documentation positioning updated across README and user-facing docs.
|
||||
- Existing v0.4.6 deployments keep working; nothing is removed. The substantive product investment shifts to the CLI and, from v0.5.0, the terminal TUI.
|
||||
|
||||
### Queue, topology, review polish
|
||||
|
||||
- **Queue compact-list rows** mark elided fields so *omitted* is not *empty*.
|
||||
- **Nested Approve** posts a missions-root-relative `scopePath`.
|
||||
- **Mission review card composition** is polished.
|
||||
- **Unverified delivered items** read `artifact-recorded` rather than "nothing delivered".
|
||||
- **Drawer `FileViewer`** resolves inline C1-body images via `/api/files/asset`.
|
||||
- **Proof-of-work Markdown links** open in the in-app drawer.
|
||||
- **Docs guard** encodes the ratified `docs/DESIGN.md` root placement.
|
||||
- Queue compact-list rows mark elided fields so "omitted" is distinguishable from "empty".
|
||||
- Nested Approve posts a missions-root-relative scope path.
|
||||
- Mission review card composition is polished.
|
||||
- Unverified delivered items read "artifact-recorded" rather than "nothing delivered".
|
||||
- The drawer file viewer resolves inline in-body images via the file-asset API.
|
||||
- Proof-of-work Markdown links open in the in-app drawer.
|
||||
- Docs guard encodes the root-placement rule for `docs/DESIGN.md`.
|
||||
|
||||
### Host sizing guidance
|
||||
|
||||
- **Swap + per-box seat budget** — add swap and a sane per-box seat budget (~2GB RSS per seat observed baseline).
|
||||
- **Swap + per-box seat budget** — recommended: add swap on the host, and plan for roughly ~2 GB RSS per seat as an observed baseline.
|
||||
|
||||
---
|
||||
|
||||
|
||||
+23
-66
@@ -4,101 +4,58 @@
|
||||
|
||||
## Summary — Recovery honesty + starter bootstrap + skills wave + Slack connector + UI maintenance-mode
|
||||
|
||||
Recovery honesty is the through-line. On a resumed restore, the startup
|
||||
orchestrator now bundles the applicable `after_ready` `send_text` preload
|
||||
action(s) in front of the first `send_text` post-launch file (`role.md`) and
|
||||
delivers them as the single leading turn — sequencing (not timing) guarantees
|
||||
the "load skills before doing anything" preload precedes the role-triggered
|
||||
first turn (the restore analogue of `deliverInitialSessionPrompt`'s fresh
|
||||
identity+`role.md` bundle). Compaction recovery and transcript ingest are
|
||||
honest: Claude transcript ingest is fixed with explicit degraded signals; a
|
||||
post-compact restore/audit is idle-gated so restore-sent actually means
|
||||
delivered. Consumers should key seat liveness off `lifecycleState` (honest
|
||||
~3s) rather than `sessionStatus` (staleness cleanup tracked for a subsequent
|
||||
release). Daemon `rig ps` and daemon-status report liveness honestly — a
|
||||
dead tmux seat drops effective running to 0 with `attention_required`; `send`
|
||||
and `capture` return `session_missing` when the seat is gone. CLI probes
|
||||
report uncertainty honestly — unconfirmable status returns `UNKNOWN` with no
|
||||
false start advice, and confirmed-stopped still `FAIL`s with guidance.
|
||||
**Recovery honesty is the through-line.** On a resumed restore, the startup sequence now loads a seat's applicable skill preloads before the role-defining first message — so a resuming seat knows its skills before it starts working. Compaction recovery is honest: transcript ingest exposes degraded states explicitly, and a post-compact restore-and-audit is gated on the seat being idle so "restore-sent" actually means "delivered". Daemon liveness reporting is honest — a dead seat drops effective running to 0 and reports `attention_required`; `rig send` and `rig capture` return an explicit "session missing" error when the seat is gone. CLI probes report uncertainty honestly — an unconfirmable status returns `UNKNOWN` with no false start advice, and a confirmed-stopped seat fails with actionable guidance.
|
||||
|
||||
Migrations are additive only. Existing v0.4.6 databases upgrade by running
|
||||
`rig daemon start` on the new daemon.
|
||||
Migrations are additive only. Existing v0.4.6 databases upgrade by running `rig daemon start` on the new daemon.
|
||||
|
||||
## What Shipped
|
||||
|
||||
### Starter bootstrap
|
||||
|
||||
Product-team starter bootstrap hygiene, plus product-team `send_text` skill-
|
||||
preload on `fresh_start` and `restore`. Default culture loads at startup, and
|
||||
rig specs are audited at load time. Rigs instantiated **before** 0.4.7 need
|
||||
re-instantiation (or spec-level patching) to pick up the starter fixes — the
|
||||
loader and audit changes apply immediately, but starter-spec content lands
|
||||
at instantiation.
|
||||
Product-team starter bootstrap is cleaner, and starter seats get a skill preload on both fresh-start and restore. Default culture loads at startup, and rig specs are audited at load time. **Rigs instantiated before v0.4.7 need re-instantiation** (or spec-level patching) to pick up the starter fixes — the loader and audit changes apply immediately, but starter-spec content lands at instantiation.
|
||||
|
||||
### Skills wave
|
||||
|
||||
The bundled skill layer gains public routing + a default projection, plus
|
||||
public-skill strip and mirror controls, plus a plugin fix that keeps the
|
||||
documented skill count honest. The vendored skill inventory (canonical,
|
||||
shared, and bundled plugin) grows from a handful to broad coverage across
|
||||
core, PM, pod, and process families.
|
||||
The bundled skill layer gains public routing and a default projection, plus public-skill strip and mirror controls, plus a plugin fix that keeps the documented skill count honest. The bundled skill inventory grows substantially, from a handful to broad coverage across core, PM, pod, and process families.
|
||||
|
||||
### Slack connector + human queue
|
||||
|
||||
First-class connector shape (CLI `commands/slack.ts` + supporting library),
|
||||
with hosted create crossing an inconclusive local probe to the real
|
||||
configured-daemon result.
|
||||
First-class Slack connector shape (CLI `rig slack` commands + supporting library). Hosted create crosses an inconclusive local probe to the real configured-daemon result.
|
||||
|
||||
### CLI contract honesty
|
||||
|
||||
`--json` errors, flag validation, and scoped overdue behavior tightened for
|
||||
machine-readable use.
|
||||
`--json` errors, flag validation, and scoped overdue behavior are tightened for machine-readable use.
|
||||
|
||||
### UI — moved to maintenance mode
|
||||
|
||||
**The web UI is frozen at this release in maintenance mode.** The wording
|
||||
is CLI-primary — never "deprecated"; the UI still ships and still runs,
|
||||
but it is no longer receiving new feature work, and CLI/TUI is the primary
|
||||
surface going forward. What lands in 0.4.7 to make this explicit to users:
|
||||
**The web UI is frozen at this release in maintenance mode.** The wording is CLI-primary — never "deprecated"; the UI still ships and still runs, but it is no longer receiving new feature work, and CLI/TUI is the primary surface going forward. What lands in v0.4.7 to make this explicit to users:
|
||||
|
||||
- A dismissible in-app banner in the web UI announcing the maintenance-
|
||||
mode status.
|
||||
- A `rig ui open` stderr notice at launch time, so operators driving the
|
||||
CLI see the status before they open the browser.
|
||||
- Documentation positioning updated across README / user-facing docs.
|
||||
- A dismissible in-app banner in the web UI announcing the maintenance-mode status.
|
||||
- A `rig ui open` stderr notice at launch time, so operators driving the CLI see the status before they open the browser.
|
||||
- Documentation positioning updated across README and user-facing docs.
|
||||
|
||||
Existing 0.4.6 deployments keep working; nothing is removed. The
|
||||
substantive product investment shifts to the CLI and, from v0.5.0, the
|
||||
terminal TUI.
|
||||
Existing v0.4.6 deployments keep working; nothing is removed. The substantive product investment shifts to the CLI and, from v0.5.0, the terminal TUI.
|
||||
|
||||
### Queue, topology, review polish
|
||||
|
||||
Queue compact-list rows mark elided fields so *omitted* is not *empty*;
|
||||
nested Approve posts a missions-root-relative `scopePath`; mission review
|
||||
card composition is polished; unverified delivered items read
|
||||
`artifact-recorded` rather than "nothing delivered"; drawer `FileViewer`
|
||||
resolves inline C1-body images via `/api/files/asset`; proof-of-work
|
||||
Markdown links open in the in-app drawer; docs guard encodes the ratified
|
||||
`docs/DESIGN.md` root placement.
|
||||
- Queue compact-list rows mark elided fields so "omitted" is distinguishable from "empty".
|
||||
- Nested Approve posts a missions-root-relative scope path.
|
||||
- Mission review card composition is polished.
|
||||
- Unverified delivered items read "artifact-recorded" rather than "nothing delivered".
|
||||
- The drawer file viewer resolves inline in-body images via the file-asset API.
|
||||
- Proof-of-work Markdown links open in the in-app drawer.
|
||||
- Docs guard encodes the root-placement rule for `docs/DESIGN.md`.
|
||||
|
||||
### Host sizing guidance
|
||||
|
||||
Add swap and a sane per-box seat budget (~2GB RSS per seat observed
|
||||
baseline).
|
||||
Recommended: add swap on the host, and plan for roughly ~2 GB RSS per seat as an observed baseline.
|
||||
|
||||
## Behavior + Compatibility
|
||||
|
||||
- **Migrations** — additive only. Existing v0.4.6 databases upgrade by
|
||||
running `rig daemon start` on the new daemon.
|
||||
- **Rig-spec starter behavior** — the loader + audit changes apply
|
||||
immediately; starter-spec content lands at rig instantiation. Rigs
|
||||
instantiated before 0.4.7 need re-instantiation (or spec-level
|
||||
patching) to pick up the starter fixes.
|
||||
- **Seat-liveness API** — consumers should key seat liveness off
|
||||
`lifecycleState` (honest ~3s) rather than `sessionStatus` (staleness
|
||||
cleanup tracked for a subsequent release).
|
||||
- **Web UI posture** — frozen in maintenance mode; no CLI surface
|
||||
breakage. Nothing is removed from the UI at this release.
|
||||
- **Migrations** — additive only. Existing v0.4.6 databases upgrade by running `rig daemon start` on the new daemon.
|
||||
- **Rig-spec starter behavior** — the loader and audit changes apply immediately; starter-spec content lands at rig instantiation. Rigs instantiated before v0.4.7 need re-instantiation (or spec-level patching) to pick up the starter fixes.
|
||||
- **Seat-liveness API** — consumers should key seat liveness off the honest lifecycle state (updated every few seconds) rather than the older session-status field, whose staleness cleanup is tracked for a subsequent release.
|
||||
- **Web UI posture** — frozen in maintenance mode; no CLI surface breakage. Nothing is removed from the UI at this release.
|
||||
|
||||
## See Also
|
||||
|
||||
|
||||
+22
-69
@@ -2,100 +2,53 @@
|
||||
|
||||
## Summary — Permission-posture fast-follow
|
||||
|
||||
Launch posture is configurable, the deny set is clobber-resistant, and
|
||||
dangerous ops are bounded by an honest prefix-gate.
|
||||
Launch posture is configurable, the deny set writes at a level that project-local approvals can't override, and dangerous operations are gated by explicit prefix rules that actually hold under the current harness.
|
||||
|
||||
Migrations are additive only. Existing v0.4.7 databases upgrade by running
|
||||
`rig daemon start` on the new daemon.
|
||||
Migrations are additive only. Existing v0.4.7 databases upgrade by running `rig daemon start` on the new daemon.
|
||||
|
||||
## What Shipped
|
||||
|
||||
### Configurable launch posture
|
||||
|
||||
The hardcoded `--permission-mode acceptEdits` launch flag is replaced by a
|
||||
configurable posture defaulting to `dontAsk`. This kills the ask-hang /
|
||||
freeze class that could park an autonomous seat on a modal permission
|
||||
prompt with nobody to click through it. `dontAsk` is the default because
|
||||
it matches what an autonomous seat can actually respond to; `acceptEdits`
|
||||
remains selectable when a seat needs the prior behavior; a deliberate
|
||||
`bypassPermissions` is preserved untouched across writes.
|
||||
The hardcoded `--permission-mode acceptEdits` launch flag is replaced by a configurable posture defaulting to `dontAsk`. This closes the class of freezes where an autonomous seat could get stuck on a modal permission prompt with nobody to click through it. `dontAsk` is the default because it matches what an autonomous seat can actually respond to; `acceptEdits` remains selectable when a seat needs the prior behavior; a deliberate `bypassPermissions` value is preserved untouched across writes.
|
||||
|
||||
### Clobber-resistant deny set
|
||||
### Deny set that project-local approvals can't override
|
||||
|
||||
The posture writes to user-level `~/.claude/settings.json` instead of the
|
||||
project-local one-off approval surface, so **deny wins over project-local
|
||||
approvals**. Writes are additive (never destructive to sibling keys) and
|
||||
forward-migrate a legacy `acceptEdits` value into the new schema. A
|
||||
deliberate `bypassPermissions` value is preserved verbatim.
|
||||
The posture writes to user-level `~/.claude/settings.json` instead of the project-local approval file. **Deny wins over project-local approvals** as a result. Writes are additive (never destructive to sibling keys) and forward-migrate a legacy `acceptEdits` value into the new schema. A deliberate `bypassPermissions` value is preserved.
|
||||
|
||||
### Bounded-dangerous deny set
|
||||
|
||||
`git push`, `gh pr create`, `npm publish`, and `rig down` are the four
|
||||
bounded-dangerous ops gated by default. `rig down` in particular is gated
|
||||
via the prefix superset `Bash(rig down:*)` — harness rules at Claude
|
||||
2.1.220 are prefix-only (flag-only patterns provably fail to gate target-
|
||||
first forms such as `rig down <rig> --force`, which were slipping through),
|
||||
so the prefix gate is the only shape that actually holds. Plain `rig down`
|
||||
is gated in 0.4.8; selective allowance (e.g. `rig down <rig>` for a
|
||||
specific target) is deferred to 0.5.0 server-side enforcement.
|
||||
Four dangerous operations are gated by default: `git push`, `gh pr create`, `npm publish`, and `rig down`. `rig down` in particular is gated via the prefix rule `Bash(rig down:*)` — the current Claude harness (2.1.220) only supports prefix matches on Bash rules, and flag-only patterns provably don't gate target-first forms like `rig down <rig> --force`, so the prefix rule is the only shape that actually holds. Plain `rig down` is gated in v0.4.8; selective allowance (e.g. `rig down <rig>` for a specific target) is deferred to v0.5.0 server-side enforcement.
|
||||
|
||||
### `rig up` un-gated
|
||||
|
||||
The prior release's ask-gate on `rig up` is superseded — `rig up` is a
|
||||
reversible op and does not warrant an interactive gate.
|
||||
The prior release's ask-gate on `rig up` is removed — `rig up` is a reversible operation and doesn't warrant an interactive gate.
|
||||
|
||||
### Permission-policy foundation (framework for the built-in templates + skill that ship in 0.5.0)
|
||||
### Permission-policy foundation (built-ins land in v0.5.0)
|
||||
|
||||
- **Harness-neutral policy schema** — the permission-policy spec ships as
|
||||
a harness-neutral surface with `default_posture`, `floor`,
|
||||
`allow` / `ask` / `deny` expressed as **semantic actions**
|
||||
(`push_to_remote`, `force_push`, `delete_files`, `read_secrets`,
|
||||
`create_pr`, `publish_package`, `mutate_topology`, ...),
|
||||
`destructive_class`, and a `source: builtin|custom` marker.
|
||||
- **`rig setup --policy <name>`** — new flag on `rig setup` records a
|
||||
deliberate permission-policy choice into an existing rig spec. Takes a
|
||||
built-in name or a path to a custom spec. The **built-in policy files
|
||||
themselves land in v0.5.0**; 0.4.8 ships the framework that consumes
|
||||
them.
|
||||
- **Two surfaces (documented, unchanged)** — the **LAUNCH-FLAG** surface
|
||||
(Claude `--permission-mode`, Codex sandbox/bypass flags, Pi
|
||||
`--approve` / `--no-approve`) is **stable and OpenRig-set
|
||||
deterministically** — this is where the FLOOR and YOLO live. The
|
||||
**CONFIG-FILE** surface (Claude `~/.claude/settings.json`, Codex
|
||||
`config.toml`) is **chaotic across harness versions** and translated
|
||||
interactively per harness version by an agent-driven skill —
|
||||
`applying-a-permission-policy`, which lands as a bundled skill in
|
||||
v0.5.0.
|
||||
- **Harness-neutral policy schema.** The permission-policy spec is a harness-neutral surface with `default_posture`, `floor`, and `allow` / `ask` / `deny` expressed as **semantic actions** (`push_to_remote`, `force_push`, `delete_files`, `read_secrets`, `create_pr`, `publish_package`, and so on) rather than raw shell-command patterns.
|
||||
- **`rig setup --policy <name>`** — a new flag on `rig setup` records a permission-policy choice into an existing rig spec. Takes a built-in name or a path to a custom policy file. The **built-in policy files themselves land in v0.5.0**; v0.4.8 ships the framework that consumes them.
|
||||
- **Two surfaces.** The **launch-flag** surface (Claude `--permission-mode`, Codex sandbox / bypass flags, Pi `--approve` / `--no-approve`) is stable and set by OpenRig for you — this is where the floor and full-bypass YOLO live. The **config-file** surface (Claude `~/.claude/settings.json`, Codex `config.toml`) is where allow/ask/deny rules live; because harness rule grammars change frequently across versions, this surface is applied interactively by an agent-driven skill (that skill ships in v0.5.0 as `applying-a-permission-policy`).
|
||||
|
||||
## Deployment Invariant (Operators Read This)
|
||||
## Deployment Note (operators read this)
|
||||
|
||||
For the posture writes to reach seats, **the daemon's `HOME` must equal the
|
||||
seat's tmux `HOME`**. This is a 2.1.220 settings-path class invariant that
|
||||
operators need to know for the remote-host leg of any upgrade. Notes for
|
||||
your host-upgrade checklist:
|
||||
For the posture writes to reach seats, **the daemon's `HOME` must equal the seat's tmux `HOME`**. This is a Claude 2.1.220 settings-path invariant that matters for the remote-host leg of any upgrade:
|
||||
|
||||
- On a local-only host, this is typically satisfied automatically.
|
||||
- On a remote-host upgrade, verify HOME parity between the daemon process
|
||||
and the tmux seat process before treating the upgrade as complete.
|
||||
- On a remote-host upgrade, verify HOME parity between the daemon process and the tmux seat process before treating the upgrade as complete.
|
||||
|
||||
## Superseded / Withdrawn
|
||||
(v0.5.0 documents this as a Known Issue for Codex `HOME` divergence; the product fix ships in v0.5.1.)
|
||||
|
||||
An initial 0.4.8 attempt (with `dontAsk` baked as a **platform default**)
|
||||
was withdrawn pre-cut on final review; the shipped 0.4.8 is a re-scoped
|
||||
permission-agnostic base + policy-spec system. Nothing from the withdrawn
|
||||
attempt shipped.
|
||||
## Superseded
|
||||
|
||||
An initial v0.4.8 attempt (with `dontAsk` baked as a **platform default** rather than an OpenRig-side default) was withdrawn on final review; the shipped v0.4.8 is a re-scoped permission-agnostic base plus a policy-spec system. Nothing from the withdrawn attempt shipped.
|
||||
|
||||
## Behavior + Compatibility
|
||||
|
||||
- **Migrations** — additive only. Existing v0.4.7 databases upgrade by
|
||||
running `rig daemon start` on the new daemon.
|
||||
- **Default launch posture** — changed from hardcoded `acceptEdits` to
|
||||
configurable, default `dontAsk`. If a seat needs the prior behavior,
|
||||
select `acceptEdits` explicitly.
|
||||
- **Deny-set write location** — user-level `~/.claude/settings.json`, so
|
||||
the deny set wins over project-local approvals. Writes are additive.
|
||||
- **`rig up`** — no longer ask-gated; reversible ops don't warrant an
|
||||
interactive gate.
|
||||
- **Migrations** — additive only. Existing v0.4.7 databases upgrade by running `rig daemon start` on the new daemon.
|
||||
- **Default launch posture** — changed from hardcoded `acceptEdits` to configurable, default `dontAsk`. If a seat needs the prior behavior, select `acceptEdits` explicitly.
|
||||
- **Deny-set write location** — user-level `~/.claude/settings.json`; the deny set wins over project-local approvals. Writes are additive.
|
||||
- **`rig up`** — no longer ask-gated; reversible operations don't warrant interactive gates.
|
||||
|
||||
## See Also
|
||||
|
||||
|
||||
+37
-126
@@ -1,174 +1,85 @@
|
||||
# OpenRig v0.5.0
|
||||
|
||||
> **UI posture (unchanged from v0.4.7):** The web UI remains in
|
||||
> **maintenance mode** — still ships, still runs, no new feature work.
|
||||
> **CLI/TUI is the primary surface.** v0.5.0 lands the TUI (`rig` /
|
||||
> `rig tui`) as the new mission-control home.
|
||||
> **UI posture (unchanged from v0.4.7):** the web UI is in **maintenance mode** — still ships, still runs, no new feature work. **CLI/TUI is the primary surface.** v0.5.0 lands the TUI (`rig` / `rig tui`) as the new mission-control home.
|
||||
|
||||
## Summary — Mission control in the terminal + context library + permission guarantee test-pinned + provider usage observability + plan amendment done right + honest CLI + build discipline
|
||||
## Summary — Mission control in the terminal + context library + permission policies + provider usage + honest CLI
|
||||
|
||||
**Mission control in the terminal.** Typing `rig` (or `rig tui`) opens the
|
||||
TUI: file-tree navigator, dense agent detail (cwd, runtime as text,
|
||||
context %), topology graph with the whole fleet on one screen, honest
|
||||
status/activity language, motion design, working scrolling, and honest
|
||||
width-clip/scope indicators throughout.
|
||||
**Mission control in the terminal.** Typing `rig` (or `rig tui`) opens the new TUI: file-tree navigator, dense agent detail (working directory, runtime, context %), a topology graph with the whole fleet on one screen, honest status/activity language, motion design, working scrolling, and honest width-clip indicators throughout.
|
||||
|
||||
**0.5.0 contains 0.4.8 in full.** One lineage, no divergence, no dual
|
||||
maintenance: 0.5.0 = 0.4.8 (the permission-policy release) + the slices
|
||||
below. The 0.4.8 code + shipped skills all reside on the 0.5.0 lineage
|
||||
via the back-merge that reconciles the 0.4.8 release-artifact history with
|
||||
the 0.5.0 working lineage.
|
||||
**v0.5.0 includes everything from v0.4.8.** There is no divergence between the two releases — the v0.4.8 permission-posture work and shipped skills are all present in v0.5.0.
|
||||
|
||||
Migrations are additive only. Existing v0.4.8 databases upgrade by running
|
||||
`rig daemon start` on the new daemon.
|
||||
Migrations are additive only. Existing v0.4.8 databases upgrade by running `rig daemon start` on the new daemon.
|
||||
|
||||
## What Shipped
|
||||
|
||||
### Permission guarantee, now test-pinned
|
||||
### Permission-policy built-ins + agent-driven translation
|
||||
|
||||
0.5.0 upholds the 0.4.8 promise — **OpenRig never writes permission entries
|
||||
into your Claude `settings.json`** — and pins it with a permanent guard
|
||||
test plus an empty-writer sweep. The one sanctioned exception is the
|
||||
project-local `acceptEdits` floor that 0.4.8 itself defines. Warning
|
||||
ordering in `permission-policy-discovery` emits pre-existing main-floor
|
||||
warnings first, then the permission-policy attachment warning;
|
||||
presentation-only, semantic fence unchanged.
|
||||
Building on the v0.4.8 permission-policy foundation, v0.5.0 ships **the built-in policy templates plus the agent-driven skill that translates them into the target harness's live config**.
|
||||
|
||||
- **Four built-in policy templates** — `locked`, `standard`, `open`, `yolo`. Read-only from the package; copy to customize. Plus `none` as a deliberate no-policy choice.
|
||||
- **`rig setup --policy <name>`** — records the chosen policy into a rig spec. Takes a built-in name (`locked | standard | open | yolo | none`) or a path to a custom policy file (custom policies live as `.policy.md` files you author).
|
||||
- **`applying-a-permission-policy` — bundled skill for the translation.** At rig setup / preflight, the skill reads the policy spec, checks the seat's current harness version, shows the concrete diff before writing, and lands the config into Claude `~/.claude/settings.json` and/or Codex `config.toml`. Never blind writes. The translation is agent-driven on purpose — harness permission formats change frequently across versions, so a deterministic writer would break the moment the harness surface shifts.
|
||||
- **Two surfaces** — the **launch-flag** surface (Claude `--permission-mode`, Codex sandbox/bypass, Pi `--approve` / `--no-approve`) is stable and OpenRig-set for you: the floor (Claude `acceptEdits`, Codex workspace-write) and the full-bypass YOLO mode. The **config-file** surface (Claude `~/.claude/settings.json`, Codex `config.toml`) is where the allow/ask/deny rules live and where the skill applies your chosen policy.
|
||||
- **What's deterministic vs best-effort** — the launch-flag floor and YOLO are deterministic. Fine-grained config-file rules are best-effort because harness rule grammars vary; the skill surfaces the caveats to you (prefix collisions, target-first leaks, Claude's lack of a native network gate) via the diff-before-write flow. If a translation is uncertain, you can always fall back to hand-editing the harness's own settings file, or to YOLO / floor as blunt instruments.
|
||||
|
||||
### Permission-writer guarantee, now test-pinned
|
||||
|
||||
v0.5.0 upholds the v0.4.8 promise — **OpenRig never writes permission entries into your Claude `settings.json`** — and pins it with a permanent guard test plus an empty-writer sweep. The one sanctioned exception is the project-local `acceptEdits` floor that v0.4.8 itself defines. Warning-ordering during permission-policy discovery is cleaner (pre-existing main-floor warnings first, then policy-attachment warnings); presentation-only, semantic fence unchanged.
|
||||
|
||||
### Context library
|
||||
|
||||
`rig context` stores and composes context; `rig walk` delivers it paced;
|
||||
`--context` / `--body-context` ride `send` / `broadcast` / `queue-create`
|
||||
with snapshot + provenance. Grammar is strict: **nouns store and compose**
|
||||
(`rig context` never delivers); **verbs deliver** (`rig send`, `rig
|
||||
broadcast`, `rig walk`, or `rig queue` via `--context` / `--body-context`).
|
||||
The 0.4.x context-window usage viewer is removed; the `rig context` name
|
||||
belongs to the library.
|
||||
`rig context` stores and composes context; `rig walk` delivers it paced; `--context` / `--body-context` attach a stored context (by reference) to `rig send` / `rig broadcast` / `rig queue create`. Grammar is strict: **nouns store and compose** (`rig context` never delivers on its own); **verbs deliver** (`rig send`, `rig broadcast`, `rig walk`, or `rig queue create` via `--context` / `--body-context`). The old context-window usage viewer from v0.4.x is removed; the `rig context` name now belongs to the library.
|
||||
|
||||
### Behavior change (0.4.8 → 0.5.0)
|
||||
### Behavior change (v0.4.8 → v0.5.0)
|
||||
|
||||
`rig.yaml` startup `context_pack` entries are no longer delivered at
|
||||
instantiation. **They are rejected with a teaching error pointing at
|
||||
compose + delivery verbs.** Users who adopted them on 0.4.8 (shipped days
|
||||
ago; tiny exposure) should compose the pack via `rig context compose` and
|
||||
deliver via a dedicated delivery verb (`rig send --context`, `rig
|
||||
broadcast --context`, `rig walk`, or `--context` / `--body-context` on
|
||||
queue create). The bundle router populates the library store without
|
||||
delivering (delivery-free-noun ruling applied at the startup surface).
|
||||
`rig.yaml` startup `context_pack` entries are no longer delivered at rig instantiation. **They are rejected with a teaching error pointing you at `rig context compose` + a delivery command.** Users who adopted `context_pack` in a `rig.yaml` on v0.4.8 (shipped days ago; small window) should compose the pack via `rig context compose` and then deliver it with a delivery command — `rig send --context`, `rig broadcast --context`, `rig walk`, or `--context` / `--body-context` on `rig queue create`. The bundle router still stores the pack; it just doesn't auto-deliver it at startup.
|
||||
|
||||
### Provider usage observability
|
||||
|
||||
The daemon tracks account-level usage per host — the "am I about to hit a
|
||||
usage limit" question — exposed via `GET /api/provider/usage` and `rig
|
||||
provider status`. Honest explicit-unknown and conflict-shows-both-facts;
|
||||
Codex account-switch flows preserved.
|
||||
The daemon tracks account-level usage per host — the "am I about to hit a usage limit" question — exposed via `GET /api/provider/usage` and `rig provider status`. Explicit-unknown when the provider doesn't report it; conflict-shows-both-facts when signals disagree. Codex account-switch flows are preserved.
|
||||
|
||||
### Plan amendment done right
|
||||
|
||||
`rig scope slice approve --re-approve --reason` re-stamps a locked plan
|
||||
with an append-only audit trail, killing the old `already_approved`
|
||||
Status-note workaround.
|
||||
`rig scope slice approve --re-approve --reason "..."` re-stamps a locked plan with an append-only audit trail — replacing an earlier workaround where an already-approved status forced a `Status`-note edit.
|
||||
|
||||
### Honest CLI output
|
||||
|
||||
`rig ps` says when it is showing one rig of many; `rig send --json`
|
||||
returns structured errors as `{fact, consequence, action}`; the activity-
|
||||
hook fix ends the fleet-wide "producer link stale" advisories (operator-
|
||||
facing quality improvement worth naming).
|
||||
- `rig ps` says when it is showing one rig of many, rather than silently limiting.
|
||||
- `rig send --json` returns structured errors as `{fact, consequence, action}`.
|
||||
- Activity-hook fix ends the fleet-wide "producer link stale" advisories that were firing on every send. Operator-facing quality improvement.
|
||||
|
||||
### Build discipline
|
||||
|
||||
Contributor gates/lanes SSOT lives at `docs/reference/developing.md`
|
||||
(encoded by the slice-12 gates policy).
|
||||
Contributor gates and lanes have a single source of truth at `docs/reference/developing.md`.
|
||||
|
||||
### UI status (unchanged from v0.4.7)
|
||||
|
||||
The web UI is formally in **maintenance mode** as introduced in v0.4.7 —
|
||||
still ships, still runs, no new feature work. CLI/TUI is the primary
|
||||
surface. v0.5.0's TUI (`rig` / `rig tui`) is where mission-control
|
||||
investment lands going forward. Never "deprecated" — the UI is not
|
||||
removed and existing deployments continue to work.
|
||||
|
||||
### Permission policies — built-in templates + custom + agent-driven translation
|
||||
|
||||
Building on the v0.4.8 policy-spec system, v0.5.0 ships **the built-in
|
||||
policy templates + the agent-driven skill that translates them into the
|
||||
target harness's live config**.
|
||||
|
||||
- **Five built-in policy templates** — `locked`, `standard`, `open`,
|
||||
`yolo`, `none`. Read-only from the package; copy to customize.
|
||||
- **`rig setup --policy <name>`** — records the chosen policy into a rig
|
||||
spec. Takes a built-in name (`locked | standard | open | yolo | none`)
|
||||
or a path to a custom policy file. Custom policies carry
|
||||
`source: custom` in the spec.
|
||||
- **`applying-a-permission-policy` — agent-driven, version-stamped
|
||||
translator (bundled skill).** At rig setup / preflight, the skill reads
|
||||
the policy spec, grounds itself in the seat's current harness version
|
||||
(Claude 2.1.220 / Codex 0.120.0 / Pi 0.83.0 at ship time), shows the
|
||||
concrete diff before writing, and lands the config into Claude
|
||||
`~/.claude/settings.json` and/or Codex `config.toml`. Never blind
|
||||
writes. The `applying-a-permission-policy` skill is agent-driven on
|
||||
purpose — harness permission formats are a moving target, and a
|
||||
deterministic writer would foot-gun on the next harness release.
|
||||
- **Two surfaces (unchanged from v0.4.8, called out honestly)** —
|
||||
**LAUNCH-FLAG** (stable, OpenRig-set deterministically): the **FLOOR**
|
||||
(Claude `acceptEdits`, Codex workspace-write) and **YOLO** (Claude
|
||||
`--dangerously-skip-permissions`, Codex full-bypass). **CONFIG-FILE**
|
||||
(chaotic, translated per harness version by the skill): the
|
||||
allow/ask/deny rules for `~/.claude/settings.json` +
|
||||
`config.toml`.
|
||||
- **Deterministic parts vs best-effort parts** — the LAUNCH-FLAG floor +
|
||||
YOLO are deterministic. Fine-grained CONFIG-FILE rule translation is
|
||||
**best-effort** — the skill surfaces prefix-collision (e.g.
|
||||
`push_to_remote` vs `force_push` both matching `Bash(git push:*)`),
|
||||
target-first leaks (e.g. `rm <t> -rf` slipping past
|
||||
`Bash(rm -rf:*)`), and Claude-only network-egress non-enforceability
|
||||
to the operator honestly via the diff-before-write flow. If a
|
||||
translation is uncertain, fall back to a blunt instrument (YOLO or
|
||||
floor) or hand-edit — those remain valid paths.
|
||||
The web UI stays in maintenance mode as introduced in v0.4.7 — still ships, still runs, no new feature work. CLI/TUI is the primary surface, and v0.5.0's TUI (`rig` / `rig tui`) is where mission-control investment lands going forward. The UI is not deprecated and not removed; existing deployments continue to work.
|
||||
|
||||
### Bundled skills
|
||||
|
||||
Two new bundled skills join the shipped set alongside the 0.4.8 skills:
|
||||
Two new bundled skills join the shipped set alongside the v0.4.8 skills:
|
||||
|
||||
- `applying-a-permission-policy` — Tier-A agent-driven translation for
|
||||
permission policies (see the Permission policies section above).
|
||||
- `delegating-work` — Tier-A every-agent distribution.
|
||||
- `applying-a-permission-policy` — agent-driven translation for permission policies (see the Permission-policy section above).
|
||||
- `delegating-work` — distribution guidance for every seat.
|
||||
|
||||
The `openrig-user` `SKILL.md` is updated with the 0.5.0 context-library +
|
||||
paced-delivery + `--context` / `--body-context` awareness. Two additional
|
||||
0.5.2-lane maturation-gated skills (`retiring-and-inheriting-a-seat` and
|
||||
`oversight-team`) sit in the oracle at draft stage and are correctly
|
||||
deferred to a later release per the maturation-gate contract.
|
||||
The `openrig-user` skill is updated with the v0.5.0 context-library grammar (`rig context compose`, `rig walk`, `--context` / `--body-context`).
|
||||
|
||||
## Known Issues
|
||||
|
||||
- **GAP-7 Codex-`HOME` product fix** (seal CLEAR `b7f4cb7d`) — accepted
|
||||
with fold-rides-release-sequencing but fell off the fold-wave
|
||||
enumeration and is **NOT in released 0.5.0 by content**. Ships in
|
||||
0.5.1 as a ready-accepted early bugfix atom. Class: sibling of the
|
||||
slice-03 omission, caught by census not damage. If you rely on Codex
|
||||
seats picking up the daemon's `HOME` setting for the permission-
|
||||
posture writes, this is the fix that is still pending; the deployment
|
||||
invariant from v0.4.8 (daemon `HOME` == seat tmux `HOME`) remains the
|
||||
operator-side workaround until 0.5.1 lands.
|
||||
- **Codex `HOME` fix not landed in v0.5.0** — a permission-posture fix that ensures the daemon and Codex seats agree on the `HOME` environment (so the posture writes reach the seat) was accepted for v0.5.0 but was inadvertently omitted from the shipped build. It ships as an early bug-fix in v0.5.1. In the meantime, the v0.4.8 deployment note applies: **the daemon's `HOME` must equal the seat's tmux `HOME`** for the permission-posture writes to reach Codex seats — verify this on any remote-host upgrade.
|
||||
|
||||
## Upgrade Notes
|
||||
|
||||
- Migrations additive-only; run `rig daemon start` on the new daemon.
|
||||
- Any rig `rig.yaml` still declaring a startup `context_pack` will see the
|
||||
teaching-error rejection above; migrate to the compose + delivery-verb
|
||||
pattern.
|
||||
- Migrations are additive-only; run `rig daemon start` on the new daemon.
|
||||
- Any `rig.yaml` still declaring a startup `context_pack` will see the teaching-error rejection above; migrate to `rig context compose` + a delivery command.
|
||||
|
||||
## Behavior + Compatibility
|
||||
|
||||
- **Migrations** — additive only.
|
||||
- **`rig.yaml` startup `context_pack`** — rejected at instantiation with a
|
||||
teaching error. Migrate to `rig context compose` + delivery verbs.
|
||||
- **Context viewer removal** — the 0.4.x context-window usage viewer is
|
||||
removed; the `rig context` name is the library.
|
||||
- **Permission-writer surface** — pinned by a permanent guard test:
|
||||
OpenRig writes zero permission entries into `~/.claude/settings.json`
|
||||
beyond the sanctioned project-local `acceptEdits` floor.
|
||||
- **`rig.yaml` startup `context_pack`** — rejected at instantiation with a teaching error. Migrate to `rig context compose` + delivery commands.
|
||||
- **Context viewer removal** — the v0.4.x context-window usage viewer is removed; the `rig context` name is the library.
|
||||
- **Permission-writer surface** — pinned by a permanent guard test: OpenRig writes zero permission entries into `~/.claude/settings.json` beyond the sanctioned project-local `acceptEdits` floor.
|
||||
|
||||
## See Also
|
||||
|
||||
|
||||
Reference in New Issue
Block a user