cool-workflow 0.1.97 → 0.2.0

package/docs/contract-migration-tooling.7.md

@@ -171,3 +171,7 @@ _No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes on
 0.1.96
 
 0.1.97
+
+0.1.98
+
+0.2.0

package/docs/control-plane-scheduling.7.md

@@ -155,3 +155,7 @@ _No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes on
 0.1.96
 
 0.1.97
+
+0.1.98
+
+0.2.0

package/docs/cross-agent-ledger.7.md

@@ -0,0 +1,217 @@
+# Cross-Agent Handoff Ledger
+
+CW adds `cw ledger` — a way for two agents scoped to two separate repos to hand
+each other a CHANGE PROPOSAL or a REVIEW VERDICT as verifiable data, not chat.
+One side proposes or reviews; the other side verifies the entry fail-closed and
+turns a proposal into a real pull request. Design notes:
+[handoff-ledger](designs/handoff-ledger.md).
+
+Each entry is a self-contained JSON object that carries its own sha256 content
+digest. The producing side prints one; it reaches the other session by human
+relay or a shared git repo (below); the consuming side runs `cw ledger verify`
+(one entry) or `cw ledger list` (a whole directory) before acting. A tampered or
+malformed entry is refused with a non-zero exit, so
+`cw ledger verify <file> && open-pr` can never proceed on a lie.
+
+Every verb is on both surfaces: the CLI (`cw ledger ...`) and MCP
+(`cw_ledger_propose`, `cw_ledger_review`, `cw_ledger_verify`, `cw_ledger_list`),
+so an agent can mint and check entries in-process, not only from a shell.
+
+`cw ledger` is a NEW verb. It does not touch `cw handoff`, which is a separate
+collaboration primitive (ownership transfer of a run/task) — see
+[team-collaboration](team-collaboration.7.md).
+
+## Why a ledger, not a shared folder
+
+The two agents run as two separate cloud sessions. They share no filesystem, and
+each is scoped to one repo at launch, so a local folder cannot be the channel.
+The only medium both sides can durably reach is git/GitHub. `cw ledger` therefore
+produces and consumes portable, self-verifying entries; how an entry crosses
+(operator relay now, a shared handoff repo later) is transport, kept separate
+from the verb.
+
+## Mechanism vs policy
+
+The MECHANISM is small and lives in the kernel (`src/ledger.ts`): build a
+proposal or a review entry, seal it with a sha256 digest over its canonical
+content, and verify that digest fail-closed. No run state, no network, no new
+runtime dependency. The POLICY — which repos, who may propose, whether a verdict
+blocks a merge — stays outside, in the operator's hands and the transport.
+
+The digest is computed over a deterministic serialization (object keys sorted
+recursively) of every field except `id` and `digest`, which are derived from it.
+The `id` is content-addressed: `ldg-` + the first 16 hex chars of the digest.
+
+## Commands
+
+```
+cw ledger propose --from <a> --to <b> --title <t> --rationale <r> \
+                  [--files a.ts,b.ts] [--diff <patch>]
+cw ledger review  --from <a> --to <b> --target <proposal-id|pr-ref> \
+                  --verdict <approved|rejected> [--findings "a,b"]
+cw ledger verify  [--file <path>]        # else reads the entry from stdin
+cw ledger apply   [--file <path>]        # verify a proposal, then print its diff
+cw ledger list    --dir <ledger-dir> [--dir <mirror-2> ...]   # verify a dir (or union of mirrors)
+```
+
+All write JSON to stdout (stdout is data). `propose` and `review` print a sealed
+entry; `verify` prints a check report; `apply` prints a verify-plus-diff report;
+`list` prints a per-entry report over a directory.
+
+## Applying a proposal — fail-closed
+
+A proposal carries a `suggestedDiff`, but a proposal never mutates the target
+repo by itself: the write-capable side turns it into a real change. `cw ledger
+apply` is the fail-closed bridge — it verifies the entry FIRST and only then
+emits the diff, so an unverified patch can never reach `git`:
+
+```
+cw ledger apply --file proposal.json | jq -r 'select(.ok).diff' | git apply -
+```
+
+`apply` prints `{ ok, id, kind, diff }`. The `diff` is present **only** when
+`ok` is `true` — a tampered entry (`ok:false`, the `verify` failure codes), a
+review rather than a proposal (`ledger-not-a-proposal`), or a proposal with no
+`suggestedDiff` (`ledger-empty-diff`) all yield `diff:null` and exit `1`. The
+kernel never runs `git`; turning the verified diff into a commit stays the
+operator's (or a wrapper's) step — mechanism, not policy.
+
+## Git transport (T2a — shared handoff repo)
+
+The two agents cannot share a local folder, but they can share a git repo both
+are scoped to. The ledger rides on it with no git logic in the kernel — writing
+is composition through files, and `git` is the operator's (or a wrapper's) step:
+
+```
+# Producing side (cool-workflow), inside the shared repo's working tree:
+cw ledger propose --from cool-workflow --to chime \
+  --title "Add retry" --rationale "flaky net" --files src/net.ts \
+  > ledger/$(cw ledger propose ... | jq -r .id).json      # or any unique name
+git add ledger/ && git commit -m "propose: add retry" && git push
+
+# Consuming side (chime):
+git pull
+cw ledger list --dir ledger && echo "inbox verified — safe to act"
+```
+
+`cw ledger list` reads every `*.json` in the directory, verifies each entry, and
+reports `allOk`. It is a **fail-closed inbox**: if any single entry is tampered,
+malformed, or unreadable, `allOk` is `false` and the command exits `1`, so the
+receiving side refuses the whole batch rather than acting on a mixed one.
+
+### Inbox resolution — which proposals are still open
+
+`cw ledger list` also derives a `resolution` summary so the inbox is
+machine-actionable without opening each file. It pairs every proposal with the
+review(s) whose `target` is that proposal's id and reports one of four states:
+
+```json
+"resolution": {
+  "proposals": [
+    { "id": "ldg-1de7c92172af1871", "title": "Add retry", "resolution": "approved", "reviews": ["ldg-…"] },
+    { "id": "ldg-…", "title": "Rename thing", "resolution": "pending", "reviews": [] }
+  ],
+  "pending": 1, "approved": 1, "rejected": 0, "contested": 0
+}
+```
+
+- `pending` — no verified review targets the proposal yet.
+- `approved` / `rejected` — every verified review targeting it agrees.
+- `contested` — verified reviews targeting it disagree (both an APPROVED and a
+  REJECTED exist); the ledger REPORTS the disagreement, it does not pick a
+  winner (mechanism, not policy — whether a verdict blocks a merge stays
+  outside).
+
+Only **verified** entries take part: a tampered review can never resolve a
+proposal, so a proposal answered only by a failing review stays `pending`
+(fail-closed). The fields are additive — the existing `entries[]` / `allOk` /
+`count` output is byte-unchanged (POLA), with each entry now also carrying its
+`title` (proposals) or `target`/`verdict` (reviews). The same `resolution` rides
+on the mirror-union output and on the `cw_ledger_list` MCP tool.
+
+### Mirrors — union-verifying several directories
+
+`--dir` is repeatable. With two or more, `cw ledger list` **union-verifies** the
+directories as mirrors of one ledger (e.g. the same handoff repo cloned from a
+GitHub remote and one or more self-hosted Gitea remotes in different places):
+
+```
+cw ledger list --dir gh/ledger --dir gitea-eu/ledger --dir gitea-asia/ledger
+```
+
+The union is **conflict-free by construction**: entries are immutable and
+content-addressed, so the same entry mirrored to several hosts collapses to one
+result whose `dirs` records every mirror it was found in. It stays **fail-closed
+across mirrors** — a tampered entry in ANY mirror sets `allOk:false` and exits
+`1`. This is for redundancy and reachability, not load: the ledger's traffic is
+tiny; multiple hosts guard against one being down or unreachable.
+
+A single `--dir` keeps the original single-directory output (a `dir` field, no
+`dirs`); two or more switch to the union shape (`dirs` plus a per-entry `dirs`).
+The transport stays git-host-agnostic — adding a mirror is one more clone + one
+more `--dir`, no code change.
+
+## Entry shape
+
+A proposal:
+
+```json
+{
+  "kind": "proposal",
+  "schemaVersion": 1,
+  "from": "cool-workflow",
+  "to": "chime",
+  "title": "Add retry to the fetch path",
+  "rationale": "the network is flaky under load",
+  "targetFiles": ["src/net.ts"],
+  "suggestedDiff": "@@ ... @@",
+  "createdAt": "<iso>",
+  "id": "ldg-<16 hex>",
+  "digest": "sha256:<64 hex>"
+}
+```
+
+A review is the same envelope with `kind: "review"`, plus `target` (the proposal
+id or a PR ref), `verdict` (`APPROVED` | `REJECTED`), and `findings` (a list).
+
+## Verification contract
+
+`cw ledger verify` re-proves the entry and exits fail-closed:
+
+- Not a JSON object, or non-JSON bytes → `ok:false`, code `ledger-bad-json` /
+  `ledger-not-object`.
+- Unknown `kind`, wrong `schemaVersion`, missing digest, missing a required
+  field, or a bad `verdict` → `ok:false` with the matching code.
+- Stored digest does not match a fresh digest of the content →
+  `ok:false`, code `ledger-digest-mismatch`.
+- `id` is not the content-addressed id for the digest (spoofed or absent) →
+  `ok:false`, code `ledger-id-mismatch`. `id` is excluded from the digest, so it
+  is bound to the content by this check — a forged entry cannot set its `id` to
+  collide with a legitimate one and slip through the mirror-union de-duplication.
+
+Any `ok:false` exits `1`. An intact entry exits `0` with `ok:true`.
+
+## Example round-trip
+
+```
+# On the proposing side (cool-workflow):
+cw ledger propose --from cool-workflow --to chime \
+  --title "Add retry" --rationale "flaky net" \
+  --files src/net.ts --diff "$(git diff)" > proposal.json
+
+# The operator carries proposal.json to the chime session, which checks it:
+cw ledger verify --file proposal.json && echo "safe to open a PR"
+
+# The reviewing side hands a verdict back:
+cw ledger review --from chime --to cool-workflow \
+  --target ldg-1de7c92172af1871 --verdict approved \
+  --findings "tests pass,scope ok" > verdict.json
+cw ledger verify --file verdict.json
+```
+
+## Roadmap
+
+Stage 1 shipped the CLI verbs (human relay). Stage 2 adds the MCP surface and
+the git-as-ledger transport (`cw ledger list` over a shared repo). Still open:
+the operator creates the shared handoff repo and scopes both agent environments
+into it. See [handoff-ledger](designs/handoff-ledger.md).

package/docs/designs/handoff-ledger.md

@@ -0,0 +1,145 @@
+# Design — Cross-agent handoff ledger
+
+Status: DRAFT / proposal. Nothing here is built yet. This file ships no
+behavior, no new command, no man-page contract, and changes no existing
+output. It exists so two people (the operator and the reviewer agent) can
+agree on the shape before any code is written.
+
+North Star track: **Track B** (portable, verifiable state — the same
+`run export` → `run restore` recovery story, now used as the channel
+between two agents).
+
+## Goal
+
+Two agents work on two repositories:
+
+- one agent scoped to repo **A** (for example `cool-workflow`),
+- one agent scoped to repo **B** (for example `chime`).
+
+The operator wants them to "share data, review each other, and each be
+able to raise a pull request to the other". In plain terms:
+
+- each side can hand the other a **change proposal**, and
+- each side can hand the other a **review verdict** on a diff or PR,
+- with saved, inspectable, fail-closed state — never a fabricated hand-off.
+
+## The hard constraint (why the obvious design does not work)
+
+The first idea is a shared local folder (for example `~/.chime/handoff/`)
+that both agents read and append to. That only works when both agents run
+on **one machine** with **one filesystem**.
+
+In the operator's setup the two agents run as **two separate cloud
+sessions**. Each session is a fresh, throwaway VM. Two facts follow, and
+the design must respect both:
+
+1. **No shared filesystem.** A file the B-agent writes to `~/.chime/handoff/`
+   in its VM is invisible to the A-agent's VM, and is gone when the session
+   ends. A local folder cannot be the channel.
+2. **Single-repo scope.** Each session's GitHub reach is scoped to one repo
+   at launch (A-agent → repo A, B-agent → repo B). The A-agent cannot read
+   repo B through its GitHub tools, and the reverse is also true. Scope is
+   fixed at launch and cannot be widened mid-session.
+
+The only medium both sessions can durably reach is **git / GitHub**. So the
+ledger is a set of committed files, not a local folder — and the scope wall
+means the hand-off still needs either a shared repo or a human relay for the
+cross-repo step. This document is honest about that; it does not pretend the
+wall is not there.
+
+## What we reuse (no new trust machinery)
+
+CW already has the parts this needs. The design adds a thin verb layer over
+them; it invents no new crypto and no new state format.
+
+- `run export` produces a **verifiable bundle** (file digests, telemetry
+  ledger, trust-audit hash chains).
+- `run restore` **imports fail-closed**: it inspects first, refuses a corrupt
+  or tampered bundle without writing anything, and exits non-zero when the
+  chain does not verify. (`run import` is the exit-0 sibling; the hand-off
+  path must use the fail-closed `restore` contract.)
+- `report verify` checks a run's evidence and citations.
+
+A hand-off entry is therefore just a CW bundle. The receiving side trusts it
+the same way it trusts any restored run: by verification, not by good faith.
+
+## Two verbs
+
+Both live under a single new `cw ledger` verb, so the existing surface is
+untouched and the new behavior is opt-in (POLA). (The name `handoff` was already
+taken by an unrelated collaboration primitive — ownership transfer of a run/task
+— so the cross-agent verb is `ledger`, not `handoff`.) Stage 1 ships as
+`cw ledger propose|review|verify`; see
+[cross-agent-ledger](../cross-agent-ledger.7.md) for the contract.
+
+- **`propose`** — the read-only side writes a structured *change proposal*
+  (title, rationale, target files, suggested diff) as a ledger entry. It does
+  **not** mutate the other repo. The write-capable side picks the entry up,
+  verifies it, and turns it into a **real GitHub pull request**.
+- **`review`** — the reviewing side writes a structured *review verdict*
+  (`APPROVED` / `REJECTED`, findings, the diff or PR it judged) as a ledger
+  entry. The other side surfaces it and can act on it.
+
+This keeps a read-only agent honest: it emits proposals and verdicts as
+**data**, and the write-capable side is the only one that opens PRs. Neither
+side has to be trusted to have mutated the other's code.
+
+## Transports (how an entry actually crosses)
+
+The verbs above produce and consume entries; the transport is how an entry
+moves from one VM to the other. Two are in scope, smallest first.
+
+- **T1 — Human relay (MVP, works today, zero infra).** The producing side
+  prints the entry (a verifiable bundle, or its safe text form) to stdout;
+  the operator carries it to the other session; the consuming side verifies
+  it fail-closed and acts (opens the PR, or records the verdict). This is
+  exactly the loop the operator is already running by hand. It needs no new
+  code beyond a stable print/parse shape.
+- **T2 — Git-as-ledger.** Each entry is committed to a repo under a known
+  path (for example `handoff/<from>-<to>/<id>.bundle`). Because scope is
+  single-repo, this needs one of:
+  - **T2a — a shared handoff repo** both agents are scoped to (cleanest, but
+    the operator must create it and launch both sessions against it), or
+  - **T2b — each side writes to its own repo** and a bridge (the operator, or
+    a scheduled job that *is* scoped to both) moves entries across. The
+    cross-repo read cannot be automatic inside a single scoped session — this
+    is the scope wall, stated plainly, not a gap to be quietly filled.
+
+## Fail-closed rules (non-negotiable)
+
+- An entry that does not verify is **refused**, never acted on. No PR is
+  opened, no verdict is recorded, and the refusal is explicit on stderr with
+  a non-zero exit — the same contract as `run restore`.
+- A proposal is a **suggestion only**. It never edits the target repo by
+  itself; a human-or-agent on the write side always makes the real PR, so the
+  read-only vow of the proposing side holds.
+- stdout stays data (the entry / the machine result); stderr stays
+  diagnostics; a piped run is silent on success. `--json` is stable and
+  decoration-free.
+
+## Non-goals / POLA
+
+- No existing command, output byte, exit code, or file layout changes.
+- No new runtime dependency (zero-dependency red line holds).
+- No vendor-specific logic in core; the verbs move opaque bundles.
+- Nothing ships until its own cycle lands with a test that fails before and
+  passes after, and a `docs/*.7.md` contract page — this design file is not
+  that contract and claims no shipped behavior.
+
+## Suggested rollout (each stage its own reviewed cycle)
+
+0. **This design doc** (no behavior). ← you are here.
+1. **T1 human-relay shape** — a stable, documented print/parse form for a
+   proposal and a verdict, plus a smoke that round-trips one of each and
+   proves a tampered entry is refused.
+2. **`cw ledger propose` / `review`** over `run export` / `restore`, with the
+   fail-closed refusal test.
+3. **T2 git-ledger** (shared-repo first), then optionally a scoped bridge job
+   for T2b.
+
+## Open decisions for the operator
+
+- T2a (shared handoff repo) or T2b (own repos + bridge)? T2a is simpler and
+  should be the default unless a shared repo is not acceptable.
+- Should a verdict be able to **block** a PR merge on the other side, or only
+  advise? Advise-only is the safer default and matches "review as data".

package/docs/durable-state-and-locking.7.md

@@ -154,3 +154,7 @@ _No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes on
 0.1.96
 
 0.1.97
+
+0.1.98
+
+0.2.0

package/docs/evidence-adoption-reasoning-chain.7.md

@@ -315,3 +315,7 @@ _No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes on
 0.1.96
 
 0.1.97
+
+0.1.98
+
+0.2.0

package/docs/execution-backends.7.md

@@ -345,3 +345,7 @@ _No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes on
 0.1.96
 
 0.1.97
+
+0.1.98
+
+0.2.0

package/docs/handoff-setup.md

@@ -0,0 +1,120 @@
+# Handoff ledger — shared-repo setup (T2a)
+
+How to stand up the shared repo that carries `cw ledger` entries between two
+agents scoped to two separate repos (e.g. `cool-workflow` and `chime`), each
+running in its own cloud session. The verbs are documented in
+[cross-agent-ledger](cross-agent-ledger.7.md); this is the operator runbook.
+
+Examples are portable — replace `<owner>`, `<src-repo>`, and the paths with your
+own, and keep tokens in environment variables, never in files or commit text.
+
+## What only the operator can do
+
+- A cool-workflow-scoped web session cannot create the shared repo — the GitHub
+  integration returns `403 Resource not accessible by integration` for any repo
+  outside its scope. Create it yourself.
+- Scoping the two agent environments (or granting them git credentials) is a
+  Claude Code web-UI step; it cannot be done from inside a session.
+
+## Choosing a host: GitHub vs self-hosted (Gitea)
+
+The transport is git-host-agnostic — the kernel has no git logic, so any git
+remote works. The choice is about reachability and operations, not code.
+
+| | GitHub (private repo) | Self-hosted Gitea (your VPS) |
+|---|---|---|
+| Reachability from cloud sessions | github.com is in the default **Trusted** allowlist — works with no network-policy change | Your VPS host is **not** in the default allowlist — the environment's network access must be configured to permit it |
+| Scope wall | The GitHub MCP scope is per-repo; the ledger uses plain git (not MCP) so it works, but it runs against the grain of the scoping model | Not a GitHub repo at all, so the GitHub scope wall does not apply |
+| Limits / quota | Disable Actions on this repo (it needs no CI) so it burns no minutes; git push/pull is not API-rate-limited; ledger traffic is tiny | Fully self-controlled, unlimited |
+| Operations | Managed, backed up, zero maintenance | You run it: uptime, backups, TLS cert, patching |
+| Data location | GitHub's servers (private) | Your own hardware |
+
+**Recommendation.** Start on **GitHub private** — it is reachable out of the box
+and the quota worry is practically moot for tiny ledger traffic. Move to **Gitea**
+if you want full self-hosting AND have confirmed the cloud environment can reach
+your VPS through its network policy (the deciding prerequisite). Migrating later
+is only a change of git remote — no code change.
+
+## GitHub private — setup
+
+1. **Token.** GitHub → Settings → Developer settings → Personal access tokens →
+   Fine-grained. Repository access: only `<owner>/handoff`. Permissions:
+   Contents = Read and write. Copy the token.
+2. **Repo.** Create `<owner>/handoff`, private, initialized with a README. In
+   Settings → Actions → General, disable Actions (no CI needed → no minutes).
+3. **Environments.** In each agent environment (both the `cool-workflow` and the
+   `chime` environment), add an environment variable `GH_TOKEN=<token>` (`.env`
+   format, no quotes). A new session is required for it to take effect.
+4. **Optional** — put the clone in each environment's setup script so the ledger
+   is present at session start:
+   ```bash
+   #!/bin/bash
+   git clone https://oauth2:${GH_TOKEN}@github.com/<owner>/handoff.git /home/user/handoff || true
+   ```
+
+## Gitea (self-hosted) — setup
+
+Same shape, two extra prerequisites:
+
+1. Serve Gitea over HTTPS with a valid certificate (e.g. Let's Encrypt) so the
+   cloud VM's git can verify it.
+2. Configure the agent environment's **network access** to permit your VPS host —
+   the default Trusted allowlist does not include it. If the loop cannot reach
+   the VPS, it cannot run.
+3. Create a Gitea access token, store it as an environment variable, and clone
+   with an authenticated remote (`https://<user>:${GIT_TOKEN}@<vps-host>/<owner>/handoff.git`).
+
+## Directory convention
+
+Entries live under `ledger/` in the shared repo, one file per entry named by its
+id:
+
+```
+handoff/
+  ledger/
+    ldg-1de7c92172af1871.json
+    ldg-2315e4b33b9a812f.json
+```
+
+## The loop
+
+Producing side (propose a change, hand it over):
+
+```bash
+entry=$(cw ledger propose --from cool-workflow --to chime \
+  --title "Add retry" --rationale "flaky net" \
+  --files src/net.ts --diff "$(git -C <src-repo> diff)")
+id=$(printf '%s' "$entry" | jq -r .id)
+printf '%s\n' "$entry" > /home/user/handoff/ledger/$id.json
+git -C /home/user/handoff add ledger/$id.json
+git -C /home/user/handoff commit -m "propose $id"
+git -C /home/user/handoff push
+```
+
+Note the single `cw ledger propose` call captured into `$entry` — calling it
+twice would mint two different entries (each carries a fresh `createdAt`).
+
+Consuming side (verify the inbox, then act or review back):
+
+```bash
+git -C /home/user/handoff pull
+cw ledger list --dir /home/user/handoff/ledger && echo "inbox verified — safe to act"
+
+# hand a verdict back:
+entry=$(cw ledger review --from chime --to cool-workflow \
+  --target ldg-1de7c92172af1871 --verdict approved --findings "tests pass,scope ok")
+id=$(printf '%s' "$entry" | jq -r .id)
+printf '%s\n' "$entry" > /home/user/handoff/ledger/$id.json
+git -C /home/user/handoff add ledger/$id.json
+git -C /home/user/handoff commit -m "review $id"
+git -C /home/user/handoff push
+```
+
+## Notes
+
+- Keep private code out of a **public** handoff repo: omit `--diff` and reference
+  a commit/branch in the private source repo instead, so only metadata + a
+  pointer is exposed. On a private handoff repo, full diffs are fine.
+- The other side may build entries without `cw` as long as they match the
+  digest/id rules in [cross-agent-ledger](cross-agent-ledger.7.md); otherwise
+  `cw ledger verify` refuses them with `ledger-digest-mismatch`.

package/docs/multi-agent-cli-mcp-surface.7.md

@@ -321,3 +321,7 @@ The host-facing surface tracks the CLI golden-path fixes (`cw -q` routing + repo
 0.1.96
 
 0.1.97
+
+0.1.98
+
+0.2.0

package/docs/multi-agent-eval-replay-harness.7.md

@@ -347,3 +347,7 @@ _No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes on
 0.1.96
 
 0.1.97
+
+0.1.98
+
+0.2.0

package/docs/multi-agent-operator-ux.7.md

@@ -359,3 +359,7 @@ _No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes on
 0.1.96
 
 0.1.97
+
+0.1.98
+
+0.2.0

package/docs/node-snapshot-diff-replay.7.md

@@ -180,3 +180,7 @@ _No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes on
 0.1.96
 
 0.1.97
+
+0.1.98
+
+0.2.0

package/docs/observability-cost-accounting.7.md

@@ -239,3 +239,7 @@ _No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes on
 0.1.96
 
 0.1.97
+
+0.1.98
+
+0.2.0