loki-mode 11.4.2 → 11.6.0

package/docs/PROOF-PASSPORT.md

@@ -29,3 +29,117 @@ trust limitations, but no repository or machine-specific paths.
 Proof Passport does not currently sign the passport itself. Receipt signature
 status is reported separately and must not be interpreted as a passport
 signature.
+
+## Verification record
+
+Status: v1 (schema_version 1). Closes review finding LM-005: a passing outcome label could be misread when checks were not performed.
+
+Implementation: the verification-record section of `autonomy/lib/proof-verify.py` (CLI: `proof-verify.py <label|summary|json> <file>`). Both routes of `loki verify` and `loki proof show` use this one module, so the bash and Bun paths cannot drift.
+
+### Why three properties
+
+A single "verified" word hides three different questions. The record answers each one separately and never lets one stand in for another.
+
+1. **Integrity.** Is this record the one that was written, unaltered?
+2. **Execution validity.** Did the checks run against the code in front of you, and in what environment?
+3. **Requirement coverage.** Do the checks that ran actually cover what was asked for?
+
+A signature alone proves neither execution validity nor requirement coverage. A signed record can describe checks run on a different commit, on a dirty tree, or against only some of the requirements. The signature says the bytes are unchanged. It says nothing about whether the claims in those bytes are current or complete.
+
+### Property 1: integrity
+
+| status | meaning |
+| --- | --- |
+| `valid` | `verification.hash` matches the canonical bytes, gpg (when present) verifies, the recorded headline matches the headline re-derived from the facts, and the cost claim is coherent. |
+| `invalid` | Any of the above failed. The label becomes `NOT VERIFIED (integrity failed ...)` regardless of what the checks say. |
+| `not_recorded` | The record carries no hash. `.loki/verify/evidence.json` is always in this state: it is unhashed and unsigned. |
+| `unchecked` | The integrity code could not run. |
+
+The Ed25519 attestation is reported as present but is not verified inside the record. Use `loki proof verify --jwks` for that.
+
+### Property 2: execution validity
+
+Recorded with every receipt:
+
+- `git.head_sha` and `git.dirty` (dirty ignores `.loki/`), plus `git.tree_sha256` when the generator computed it.
+- `environment`: os, machine, python, node, bun and git versions, as found.
+
+Status:
+
+| status | meaning |
+| --- | --- |
+| `fresh` | Recorded HEAD equals live HEAD and the tree digest (or clean flag) still matches. |
+| `stale` | HEAD moved, or the working tree changed since the checks ran. Every previously passed check is reported as `stale`, and the label is `STALE (...)`. |
+| `unknown` | Not enough was recorded to compare (older receipts, no git tree). Unknown is never promoted to fresh. The label carries `revision freshness unknown`. |
+
+### Property 3: requirement coverage
+
+Read from `.loki/state/requirements-map.json`:
+
+```json
+{"requirements": [{"id": "R1", "text": "...", "checks": ["lint"], "status": "covered"}]}
+```
+
+| status | meaning |
+| --- | --- |
+| `recorded` | `total`, `covered`, `uncovered` and `uncovered_ids` are filled in. Uncovered requirements appear in the label. |
+| `not_recorded` | No map exists. Coverage is unknown, not zero. Counts are `null`. |
+| `unreadable` | The file exists but is not a valid map. Counts are `null`. |
+
+`covered_but_check_not_passed` lists covered requirements whose named check did not pass. Matching check ids to gate names is best effort.
+
+### Per-check status
+
+Every check is exactly one of: `passed`, `failed`, `skipped`, `not_run`, `stale`.
+
+Recorded words map as follows: pass-like words (`pass`, `passed`, `verified`, `ok`, `success`) become `passed`; fail-like words (`fail`, `failed`, `blocked`, `weakened`, `error`) become `failed`; `skipped` and `disabled` become `skipped`; `stale` stays `stale`. Everything else, including `inconclusive` and empty, becomes `not_run`. A check that did not reach a conclusion never reads as passed.
+
+### Label rules
+
+Evaluated in this order, first match wins:
+
+1. Integrity `invalid`: `NOT VERIFIED (integrity failed: ...)`.
+2. Any `failed` check: `NOT VERIFIED (failed: <ids>)`. A failed check never yields a passing label.
+3. Record has no facts or no base verdict: `INCOMPLETE (...)`.
+4. Base verdict is not `VERIFIED` or `VERIFIED WITH GAPS`: that verdict, unchanged.
+5. Execution `stale`: `STALE (...)`.
+6. Anything not run, recorded gaps, uncovered requirements, modified tests or unknown freshness: `VERIFIED (scoped: 5 of 7 checks ran; not run: lint, e2e)` with the applicable clauses.
+7. Otherwise `VERIFIED`.
+
+The bare word `VERIFIED` therefore means: integrity not failed, no failed checks, every check ran and passed, tree fresh, no uncovered requirements, no modified tests.
+
+### Modified tests
+
+`modified_tests` lists existing test files the change modified, deleted, renamed or type-changed, derived from `git diff --name-status` between the recorded base and head. Added test files are not listed. Status is `measured` or `unknown` (no base recorded or diff not computable). Modified tests appear in the label and in the summary because an implementer who edits the tests that judge the change weakens the evidence.
+
+### Record shape
+
+`loki proof show <id> --json` keeps the full proof. The verification record is produced by `proof-verify.py json`, embedded as `verification` in `.loki/verify/evidence.json`, and added as `verification` to the `loki proof verify` JSON. Fields are added, never renamed.
+
+```json
+{
+  "schema_version": 1,
+  "kind": "proof | evidence",
+  "label": "VERIFIED (scoped: ...)",
+  "base_verdict": "VERIFIED",
+  "integrity": {"status": "valid", "hash_ok": true, "signature": "none", "detail": "..."},
+  "execution": {"status": "fresh", "reason": "", "recorded": {}, "current": {}, "environment": {}},
+  "requirements": {"status": "recorded", "total": 3, "covered": 1, "uncovered": 2, "uncovered_ids": []},
+  "checks": [{"id": "lint", "status": "skipped", "detail": ""}],
+  "counts": {"passed": 1, "failed": 0, "skipped": 1, "not_run": 0, "stale": 0, "total": 2, "ran": 1},
+  "modified_tests": {"status": "measured", "files": [{"path": "tests/a.py", "change": "modified"}]},
+  "complete": true,
+  "record_path": ""
+}
+```
+
+### Human output
+
+`loki verify` (banner), `loki proof show <id>` and `loki proof verify <id> --human` print a compact summary of about 12 lines: the label, revision and freshness, environment, integrity, check counts with the checks that did not pass, requirement coverage, modified tests, and the signature caveat. Pass `--json` to `loki proof show` for the full record.
+
+### Compatibility
+
+- Exit codes are unchanged: `loki verify` keeps its verdict-based codes; `loki proof verify` keeps 0 clean, 1 tamper or drift, 2 unusable.
+- Existing JSON fields are untouched. `verification` is additive.
+- Receipts written before this contract lack `facts.environment` and `facts.git.dirty`. They report environment `not recorded` and may report freshness `unknown`.
+- `loki proof show <id>` used to print the raw JSON. Scripts that parsed it must now pass `--json`.

package/docs/alternative-installations.md

@@ -115,3 +115,106 @@ mv loki-mode-${VERSION} ~/.claude/skills/loki-mode
 ```
 
 **Best for:** Offline or air-gapped environments, pinned version deployments.
+
+---
+
+## Setup requirements (LM-001)
+
+This is the authoritative statement of what Loki Mode needs to run a first task. It is checked by tests against one shared table, `autonomy/lib/setup-requirements.json`. `loki doctor`, `loki doctor --requirements`, `loki doctor --json` (key `requirements`), `loki setup`, and the runtime "provider CLI missing" errors all read that table, so wording and fixes match.
+
+Normal repository build dependencies (the toolchain of the project you point Loki at) are not Loki overhead and are not listed.
+
+### How to read your machine
+
+```
+loki doctor --requirements   # per path: ready or not ready, each item required or optional, present or missing, one-line fix
+loki doctor --json           # same data under "requirements", plus "first_task_ready"
+```
+
+A first task is ready when every required "All paths" item is present and at least one execution path is ready. `first_task_ready` in the JSON reports exactly that. It checks presence on this machine; it does not prove that a provider login is valid or that an API key is accepted.
+
+### Execution paths
+
+- Claude Code CLI path: the default. `loki start` runs the `claude` binary you installed and logged in with `claude auth login`. `loki chat` (with the claude provider) and `loki edit` call the `claude` CLI directly.
+- Anthropic API-key path (Agent SDK, no `claude` CLI): opt-in. It needs `LOKI_SDK_MODE=full` (resolved to `LOKI_SDK_LOOP=1` by `bin/loki`), Anthropic credentials, the bundled `@anthropic-ai/claude-agent-sdk` platform binary, and Bun. It runs only on the Bun route of `loki start`; commands that stay on the bash route (for example `loki demo`, `loki quick`) still need a provider CLI on PATH. Without `LOKI_SDK_MODE=full`, an API key alone does not replace the `claude` CLI for the main loop.
+- Other provider CLIs: `codex` (degraded), `cline`, `aider`, `opencode`. Any one of them replaces the `claude` CLI for `loki start --provider <name>`. Loki never silently substitutes a different provider than the one requested.
+
+### Install methods
+
+| Install method | What it provides | What you still need |
+| --- | --- | --- |
+| `npm install -g loki-mode` | Loki, a bundled Bun binary and the Claude Agent SDK as npm optional dependencies | Node 20+, python3, jq, git, curl, and one execution path above |
+| `npm install -g loki-mode --omit=optional` (slim) | Loki only; no bundled Bun, no Agent SDK | Everything above, plus Bun from https://bun.sh for the Bun route. Without Bun, `bin/loki` falls back to the bash CLI. The API-key path is unavailable |
+| Homebrew (`brew install loki-mode`) | Loki | Same as npm, and install Bun yourself if you want the Bun route |
+| git clone | Loki sources | Same as npm; see the Git Clone section above for the clone steps |
+
+Supported platforms are the `os` entries in `package.json` (darwin, linux).
+
+### Requirements by path
+
+The tables below are generated from the shared source. Do not edit between the markers; run `UPDATE_CONTRACT=1 bun test tests/commands/doctor.test.ts` from `loki-ts` after editing the JSON, and the test fails if this block drifts.
+
+<!-- BEGIN GENERATED REQUIREMENTS (loki-ts/tests/commands/doctor.test.ts) -->
+
+### All paths
+
+Needed by every Loki command.
+
+| Requirement | Level | Check | Fix |
+| --- | --- | --- | --- |
+| Node.js 20 or newer | required | `node` on PATH, version 20.0 or newer | install Node 20+ from https://nodejs.org |
+| Python 3.8 or newer | required | `python3` on PATH, version 3.8 or newer | install python3 with your package manager (brew install python3) |
+| jq | required | `jq` on PATH | install jq with your package manager (brew install jq) |
+| git | required | `git` on PATH | install git with your package manager (brew install git) |
+| curl | required | `curl` on PATH | install curl with your package manager (brew install curl) |
+| bash 4.0 or newer | optional | `bash` on PATH, version 4.0 or newer | install a newer bash (brew install bash); macOS ships 3.2 |
+| Bun 1.3 or newer (bundled by npm install) | optional | `bun` on PATH, version 1.3 or newer | reinstall without --no-optional (npm bundles @oven/bun-*) or install from https://bun.sh; without it loki falls back to the slower bash CLI |
+
+### Claude Code CLI path (default, loki start)
+
+Loki drives the claude binary you installed and logged in.
+
+| Requirement | Level | Check | Fix |
+| --- | --- | --- | --- |
+| claude CLI on PATH (then log in: claude auth login) | required | `claude` on PATH | npm install -g @anthropic-ai/claude-code |
+
+### Anthropic API-key path (Agent SDK, no claude CLI)
+
+Opt-in with LOKI_SDK_MODE=full; the bundled Agent SDK runs the loop over HTTPS.
+
+| Requirement | Level | Check | Fix |
+| --- | --- | --- | --- |
+| SDK loop enabled (LOKI_SDK_MODE=full) | required | `LOKI_SDK_LOOP` is `1` or `true` | export LOKI_SDK_MODE=full |
+| Anthropic credentials (API key, auth token or gateway URL) | required | one of `ANTHROPIC_API_KEY`, `ANTHROPIC_AUTH_TOKEN`, `ANTHROPIC_BASE_URL` is set | export ANTHROPIC_API_KEY=<your key> |
+| Claude Agent SDK platform binary (optional npm dependency) | required | executable `@anthropic-ai/claude-agent-sdk-<platform>/claude` in an installed node_modules | reinstall without --no-optional: npm install -g loki-mode (the SDK is an optionalDependency) |
+| Bun runtime (the SDK loop runs only on the Bun route) | required | `bun` on PATH, version 1.3 or newer | reinstall without --no-optional (npm bundles @oven/bun-*) or install from https://bun.sh |
+
+### Other provider CLIs
+
+codex (degraded), cline, aider, opencode: any one replaces the claude CLI.
+
+| Requirement | Level | Check | Fix |
+| --- | --- | --- | --- |
+| codex CLI | optional | `codex` on PATH | npm install -g @openai/codex |
+| cline CLI | optional | `cline` on PATH | npm install -g cline |
+| aider CLI | optional | `aider` on PATH | pip install aider-chat |
+| opencode CLI | optional | `opencode` on PATH | npm install -g opencode-ai |
+
+### When an optional dependency is missing
+
+| Missing | Effect |
+| --- | --- |
+| @anthropic-ai/claude-agent-sdk (or its platform binary) | The api-key-sdk path is unavailable and doctor reports it not ready. The claude-cli path and all other providers are unaffected. |
+| @oven/bun-* (Bun) | bin/loki falls back to the bash CLI (slower). The api-key-sdk path is unavailable because the SDK loop runs only on Bun. |
+
+<!-- END GENERATED REQUIREMENTS -->
+
+### Install smoke test
+
+`scripts/smoke-install.sh` packs the repository, installs the tarball into a temporary prefix, and runs `loki --version`, `loki doctor --json` and `loki route "add a health endpoint" --json`. It then repeats with Bun and the optional Agent SDK hidden. It is run by hand, is not part of CI, and writes a reproducible log. A run on one machine is evidence for that machine and OS only; it is not an OS matrix.
+
+### Known behaviors
+
+- Bun-less fallback: when Bun is absent, `loki doctor --json` runs a minimal bash evaluator (`loki_requirements_json` in `autonomy/provider-offer.sh`) over the same table. It checks presence only and does not compare versions, so the Node minimum is enforced only by the Bun doctor.
+- `first_task_ready` does not verify that `claude auth login` was done or that an API key is valid.
+- Observed once, with npm 11.17.0 on macOS arm64 and a local tarball: `npm install -g --omit=optional` still installed `@oven/bun-*` and the Claude Agent SDK packages. The smoke test removes them after install so the second case models a machine without them. This was not checked on other npm versions or from the registry.

package/docs/authentication.md

@@ -97,6 +97,20 @@ Scope hierarchy:
 - `control` includes `write` and `read`
 - `write` includes `read`
 
+### Key Rotation and Revocation
+
+Dashboard API keys (`/api/keys`) can be rotated with a grace period during which the old key stays valid (default 24 hours, `grace_period_hours`):
+
+```bash
+curl -X POST http://localhost:57374/api/keys/ci-pipeline/rotate \
+  -H "Authorization: Bearer $ADMIN_TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"grace_period_hours": 24}'
+
+curl -X DELETE http://localhost:57374/api/keys/ci-pipeline \
+  -H "Authorization: Bearer $ADMIN_TOKEN"
+```
+
 ### Roles
 
 Predefined roles map to common access patterns:
@@ -177,7 +191,11 @@ Running with signature verification off provides no authentication security.
 4. Provider redirects back with JWT
 5. Dashboard validates JWT and grants access
 
-OIDC-authenticated users receive full access scopes by default. For fine-grained control, combine OIDC with token-based authorization.
+OIDC-authenticated users are NOT granted full access by default. The role is resolved from claims (see below) and its scopes are enforced through the same hierarchy as API tokens.
+
+### OIDC Role Claims
+
+Role claims are read case-insensitively; values may be a string, a space-separated string or a list. Sources: the claim named by `LOKI_OIDC_ROLES_CLAIM` (dotted paths such as `realm_access.roles` work), then `roles`, `groups`, `realm_access.roles` (Keycloak) and `cognito:groups` (AWS Cognito). Only values that exactly match a built-in role name (`admin`, `operator`, `viewer`, `auditor`) grant that role; other group names fall through to `LOKI_OIDC_DEFAULT_ROLE`. When several roles match, the highest privilege wins (`admin` > `operator` > `auditor` > `viewer`). An unset or unrecognized default falls back to `viewer`, never `admin`. When PyJWT and cryptography are installed, the signature (RS256/RS384/RS512), issuer, audience and expiry are verified against the issuer JWKS.
 
 ### Mixed Mode
 

package/docs/cost-controls.md

@@ -41,6 +41,127 @@ while spending almost nothing and completing no iteration, so neither of those
 breakers ever trips. The wall-clock cap is the one that catches it. We added it
 after a run burned $34 reaching an external timeout.
 
+## Budget contract
+
+The per-run spend cap: its default, how it is chosen, what it covers, where it is
+enforced, how far a run can overshoot, what happens when a price is missing, and
+what happens when a run is cancelled. The CLI help, the run-start line and this
+section must agree; tests pin them.
+
+### Default
+
+The default cap is **100 USD per run**.
+
+The number lives in one file, `loki-ts/data/model-pricing.json`
+(`default_max_cost_usd`). Both routes read it:
+
+- TypeScript: `loki-ts/src/e10ext/budget_cap.ts` (`DEFAULT_MAX_COST_USD`).
+- Bash: `autonomy/run.sh` (`BUDGET_LIMIT`) and the help text through
+  `loki_budget_default_usd` in `autonomy/loki`.
+
+`loki-ts/tests/engine10/budget_cap.test.ts` asserts that this document, the JSON
+file, the TypeScript constant, the bash default and the CLI help all state the same
+number. Change the JSON file and the document together.
+
+Where the default applies:
+
+| Route | Default applies | What the cap does |
+| --- | --- | --- |
+| engine10 (`loki "<task>"`, the Loki 10 engine) | Only when an API key is set (`ANTHROPIC_API_KEY` or `OPENAI_API_KEY`). A subscription run (no key) has no dollar cap. | Ends the run `BUDGET_STOP`, exit 3. |
+| Bash loop (`loki start`, `autonomy/run.sh`) | Always, key or not. | Pauses the run (writes `.loki/PAUSE` and `.loki/signals/BUDGET_EXCEEDED`); remove both to resume. |
+| Bun SDK loop (`LOKI_SDK_LOOP`) | No default. Opt in with `BUDGET_LIMIT`. | Stops the loop when the limit is reached. |
+
+The README and the engine guide have shown different figures in the past (100 and
+20). The figure above is the code's, and the two guides follow it.
+
+### Precedence
+
+Highest first. The first one set wins.
+
+1. `--max-cost USD` (engine10) or `--budget USD` (bash route). `loki start --budget`
+   is forwarded to engine10 as `--max-cost`.
+2. The environment variable `LOKI_BUDGET_LIMIT`. On the bash route an empty value
+   (`LOKI_BUDGET_LIMIT=`) means unlimited.
+3. Config file: `budgets.per_run` in `loki.yaml` (engine10), or the budget setting in
+   the settings file loaded by `autonomy/run.sh` (bash route).
+4. The default above (subject to the API-key rule for engine10).
+
+### Run-start line
+
+Every start prints the active cap and where it came from.
+
+- engine10: the start line ends the cap clause with `cap $X.XX (SOURCE)` where SOURCE
+  is `--max-cost`, `env`, `loki.yaml` or `default`, or `no dollar cap (subscription)`.
+  The default output stays within its 8-line limit.
+- bash route: `Budget limit set: $X.XX (source: flag|env|config|default)`.
+
+A cap set through the bash settings file is reported as `config`; the `--config`
+file loader exports the variable, so it reports as `env`.
+
+### Scope
+
+- **Per run.** The cap covers one run, not a day or a repository.
+- **Retries.** Every session counts, including retried stages and sessions started
+  after a provider failover. Each session writes its own cost record, and the run
+  total is the sum over every session started, so a retry adds to the total.
+- **Child work.** Subagents and tool calls made inside a provider session are part of
+  that session's reported cost. Sessions run in a temporary directory (the Wall stage)
+  have their cost record copied into the run before the directory is removed.
+- **Not counted.** The detached deep verify that may start after a PR opens is a
+  separate process and is not counted against the run cap. Sessions with no known
+  price are not counted either (see "Missing prices").
+
+### Enforcement point and overshoot
+
+engine10 checks the cap before each stage starts (`machine.ts`, `capReached`), using
+the cost events recorded so far. A stage that is already running is not interrupted by
+the dollar cap. The documented overshoot is therefore up to the cost of the stages in
+flight when the cap is crossed (the plan and wall stages can run together). Time caps
+and the per-session time limit still apply inside a stage.
+
+The bash route checks after each iteration (`check_budget_limit`), so the overshoot is
+up to one iteration.
+
+### Missing prices
+
+Cost is never reported as 0 when it was not measured.
+
+- A session with no dollar figure records `usd: null` in its cost event. Token counts
+  are kept when the provider reported them.
+- A model with no entry in the price table (`loki-ts/src/providers/price_table.ts`)
+  is not priced with a default guess. The cost record carries `total_cost_usd: null`,
+  `cost_basis: "unpriced"` and an `unmeasured_reason` naming the model.
+- The bash iteration record omits `cost_usd` and writes `cost_unmeasured_reason`
+  instead of `"cost_usd": 0`.
+- Unmeasured sessions never count toward the cap, so a run with unpriced models is not
+  stopped by a guess. The run summary says `not measured`, or `partial: $X for N of M
+  sessions` when only some sessions were priced. It never prints `$0.00` for a run
+  whose cost is unknown. The cap is only as good as the prices behind it: a run on a
+  model the table does not know is effectively uncapped, and the summary says so.
+
+### Cancellation
+
+SIGINT or SIGTERM during an engine10 run:
+
+1. The supervisor forwards SIGTERM to the worker process group and keeps reading its
+   output.
+2. The worker stops every live provider session. All providers share one spawn path
+   (`createSessionRunner`), so one rule covers them all: SIGTERM to the session's
+   process group, then SIGKILL after 2 seconds. No new session starts.
+3. Each stopped session records the usage measured so far, with its unmeasured flag
+   when no dollar figure exists (`usd: null`).
+4. If the worker has not exited after the cancel grace (10 seconds, set with
+   `LOKI_E10_CANCEL_GRACE_MS`), the supervisor SIGKILLs the group. A second signal
+   escalates immediately.
+5. The supervisor opens no PR and makes no backstop commit, restores the branch the
+   run started on, and appends `run.completed` with `cancelled: true`,
+   `outcome: "CANCELLED"` and the cost folded from the events. `loki status` shows the
+   run as `cancelled`, distinct from `FAILED`.
+6. The run summary is printed with `Outcome: CANCELLED` and the process exits **130**.
+
+The test `loki-ts/tests/engine10/supervisor_signal.test.ts` drives this with a stub
+provider that sleeps.
+
 ## Hitting a cap is a FAILURE, not a success
 
 This is the part that matters for anyone automating against us.
@@ -86,3 +207,21 @@ What we do instead:
 
 If a run cost more than you expected, `loki proof show <id>` tells you where it
 went.
+
+## Backend capability contract (LM-004)
+
+One table in `loki-ts/src/providers/provider_guard.ts` (`CAPABILITIES`) records what each provider guarantees on engine10. `loki provider matrix` prints it (all engines), `loki provider info <name> --json` prints one provider's rows with the source files each value was read from, and `loki start` prints one disclosure line before the run when the provider falls short of Claude. Claude prints nothing extra. On the legacy bash engine only the invocation and sandbox flags are confirmed from code; every other value there is `unknown`, which means not confirmed, not absent.
+
+- cost: `measured` = provider-reported; `estimated` = parsed or size-based and flagged estimated; `none` = reported as not measured.
+- budget kill: `post-iteration` = no further stage starts once priced cost reaches the cap; `none` = no cap applies.
+- cancel (pgroup): the session child is killed as a whole process group.
+- guard scan: `native` = the provider's own hooks gate each call; `post-iteration` = diff scan after each iteration, reverting destructive changes.
+- kill blocking: `native` = enforced; `none` = receipts list `kill blocking not enforced`.
+
+| provider | engine | cost | budget kill | cancel (pgroup) | sandbox flags | receipt | resume | guard scan | kill blocking |
+|---|---|---|---|---|---|---|---|---|---|
+| claude | engine10 | measured | post-iteration | yes | none | yes | yes | native | native |
+| codex | engine10 | estimated | post-iteration | yes | --sandbox workspace-write | yes | no | post-iteration | none |
+| cline | engine10 | estimated | post-iteration | yes | none | yes | no | post-iteration | none |
+| aider | engine10 | estimated | post-iteration | yes | --no-auto-commits | yes | no | post-iteration | none |
+| opencode | engine10 | none | none | yes | none | yes | no | post-iteration | none |

package/docs/dev/release-checklist.md

@@ -4,9 +4,10 @@ Moved out of CLAUDE.md (S-78) to keep the root file short. Updated in this
 pass to remove two items that `docs/v10/DECISIONS.md` D25 and
 `docs/LOKI-10-BUILD-PROMPT.md` section 1 have superseded:
 - `git add -A` in step 4 is replaced with staging by name (repo rule, always).
-- Per-merge pushing is replaced by the release-train model (D25): batch
-  approved merges locally, push once per train, freeze main until Tests, Bun
-  Parity and Security Audit are all green on that exact SHA, then release.
+- Per-merge pushing and the D25 release trains are superseded by D96 (every
+  approved slice is a release; see `docs/v10/OPERATING-MODEL.md`). Waiting for
+  Tests and Security Audit green on that exact SHA still applies to any push
+  made outside the merge-gate.
   "Wait for user approval before commit" from the old workflow is superseded
   by the standing authorization in `docs/LOKI-10-BUILD-PROMPT.md` section 1
   for sessions operating under that program; outside it, ask as normal.
@@ -116,13 +117,13 @@ rm -f loki-mode-*.tgz
 ```
 If any check fails, do not release; fix the root cause first.
 
-### 4. Commit and land (release-train model, D25)
+### 4. Commit and land (every approved slice is a release, D96)
 
 Stage files by name (never `git add -A` or `git add .`), commit with the
-repo-local `asklokesh` identity, no co-author. Batch approved merges locally;
-push once per train (`git push origin main`); wait for Tests and
-Security Audit to go green on that exact SHA before bumping VERSION and
-releasing. GitHub Actions then creates the tag, the GitHub Release, publishes
+repo-local `asklokesh` identity, no co-author. The merge-gate merges approved
+slices to main and main publishes to npm `next` (D96); for a manual push
+(`git push origin main`), wait for Tests and Security Audit to go green on that
+exact SHA before bumping VERSION and releasing. GitHub Actions then creates the tag, the GitHub Release, publishes
 npm, builds/pushes Docker, and updates the Homebrew tap. Do not manually
 create tags.