loki-mode 11.6.0 → 11.8.1

package/docs/CLI-REFERENCE.md

@@ -1,6 +1,6 @@
 # CLI reference
 
-Generated from `loki-ts/src/cli/registry.ts` by `scripts/generate-stale-zero.sh` for v11.6.0. Do not edit by hand.
+Generated from `loki-ts/src/cli/registry.ts` by `scripts/generate-stale-zero.sh` for v11.8.1. Do not edit by hand.
 Hidden and legacy-only commands are omitted; see `docs/v10/CLI-MODERN.md` for the full inventory.
 
 | Command | Description |
@@ -19,6 +19,7 @@ Hidden and legacy-only commands are omitted; see `docs/v10/CLI-MODERN.md` for th
 | `loki memory index` | Show or rebuild the memory index |
 | `loki memory learn` | Learn lessons from a merged PR's review comments |
 | `loki memory lessons` | List PR review lessons with uses and outcomes |
+| `loki memory brief` | Print the lessons and learnings block an engine10 run injects |
 | `loki memory show` | Show one learning |
 | `loki memory search` | Search learnings |
 | `loki memory stats` | Memory statistics |

package/docs/DEPLOY-PLAN.md

@@ -1,17 +1,26 @@
-# DEPLOY-PLAN.md -- `loki deploy` (ADVISORY / PRINT-ONLY)
+# DEPLOY-PLAN.md -- `loki deploy` (original design: advisory print-only; `--execute` now exists)
 
-**Feature:** `loki deploy` -- detect project type + the user's installed cloud CLI,
-PRINT (and best-effort copy) the canonical deploy command(s), and **never run them**.
+**Current behavior (v11.7.0).** `loki deploy` still prints the deploy command by default and
+runs nothing. Loki deploys only behind `--execute` plus a VERIFIED, HEAD-anchored receipt, a
+clean tree, a destructive-op refusal and a policy permission (`.loki/policies.json`
+`autonomy: operate`, or an explicit `actions.deploy` allow). With `--health-url URL` it probes the
+deployed URL after the command. A non-2xx result is recorded as FAILED_HEALTH and exits non-zero;
+with `--auto-rollback` it also runs the provider's documented rollback verb (`vercel rollback`,
+`fly releases rollback <captured version>`; Netlify and Cloudflare print a manual note). With no
+URL, health is recorded as "unchecked", never healthy. The deploy record lives in `.loki/deploys`
+and is not part of the signed receipt. `loki start --deploy [--health-url U] [--auto-rollback]`
+chains the same gated command after a start. Not built: canary or staged rollout, and receipt-bound deploy records.
+
+Everything below is the original print-only design plan and is kept for history.
 
 **Status:** Architecture plan. No implementation code here. Pattern family: the just-shipped
 `loki preview --public` (`_preview_public` at `autonomy/loki:5306`, helpers from `_read_app_state`
 at `:5216`, arg parsing in `cmd_preview` at `:5546`-`:5609`, dispatch arm `preview)` at `:14966`).
 
-**Why this exists / why it is safe.** README states (line 447) *"Does not deploy -- human runs
-deploy commands"* and (line 452) *"It does NOT access your cloud accounts ... Human oversight is
-expected for deployment."* This feature keeps that literally true: it is an **advisory printer**.
-It runs `command -v <cli>` ONLY (never the CLI itself, not even `--version`), prints the exact
-command, and the **human runs it**. Fully reversible; touches no cloud account.
+**Why the original design was print-only.** The README then stated that deploy commands were run by
+a human and that Loki did not access cloud accounts. The first version was an **advisory printer**:
+it ran `command -v <cli>` ONLY (never the CLI itself, not even `--version`), printed the exact
+command, and the **human ran it**. Fully reversible; touched no cloud account.
 
 ---
 

package/docs/EVALUATING.md

@@ -211,6 +211,12 @@ Not measured: human effort, recovery success, review quality. Output: `--out-dir
 
 ---
 
+## 9. Factory-vs-Loki task set (reproducible, partly unmeasured)
+
+`benchmarks/attribution/tasks/coord-1-api-web/` (multi-repo coordination) and `benchmarks/attribution/tasks/longspec-1-three-units/` (long spec, three units) ship with held-out acceptance kept outside the workspace. `benchmarks/bench/attribution.py` has three arms: `raw_claude`, `loki` and an optional `droid` arm. The droid arm probes `droid exec --help`; when `droid exec` is unavailable every droid cell is recorded UNMEASURED with a reason, never zero. `python3 benchmarks/bench/attribution.py --dry-run` lists the tasks and arms and makes no model call. No Factory result is published: Factory publishes no Missions benchmark and no droid run has been measured here. Axis where Loki is ahead on documented features: offline-recheckable signed receipts, now composite receipts for multi-repo change sets; Factory documents none.
+
+---
+
 ## What we do not have
 
 Stating this plainly, because you will find it out anyway and it is cheaper for
@@ -228,6 +234,8 @@ both of us if you find it here.
   Replit Agent ship no local CLI and are not covered at all. Treat this as
   "unclaimed on every surface we can reach", which is stronger than the earlier
   "unclaimed as far as we can verify" and still short of a proven first.
+- **No scale measurement for multi-repo runs.** No test covers dozens of repos, so none is claimed.
+- **No Factory comparison run.** The droid arm is UNMEASURED until a run exists (section 9).
 - **Generation is not air-gapped.** See section 2.
 
 ---

package/docs/INSTALLATION.md

@@ -2,7 +2,7 @@
 
 Loki Mode, by [Autonomi](https://www.autonomi.dev/), turns a spec or an issue into a verified pull request with a receipt you can check. This page covers installing it, a first run, and the options around it.
 
-**Version:** v11.6.0
+**Version:** v11.8.1
 
 **Engine note:** `loki start` is the primary command. `loki start`, `loki "<task>"`, `loki owner/repo#N` and `loki quick` all run the Loki 10 engine, whatever the flag order or input form (PRD file, issue ref, task or one-word brief). The previous loop runs only on `--engine legacy`, `LOKI_ENGINE=legacy`, or for one call when a flag Loki 10 cannot honor is present. See the [user guide](v10/GUIDE.md) and the [5-minute quickstart](QUICKSTART.md).
 

package/docs/WORKSPACES.md

@@ -10,9 +10,13 @@ workspaces:
     repos:
       - {repo: acme/api, path: ~/src/api, setup: "npm ci"}
       - {repo: acme/web, path: ~/src/web, after: [acme/api]}
-    integration: {command: "make e2e", timeout_s: 900}
+    integration: {command: "make e2e", timeout_s: 900, per_stage: false}
+    concurrency: 2
+    plan: false
 ```
 
+The `workspaces:` block is validated and fails closed: a misspelled key (for example `afer`) or a wrong type exits 2 and names the key.
+
 Repos with no pending `after` run in parallel, at most `concurrency` at a time (default 2; set `LOKI_WORKSPACE_CONCURRENCY` to change it).
 
 Then:
@@ -21,6 +25,8 @@ Then:
 loki workspace list
 loki workspace show shop
 loki workspace run shop acme/api#12
+loki start --workspace shop "<brief>"   # same runner, from the primary command
+loki workspace infer shop        # print suggested after: edges
 loki workspace status            # every recorded run, one row per repo
 loki workspace status <run-id>
 ```
@@ -30,7 +36,10 @@ loki workspace status <run-id>
 - A failing repo does not stop the others (continue and report). The command exits 0 only when every repo succeeded and the integration step did not fail. It exits 3 when the only non-ok outcomes are budget stops (a child exited 3, or a dependent was skipped behind one), and 1 for any other failure. Ctrl-C (SIGINT) stops the recorded child process groups like SIGTERM.
 - The repo that owns the issue ref gets the ref; other repos get a task text naming the ref and the sibling worktree paths as read-only context.
 - After all repos finish, the `integration` command runs once from the run directory with `LOKI_WS_DIR_<OWNER>_<REPO>` pointing at each worktree. A timeout counts as failed. With no integration configured the status is `not_configured`.
-- Evidence is written to `.loki/workspaces/<name>/<run-id>/integration.json`: head SHA per repo, exit code, log sha256. It is not part of the Seal.
+- Evidence is written to `.loki/workspaces/<name>/<run-id>/integration.json`: head SHA per repo, exit code, log sha256. When every repo succeeded, integration did not fail and every child sealed a receipt, the run also seals a signed `composite.json` that binds integration.json and every child receipt (see "Verify a workspace run").
+- `loki workspace infer <name>` prints suggested `after:` edges read from package.json, go.mod and pyproject.toml dependencies on other listed repos. It is print-only and cycle-checked; it never edits loki.yaml. Manifests only: no OpenAPI or import inference.
+- `plan: true` (or `LOKI_WORKSPACE_PLAN=1`) makes one provider call that decomposes the brief per repo into `<run-dir>/plan.json`. A valid plan gives each listed repo its own task; an invalid one falls back to the generic text and prints the reason.
+- `integration: {per_stage: true}` also runs the integration command after each topological layer. A failing stage SKIPs every later layer, so a broken contract stops before downstream repos build on it.
 - Without `path`, a repo is cloned to `~/.loki/repos/owner__name`.
 - After the integration step, a PR comment is posted on each repo PR that exists for its run branch, showing the integration status (PASSED, FAILED, TIMEOUT or NOT CONFIGURED) and every head SHA. It uses your own `gh` login or GH_TOKEN, skips silently when there is no PR, never fails the run, and is disabled with `LOKI_WORKSPACE_COMMENT=0`.
 - Metrics: each run records `timing` (per repo `started_at` and `finished_at`, epoch seconds) in integration.json. `python3 autonomy/lib/workspace_metrics.py <run-dir> --attention-min 30` prints `prs` (repos with outcome ok), `wall_clock_seconds` (earliest start to latest finish), `prs_per_hour` and `prs_per_attention_minute`. Runs recorded before timing existed, and any run where `--attention-min` is not given, print `unmeasured` for the affected rate, never zero.
@@ -46,5 +55,9 @@ After `loki workspace run <name> <ref>` finishes, check the evidence rather than
 3. `.loki/workspaces/<name>/<run-id>/integration.json` holds `status`, the head SHA per repo and `timing`.
 4. `python3 autonomy/lib/workspace_metrics.py <run-dir> --attention-min <minutes>` prints `prs`, `prs_per_hour` and `prs_per_attention_minute`; any value it cannot measure prints `unmeasured`.
 5. Each repo PR for the run branch carries exactly one integration comment.
+6. `loki verify <run-dir>/composite.json` re-checks the composite offline (add `--pubkey FILE` on another machine). It recomputes the composite hash, re-verifies every child receipt from disk and checks the signature. A tampered, swapped or stale-head child makes it TAMPERED or UNCHECKED; an unsigned child under a signed composite is UNCHECKED. Exit codes are the single-receipt ones: 0 VERIFIED, 1 TAMPERED, 2 UNCHECKED, 3 UNSIGNED. The composite never reads higher than its weakest child: one PARTIAL child caps it at PARTIAL.
+7. A run that could not seal prints `composite not sealed: <reason>` (for example a repo with no receipt). Seal by hand with `loki verify --seal-composite <run-dir>`; it refuses unless every child has a receipt.
+
+Not measured: no scale test exists for large repo counts. Claim only what you have run.
 
 `tests/workspace/99-e2e.sh` runs this whole check through both `autonomy/loki` and `bin/loki` with a stub launcher and a stub `gh`.

package/docs/dev/architecture-reference.md

@@ -105,3 +105,11 @@ These knobs together implement the RARV-C (closure) loop: findings -> override c
 ## Project memory across runs
 
 extract_learnings_from_session (autonomy/run.sh) mirrors learnings and decisions into .loki/memory/learnings/project-*.jsonl. get_relevant_learnings adds a bounded newest-first project_memory list (15 entries, LOKI_PROJECT_MEMORY_MAX_CHARS, default 2000) to .loki/state/relevant-learnings.json at run start. LOKI_PROJECT_MEMORY=0 disables both. Test: tests/test-project-memory.sh.
+
+## Verdicts, composite receipts and the autonomy ladder (v11.7.0)
+- Two sets: receipt verdicts (`engine10/types.ts` Verdict: VERIFIED, PARTIAL, ALREADY_SATISFIED, SPEC_CONFLICT, FAILED) and run outcomes (`engine10/output.ts` Outcome adds BUDGET_STOP, BLOCKED, STALLED, CANCELLED; exit ladder EXIT). Only receipt verdicts are sealed.
+- Composite: `features/speed/seal_group.ts` composeComposite/verifyComposite (schema `loki.v10.composite/1`), sealed by `loki verify --seal-composite <run_dir>`, signed with the existing `signReceipt`, capped by `capGroupVerdict`. Workspace runs seal it after integration.json.
+- Autonomy ladder: `src/policies/engine.js` allowedActions(level) (propose = none, execute = pr, operate = pr + deploy; merge never). engine10 `supervisor.ts` prGate consults `src/policies/check.js`; `loki deploy --execute` consults it for `deploy` and fails closed. `loki trust` graduationAdvice is advisory and never writes the policy file.
+- Parallel units: `route.ts` maybeRunGroup defaults to `features/speed/run_group.ts`, which freezes per-unit acceptance (`features/contract.ts`), runs units, merges with `engine10/integrate.ts` and seals once via sealGroup.
+- Lessons: every sealed run appends a receipt fact (`LOKI_AUTO_LEARN_PR`, default on) outside the receipt body; `implement.ts` injects lessons and relevant learnings inside the untrusted-data fence; `loki memory brief --task T` prints the same block.
+

package/docs/sentry-intake.md

@@ -11,3 +11,36 @@ From a URL (needs `SENTRY_AUTH_TOKEN`; without it nothing is fetched):
     SENTRY_AUTH_TOKEN=... loki start https://sentry.io/organizations/acme/issues/4001/
 
 The token is sent only to the Sentry host through a curl config on stdin, never on argv, and is never printed. Implementation: `autonomy/issue-providers.sh` (`normalize_sentry_json`).
+
+## Webhook: self-healing entry point
+
+`autonomy/trigger-server.py` accepts `POST /sentry`, a Sentry integration webhook authenticated by Sentry's own HMAC (`sentry-hook-signature`, hex HMAC-SHA256 of the body).
+
+1. Set the client secret: `LOKI_SENTRY_WEBHOOK_SECRET` (or `SENTRY_CLIENT_SECRET`). It must differ from the GitHub webhook secret and the API token. With no secret the route answers 503 and nothing is enqueued.
+2. Start the server: `python3 autonomy/trigger-server.py --port 8080` and point the Sentry alert webhook at `/sentry`.
+3. A valid alert is normalized with `normalize_sentry_json` and enqueues `loki start "<brief>" --pr --detach`. A bad signature gets 401.
+
+The output is a receipt-gated PR only, never a deploy. Whether the PR opens is still decided by the policy file (`autonomy`).
+
+
+## Slack and Linear delegation
+
+`loki trigger` server setup for delegating a job from chat or a tracker. Both routes enqueue through the same job queue and runner as `POST /jobs`; a completion summary goes back to the origin. Nothing unauthenticated can start a job or choose a reply URL.
+
+Secrets are env only and must differ from each other, the GitHub webhook secret, the API token and the Sentry secret (an equal secret disables its route at startup). A missing secret answers 503 naming the variable, and the server logs a startup warning. None of them reach the `loki start` child environment.
+
+Slack (`POST /slack`):
+
+1. Set `SLACK_SIGNING_SECRET`. Point a `/loki` slash command (and Events URL verification) at `/slack`.
+2. The signature is `v0=` + hex HMAC-SHA256 over `v0:<X-Slack-Request-Timestamp>:<raw body>`, window 300s, the same contract as `loki-ts/src/contrib/slack_inbound.ts`. Bad, stale or missing signature: 401, nothing queued.
+3. The command text is the spec (one line, not starting with `-`) and runs as `loki start <text> --detach`. Slack gets an ephemeral reply carrying the job id.
+4. On completion the summary is posted to the request's `response_url`, only if it starts with `https://hooks.slack.com/`. Any other host is never contacted.
+
+Linear (`POST /linear`):
+
+1. Set `LINEAR_WEBHOOK_SECRET`. Point a Linear issue webhook at `/linear`.
+2. `Linear-Signature` is the hex HMAC-SHA256 of the raw body, and the signed `webhookTimestamp` must be within 300s. Otherwise 401.
+3. A created issue enqueues `loki start linear:<identifier> --detach` and answers 202 with the job id. Other events are skipped.
+4. If `LINEAR_API_KEY` is set, a comment with the result is posted on the issue through `https://api.linear.app/graphql`. Without it nothing is posted.
+
+Reply targets are stored server side keyed by job id, captured only after verification. Notifier errors are logged and never fail the job. Poll status with `GET /jobs/<id>`.

package/docs/v10/CLI-MODERN.md

@@ -11,7 +11,7 @@ Classes: KEEP-MODERN (v10-native or engine-neutral), UPDATE (live but needs mode
 - DROP-LEGACY: 32
 - DELETE: 14
 - Total rows: 137
-- Registry paths (commands and nested subcommands): 190
+- Registry paths (commands and nested subcommands): 191
 
 ## Commands
 

package/docs/v10/D61-SPEED.md

@@ -89,3 +89,15 @@ With `LOKI_SPEED=1` (default off), intake no longer waits on the cheap-model alr
 ## D82-FLAGS status: default on
 
 Per the D82 founder directive, `LOKI_SPEED` is on unless set to `0` (decomposer routing, warm engine on a unix socket, stage prefix, deferred already-done check, lean keyword fallback, unit mode when `LOKI_UNIT_SPEC` is set). `LOKI_SPEED=0` restores the previous behaviour byte for byte. The other D82 opt-outs are `LOKI_VISUAL_EVIDENCE=0`, `LOKI_CONTRACT=0`, `LOKI_SLACK_INBOUND=0` (Slack stays inert until its credential is configured), `LOKI_CONTROL=0` and `LOKI_WORKSPACES=0`. Test: `loki-ts/tests/features/d82_default_on.test.ts`.
+
+## Missions and group Seal (v11.8.0)
+
+Missions: a spec with two or more milestones runs milestone by milestone. Format: `## Milestone N[: title]` headings (the body is everything up to the next milestone heading), or a top-level `milestones:` list of `- title` lines. Fewer than 2 milestones is not a mission and takes the normal path unchanged. Parsing is `parseMilestones` in `loki-ts/src/features/decompose.ts`; the loop is in `maybeRunGroup` (`loki-ts/src/features/speed/route.ts`), reached from `loki start` and from chat `/run` through the same supervisor call.
+
+Each milestone prints `loki: milestone k/N: <title>`, is decomposed on its own, and runs as its own group with its own frozen contract and group Seal. One-unit groups and sequential providers are allowed for milestones (the normal fewer-than-2-units and slot fallbacks do not apply). The mission stops at the first non-zero result, prints `loki: milestone k/N failed (exit X); rerun the same loki start to resume`, and returns that code; later milestones never start. All milestones exit 0 returns 0.
+
+Group exit codes: 0 = every unit VERIFIED and the group receipt VERIFIED; 4 = NOT PROVEN (integrated, but no checked group receipt); 1 = failures.
+
+Resume: rerun the same `loki start`. Each milestone group is found again by the hash of its body, so finished milestones re-verify and return 0 fast and the run continues at the failed one. No extra state is kept. `LOKI_GROUP_RESUME=0` disables auto-resume and starts every group fresh. Check any group receipt with `loki verify .loki/groups/<gid>/receipt.json`.
+
+Test command precedence: `LOKI_GROUP_TEST_CMD` (whitespace split) wins over the repo's own test script. Test: `loki-ts/tests/engine10/route_group.test.ts`.

package/docs/v10/PROGRESS.md

@@ -2337,3 +2337,13 @@ The swarm is stopped: .loki/V10-STOP exists, the loop has no wake-ups, and the c
 - 10.6.6 (456058bae): scope control, Control Plane v0, train-cycle fix, docs. All green. Published.
 - 10.6.7 (bfce1db12): D60 sprint, all gates, Release, Post-Release Smoke and Promote success. latest and next at 10.6.7.
 - Open at handoff: real-repo gate not wired into promote.yml and needs operator provider auth; no end-to-end exit 3 run of the cost cap; root action.yml still uses loki start --simple; about 43 worktrees under .claude/worktrees (cap 15); never push backup/train-67..70 or backup/main-pre-rebuild.
+
+## 2026-10-15T20:05Z (CoS) 11.7.1 published, v11.8.0 train started
+- 11.7.0 (8b22e5fba): Tests red on tests/test-help-changelog-drift.sh (three flags missing from help/completion) and tests/test-sigpipe-guard.sh (count 1743 over ceiling 1742). Not published.
+- 11.7.1 (a01a22740): Release and Tests completed/success (gh run watch log, runs 38794589410 and 38794589637); npm dist-tags next=11.7.1, latest=11.6.0.
+- v11.8.0 train (workflow wf_e6306e08-008): group Seal, group resume, multi-milestone missions, Slack and Linear delegation on the trigger server, receipt --max-age, deploy completion and pulse ID_RE fixes.
+
+## 2026-10-15T20:45Z (CoS) v11.8.0 failed CI, v11.8.1 fix-forward
+- v11.8.0 (b5191b999): Tests run 38800796458 and Release failed on line budgets (core engine10 5020, features 3190), the D66 fence (run_group.ts value-imported seal and verify_cmd), two unclassified checkouts in the L2 registry, macOS-first stat in tests/test-backlog-units.sh:162, and a `loki help verify` mismatch. Not published.
+- Fix 1d734e6ba (Opus HIGH review APPROVED, 162 pass 0 fail on five suites), merged as 1788db60b. The pulse ID_RE item (E-121) was not in the train and stays open.
+- Local guards on the merged tree, all rc=0: test-help-changelog-drift, test-sigpipe-guard, test-help-and-log-cap, test-backlog-units, structural-checks, test-ci-only-divergence, test-platform-infra; bun test budget, l2_destructive_registry, route_group, seal_group: 117 pass 0 fail.