loki-mode 9.54.2 → 9.55.0

package/autonomy/verify.sh

@@ -1689,14 +1689,26 @@ verify_gate_runtime() {
     local boot_log="$artifact_dir/boot.log"
 
     # Boot the app in the background, bounded by the timeout wrapper. The whole
-    # process group is killed on teardown. Env is inherited (no secrets injected).
-    # PORT is exported to the resolved port so 12-factor apps (node, many python
-    # frameworks) listen where the probe looks; apps that hardcode a port ignore
-    # it harmlessly. This keeps boot-port and probe-port consistent.
+    # process group is killed on teardown. Env is inherited (no secrets injected)
+    # PLUS one new marker: LOKI_VERIFY_RUN_TOKEN, a per-run random value used
+    # ONLY as an ownership proof at teardown (see _verify_runtime_teardown) --
+    # it identifies "a process this exact verify run launched" even after a
+    # setsid()'d daemon detaches into its own session/process group, which
+    # defeats every pgid/ppid-based check (round-4 council finding: v7.109.0's
+    # daemonize-leak fixture uses child_process.spawn({detached:true}), and no
+    # pgid/ppid arm can ever match a setsid'd process). Environment variables
+    # survive setsid() and fork()/spawn() regardless of process-group changes,
+    # so this closes exactly the gap those checks cannot. PORT is exported to
+    # the resolved port so 12-factor apps (node, many python frameworks) listen
+    # where the probe looks; apps that hardcode a port ignore it harmlessly.
+    # This keeps boot-port and probe-port consistent.
+    local run_token=""
+    run_token="verify-$$-${RANDOM}-${RANDOM}-$(date +%s 2>/dev/null || echo 0)"
     local app_pid=""
     (
         cd "$tree" || exit 127
         export PORT="$port"
+        export LOKI_VERIFY_RUN_TOKEN="$run_token"
         exec "$timeout_bin" "$boot_timeout" sh -c "$method"
     ) >"$boot_log" 2>&1 &
     app_pid=$!
@@ -1769,7 +1781,7 @@ verify_gate_runtime() {
     # Reclaim BOTH the detected port and the actually-bound port (scraped from the
     # boot log) so a server that daemonized onto a different port than we guessed
     # does not leak. scraped_port may be empty (no banner) -- teardown handles it.
-    _verify_runtime_teardown "$app_pid" "$port" "$scraped_port"
+    _verify_runtime_teardown "$app_pid" "$port" "$scraped_port" "$run_token"
 
     # Interpret the result.
     if [ "$answered" != "true" ]; then
@@ -1907,8 +1919,34 @@ SMOKE_SCRIPT
 
 # Teardown: terminate the boot launcher and any process still holding the port.
 # Bounded and best effort; never blocks the gate.
+# Does pid's environment carry LOKI_VERIFY_RUN_TOKEN=<tok> exactly? Portable
+# ownership proof that survives setsid() (see the fourth arm below for why
+# pgid/ppid checks cannot). Fails CLOSED: an empty token, an unreadable
+# environment, or any ambiguity returns "no match" -- never a false positive
+# that would authorize a kill. Checked directly (not assumed) on this
+# codebase's target platforms: Linux via /proc/<pid>/environ (NUL-separated,
+# same-uid readable); macOS/BSD via `ps -E -ww -o command=` (the `-E` flag
+# specifically requests the environment block; `-e` on BSD ps means "all
+# processes" and shows nothing extra -- do not confuse the two).
+_verify_runtime_pid_has_token() {
+    local pid="$1" tok="$2"
+    case "$pid" in ''|*[!0-9]*) return 1 ;; esac
+    [ -n "$tok" ] || return 1
+    if [ -r "/proc/$pid/environ" ]; then
+        tr '\0' '\n' < "/proc/$pid/environ" 2>/dev/null | grep -qxF "LOKI_VERIFY_RUN_TOKEN=$tok"
+        return $?
+    fi
+    if command -v ps >/dev/null 2>&1; then
+        case " $(ps -E -ww -o command= -p "$pid" 2>/dev/null) " in
+            *" LOKI_VERIFY_RUN_TOKEN=$tok "*) return 0 ;;
+            *) return 1 ;;
+        esac
+    fi
+    return 1
+}
+
 _verify_runtime_teardown() {
-    local app_pid="$1" port="$2" scraped_port="${3:-}"
+    local app_pid="$1" port="$2" scraped_port="${3:-}" run_token="${4:-}"
     if [ -n "$app_pid" ]; then
         # Best: kill the launcher's whole process GROUP so a server it spawned in
         # a subshell (e.g. `vite &`) dies too. GUARDED against self-suicide: in a
@@ -1943,6 +1981,22 @@ _verify_runtime_teardown() {
     # Reclaim BOTH the detected port and the actually-bound (scraped) port from
     # any orphan that outlived the launcher -- a daemonized server that bound a
     # different port than we guessed would otherwise leak. Bounded, best effort.
+    #
+    # SCOPING (D14/D15/D16 class): `lsof -ti tcp:$port` alone, with no
+    # -sTCP:LISTEN filter, matches EVERY socket referencing that port number,
+    # including a CLIENT with an established connection whose remote port
+    # happens to be $port (e.g. a browser tab open to localhost:$port) -- that
+    # process gets SIGKILL'd even though it never bound anything. And with no
+    # ownership check at all, ANY process (this run's or not) listening on the
+    # reused port gets killed. Fixed to (1) filter to LISTEN sockets only, and
+    # (2) verify each candidate is actually part of THIS launcher's tree before
+    # killing it: its pgid matches $child_pgid (the group this teardown just
+    # tried to signal above), or its direct parent is $app_pid. A holder that
+    # matches neither is left alone -- this run never bound that port, so it
+    # never reclaims it. Trade-off: a server that called setsid() into a fresh
+    # session AND was reparented away from app_pid (neither condition holds)
+    # will leak here; failing closed on an unverified kill is the safer
+    # direction (see docs/v10/DECISIONS.md D14/D15/D16).
     if command -v lsof >/dev/null 2>&1; then
         # Build a unique, non-empty port list (scraped only if it differs).
         local _ports="$port"
@@ -1951,10 +2005,62 @@ _verify_runtime_teardown() {
         for _rp in $_ports; do
             [ -z "$_rp" ] && continue
             local holders
-            holders="$(lsof -ti tcp:"$_rp" 2>/dev/null || true)"
+            holders="$(lsof -ti tcp:"$_rp" -sTCP:LISTEN 2>/dev/null || true)"
             if [ -n "$holders" ]; then
                 printf '%s\n' "$holders" | while IFS= read -r pid; do
-                    [ -n "$pid" ] && kill -9 "$pid" 2>/dev/null || true
+                    [ -z "$pid" ] && continue
+                    local _h_pgid="" _h_ppid=""
+                    _h_pgid="$(ps -o pgid= -p "$pid" 2>/dev/null | tr -d ' ' || true)"
+                    _h_ppid="$(ps -o ppid= -p "$pid" 2>/dev/null | tr -d ' ' || true)"
+                    # THIRD ARM (council round 2, REJECT reproduced and fixed):
+                    # GNU `timeout` (this codebase's launcher, verify.sh:1699)
+                    # makes ITSELF the process-group leader, so the group's
+                    # pgid equals timeout's own pid, which equals app_pid (the
+                    # subshell execs straight into timeout with no fork). If
+                    # the launched command daemonizes -- forks a server and
+                    # the parent (timeout, then sh -c) exits -- by teardown
+                    # time: child_pgid is EMPTY (timeout already exited, so
+                    # `ps -o pgid= -p "$app_pid"` finds nothing); the orphan's
+                    # ppid is 1, not app_pid; but its pgid is STILL app_pid,
+                    # the value it inherited when timeout created the group.
+                    # Neither of the two arms above can ever match this case,
+                    # so the classic "daemonized" leak this function's own
+                    # comments describe was never reclaimed. Reproduced
+                    # directly: own daemon listener LEAKED pre-this-arm,
+                    # reclaimed after. Safe as an ownership proof, not a
+                    # loosening: a process group's pgid cannot be reassigned
+                    # to an unrelated group while any member of the original
+                    # group (here, the orphan itself, still alive and
+                    # reporting this exact pgid) still exists -- POSIX pgid
+                    # reuse is blocked until the whole group is empty.
+                    # FOURTH ARM (council round 4, 2 of 4 reviewers REJECTed
+                    # with an identical reproduction; verified independently
+                    # before applying): a process launched via
+                    # child_process.spawn({detached:true}) (Node's setsid()
+                    # wrapper) becomes its OWN session and process group
+                    # leader -- its pgid equals its OWN pid, not app_pid or
+                    # child_pgid, and its ppid is 1. None of the three arms
+                    # above can ever match that shape, which is exactly
+                    # test-runtime-gate.sh case I's fixture (the v7.109.0
+                    # daemonize-leak regression test) and a real pattern many
+                    # servers use to daemonize. Environment variables survive
+                    # setsid()/fork()/exec() regardless of process-group
+                    # changes, so LOKI_VERIFY_RUN_TOKEN (exported into the
+                    # launched app's env at boot, see the launch site above)
+                    # is checked here as a portability-verified ownership
+                    # proof (see _verify_runtime_pid_has_token; confirmed
+                    # directly on macOS with `ps -E -ww`, not assumed).
+                    # Residual, disclosed gap: a daemon that scrubs its own
+                    # environment (env -i, some process supervisors) before
+                    # detaching still leaks -- no ownership proof survives
+                    # that, and failing closed on an unverified kill remains
+                    # the safer direction.
+                    if { [ -n "$child_pgid" ] && [ -n "$_h_pgid" ] && [ "$_h_pgid" = "$child_pgid" ]; } \
+                       || { [ -n "$app_pid" ] && [ -n "$_h_ppid" ] && [ "$_h_ppid" = "$app_pid" ]; } \
+                       || { [ -n "$app_pid" ] && [ -n "$_h_pgid" ] && [ "$_h_pgid" = "$app_pid" ]; } \
+                       || _verify_runtime_pid_has_token "$pid" "$run_token"; then
+                        kill -9 "$pid" 2>/dev/null || true
+                    fi
                 done
             fi
         done

package/bin/loki

@@ -348,6 +348,18 @@ if [ "${1:-}" = "trust" ]; then
     done
 fi
 
+# `doctor --airgap` (egress audit) lives only in bash (_loki_airgap_audit).
+# The Bun doctor rejected the flag, so the default route had no audit at all.
+# Routed here, flag-anywhere, so the committed dist needs no rebuild and bash
+# stays the single implementation; bash main() fires the one cli_command event.
+if [ "${1:-}" = "doctor" ]; then
+    for _doctor_arg in "${@:2}"; do
+        if [ "$_doctor_arg" = "--airgap" ]; then
+            exec "$BASH_CLI" "$@"
+        fi
+    done
+fi
+
 # CLI consolidation (Phase B): `report kpis` is the canonical form of the
 # Bun-only KPI snapshot. The `report` noun is otherwise bash-owned (every other
 # subcommand -- session/metrics/cost/export/share/dogfood -- routes to bash

package/dashboard/__init__.py

@@ -7,7 +7,7 @@ Modules:
     control: Session control API (start/stop/pause/resume)
 """
 
-__version__ = "9.54.2"
+__version__ = "9.55.0"
 
 # Expose the control app for easy import
 try:

package/docs/INSTALLATION.md

@@ -115,11 +115,12 @@ commands and forward-compat with v8.0.0.
 - Installs the `loki` CLI binary to your PATH (`bin/loki` shim)
 - Subsequent `loki setup-skill` creates symlinks at `~/.claude/skills/loki-mode`, `~/.codex/skills/loki-mode`
 
-**Anonymous telemetry is OPT-IN and OFF by default.** A default `npm install`
-sends nothing, so air-gapped and enterprise installs are safe out of the box. To
-opt in to anonymous diagnostics, run `loki telemetry on` or set
-`LOKI_TELEMETRY=on`. To make opting in impossible across a fleet, bake an
-opt-out into your base image (opt-out always wins):
+**Anonymous telemetry is ON by default for an individual interactive install**
+and auto-off in CI, non-interactive sessions, and when `LOKI_ENTERPRISE=true` or
+`LOKI_AIRGAP=true` is set. It is disclosed once on first use. Turn it off with
+`loki telemetry off`; `loki doctor --airgap` shows its current state. To make
+opting in impossible across a fleet, bake an opt-out into your base image
+(opt-out always wins):
 ```bash
 # Hard-disable everywhere (belt and suspenders; opt-out always wins):
 LOKI_TELEMETRY_DISABLED=true npm install -g loki-mode

package/docs/air-gapped.md

@@ -45,31 +45,53 @@ That is the property competitors' dashboard-bound verification cannot have.
 ## The one required egress, stated plainly
 
 ```sh
-LOKI_LEGACY_BASH=1 loki doctor --airgap
+loki doctor --airgap
 ```
 
-The `LOKI_LEGACY_BASH=1` prefix is required for now: the default (Bun) route
-does not yet accept the `--airgap` flag (tracked as
-`P5.airgap-audit-default-route`), so plain `loki doctor --airgap` fails on a
-default install.
-
-Once run, it prints the egress inventory. Today it reports exactly one REQUIRED point:
+`bin/loki` routes the flag straight to the bash audit regardless of route, so
+no `LOKI_LEGACY_BASH=1` prefix is required. It prints the egress inventory. On
+a default install it reports exactly one REQUIRED point:
 
 ```
 REQUIRED  model inference -> https://api.anthropic.com
-          Set ANTHROPIC_BASE_URL to an in-network gateway, or switch to a
-          local-weights provider.
-optional  telemetry  [off]  disable: loki telemetry off (default off)
+optional  telemetry           [on]  -> https://us.i.posthog.com
+optional  update check        [on]  disable: export LOKI_NO_UPDATE_CHECK=1
 ```
 
-**We cannot run a build with no model at all.** Nobody can. What we can do is
-let you point at a model you host: set `ANTHROPIC_BASE_URL` to an in-network
-gateway, or run a provider with local weights. The engine abstracts over CLIs
-rather than over one vendor's API.
+It judges the provider `loki start` would use (the project's saved
+`loki provider set` choice, else `LOKI_PROVIDER`), and runs on both the default
+route and `LOKI_LEGACY_BASH=1`. `--json` gives the same inventory for scripts.
+It covers the egress the engine configures, and names what it does not audit
+because it depends on the project: package installs (the app runner's npm, pip
+and docker steps for the built app, the dashboard venv from PyPI, and
+quality-gate tools fetched by `npx` when not installed locally; mirror or
+pre-install them, since a failed `npx` fetch fails that gate) and the delegate
+PR (`git push` and `gh pr create` after a successful run when `gh` is
+installed; `LOKI_DELEGATE_PR=0` turns it off).
+
+With a non-claude provider selected, `loki start` on the default (bash) route
+and `loki quickstart` never prompt the `claude` CLI, even when one is
+installed: PRD enrichment, done recognition, the council voters, the USAGE.md
+refresh and the quickstart intent check fall back to their deterministic
+paths. The opt-in Bun loop (`LOKI_SDK_LOOP=1`) is not yet held to this.
+`LOKI_ALLOW_CLAUDE_SIDECALLS=1` restores those claude calls, and the audit then lists them as REQUIRED egress, so it cannot read air-gap ready.
 
-Telemetry is off by default and every opt-out wins (`DO_NOT_TRACK=1`,
-`LOKI_TELEMETRY=off`, `~/.loki/config`). The adoption instrumentation added in
-v8.6.0 requires a second explicit opt-in on top of that -- see
+**We cannot run a build with no model at all.** Nobody can. What we can do is
+let you point at a model you host. Only a local-weights provider clears the
+required line: opencode, cline or aider with an `ollama/` or `lmstudio/` model
+id in that provider's own variable (for example
+`LOKI_OPENCODE_MODEL=ollama/qwen2.5-coder`). An Ollama cloud model (a `:cloud`
+or `-cloud` tag) runs on ollama.com and is still reported as required. The
+verdict comes from the model id; the audit does not read where your Ollama or
+LM Studio endpoint listens, so confirm that yourself. An in-network gateway for
+claude or codex (`ANTHROPIC_BASE_URL`, `OPENAI_BASE_URL`) keeps traffic inside
+your network, but the audit still counts it as required egress.
+
+Telemetry is ON by default for an individual interactive install and auto-off
+in CI, non-interactive, `LOKI_ENTERPRISE=true` and `LOKI_AIRGAP=true`
+contexts. The audit shows its real state. Every opt-out wins (`DO_NOT_TRACK=1`,
+`LOKI_TELEMETRY=off`, `loki telemetry off`). The adoption instrumentation added
+in v8.6.0 requires a second explicit opt-in on top of that -- see
 [PRIVACY.md](./PRIVACY.md).
 
 ## Why `unknown` is the right answer offline

package/docs/enterprise/security.md

@@ -334,11 +334,11 @@ All Loki Mode data is stored locally on the machine running the system:
 | Policy files | `.loki/policies.yaml` or `.loki/policies.json` |
 | Configuration | `.loki/config.yaml` or `.loki/config.json` |
 
-No data is transmitted to external services unless explicitly configured (OTEL endpoint, integration webhooks, syslog forwarding).
+Beyond model inference (required unless you run a local-weights provider), anonymous telemetry (on by default for individual interactive installs, auto-off in CI, non-interactive and `LOKI_ENTERPRISE=true` / `LOKI_AIRGAP=true` contexts) and a daily update check, no data is transmitted to external services unless explicitly configured (OTEL endpoint, integration webhooks, syslog forwarding). `loki doctor --airgap` prints the egress inventory for the current configuration.
 
 ### Provider Restrictions
 
-The data residency controller restricts which AI providers can be used based on region:
+The data residency controller (`src/audit/residency.js`, configured in `.loki/residency.json`) answers whether a provider is allowed by a region or air-gapped policy. It is a library check: `loki start` does not consult it today, so setting `air_gapped: true` does not by itself stop a run from calling a hosted provider. Use `loki doctor --airgap` and network policy to enforce that.
 
 ```javascript
 const audit = require('./src/audit');
@@ -351,17 +351,14 @@ const allowed = audit.checkProvider('anthropic', 'us');  // true/false
 const airGapped = audit.isAirGapped();
 ```
 
-Configure via `.loki/config.yaml`:
-
-```yaml
-residency:
-  allowed_providers:
-    - anthropic
-    - openai
-  allowed_regions:
-    - us
-    - eu
-  air_gapped: false
+Configure via `.loki/residency.json` (the file `residency.js` reads):
+
+```json
+{
+  "allowed_providers": ["anthropic", "openai"],
+  "allowed_regions": ["us", "eu"],
+  "air_gapped": false
+}
 ```
 
 ## Policy Engine Security

package/docs/environment-variables.md

@@ -42,6 +42,7 @@ interact and why hitting one is a failure rather than a success.
 | `LOKI_MAX_TIER` | unlimited | Caps model tier, so a run cannot escalate past what you are willing to pay for. |
 | `LOKI_MODEL_OVERRIDE` | unset | Overrides the resolved model outright. |
 | `LOKI_TIER` | `oss` | **Not a model setting.** The open-core licensing seam. Leave it unset. |
+| `LOKI_ALLOW_CLAUDE_SIDECALLS` | unset | `1` (exactly) lets PRD enrichment, done recognition, the council voters, the USAGE.md refresh and the quickstart intent check prompt the `claude` CLI under a non-claude provider; `loki doctor --airgap` then reports that as required egress to Anthropic. |
 
 ### Picking a model without naming one
 

package/docs/exit-codes.md

@@ -75,8 +75,8 @@ codes on the Bun route and the bash route (`LOKI_LEGACY_BASH=1`).
 | Code | Meaning |
 |---|---|
 | 0 | Clean: the integrity hash matches and the recorded diff still matches the repo (and, with `--jwks`, the attestation is VERIFIED) |
-| 1 | Tampered or drifted; or, with `--jwks`, the attestation FAILED, or is ABSENT (the receipt is unsigned while a key set was supplied) |
-| 2 | Could not check: the receipt is present but unusable (malformed JSON), the verifier itself is missing, or, with `--jwks`, the attestation is NOT CHECKED (key set unreadable, or a verifier dependency missing) |
+| 1 | Tampered, or genuinely drifted (the working tree really changed since the recorded base); or, with `--jwks`, the attestation FAILED, or is ABSENT (the receipt is unsigned while a key set was supplied) |
+| 2 | Could not check: the receipt is present but unusable (malformed JSON), the verifier itself is missing, drift could not be re-derived (verified outside a git tree, or the recorded base ref no longer resolves, with every other check passing) rather than genuinely found, or, with `--jwks`, the attestation is NOT CHECKED (key set unreadable, empty, or a verifier dependency missing) |
 | 64 | Usage error: no proof id, more than one proof id, an unknown option (a mistyped `--jwk` must never skip the check), `--jwks` with no value or an empty one, or `-h`/`--help` (verify never exits 0 without a verdict; full help is `loki proof help`). `--` ends options, so `loki proof verify -- <id>` checks an id that begins with `-` |
 | 66 | Input missing: no `.loki/proofs/<id>/proof.json` for that id |
 
@@ -94,6 +94,80 @@ purpose: it rolls up many stages, and an operator who fixes the named FAILED
 stage and re-runs would see green while still blind on the stage that never
 ran (`tools/verify-chain.py`, rule 4).
 
+## `loki start --remote` receipt check (not a verify command)
+
+This is a documented DIVERGENCE from `proof verify`, not a bug. `loki start
+--remote <url>` submits a build to a deployed cluster (`loki_remote_submit`,
+`autonomy/loki`), and after the job finishes it fetches the Evidence Receipt
+and runs an internal check (`loki_remote_verify_receipt`) that prints one of
+several verdict words also used elsewhere in `loki proof`: VERIFIED, UNSIGNED,
+NOT CHECKED, TAMPERED, plus its own NOT VERIFIED when the verifier itself is
+unavailable (a fifth, distinct string -- see the last row below). Despite the
+shared vocabulary, this is not the `proof verify` contract and does not return
+its codes.
+
+`loki_remote_verify_receipt` is an internal helper, never a standalone
+command. Its return value feeds `_receipt_rc` inside `loki_remote_submit` via
+`loki_remote_fetch_receipt` (`autonomy/loki`), whose own last statement is the
+verify call with no `||` to reset the status -- so the helper's return code
+propagates out unchanged. `loki_remote_submit` then checks `_receipt_rc`
+BEFORE ever looking at job status:
+
+| Receipt verdict | Helper return | Process exit |
+|---|---|---|
+| VERIFIED (gpg or attestation) | 0 | Governed by the job status below |
+| UNSIGNED | 0 | Governed by the job status below |
+| NOT CHECKED -- gpg unavailable on this machine, or an attestation present but unreachable/uncheckable (JWKS unreachable, crypto missing) | 0 | Governed by the job status below |
+| NOT CHECKED -- signed, but the signing key is not in the verifier's keyring (gpg `nopubkey`), and no valid attestation covers it | 1 | 1, unconditionally |
+| NOT VERIFIED -- the local verifier itself is unavailable (no python3, or `lib/proof-verify.py` missing) | 0 | Governed by the job status below |
+| TAMPERED (bad hash, bad gpg signature, bad attestation) | 1 | 1, unconditionally |
+
+The exit code `loki start --remote` actually returns is gated on the job's own
+terminal status (`passed` / `failed` / `unknown`) in most cases, but there are
+TWO deliberate overrides that fail the whole submit regardless of job status,
+not one:
+
+- **TAMPERED** (bad hash, bad gpg signature, bad attestation): an accusation
+  that the receipt itself was altered.
+- **NOT CHECKED / nopubkey** (signed, but the verifying machine does not hold
+  the signing public key, and no attestation proves it another way): per the
+  code's own comment at this branch (`autonomy/loki:1081-1084`), this is
+  "Non-zero: a caller who asked for a signed receipt did not get proof, and in
+  CI that must not pass silently." It is explicitly NOT an accusation of
+  tampering -- the message says plainly that nothing is wrong with the
+  contents -- but it still fails the submit, because a signed remote build
+  whose signature could never be checked is exactly the case this override
+  exists to catch. Concretely: a build can be genuinely signed, actually pass,
+  and still make `loki start --remote` exit 1, if the verifying machine simply
+  never imported the publisher's key and no JWKS attestation is available to
+  cover the gap.
+
+Every other outcome -- VERIFIED by either gpg or attestation, UNSIGNED, the
+gpg-unavailable/attestation-uncheckable NOT CHECKED case, and the
+verifier-unavailable NOT VERIFIED case -- returns 0 from the helper and
+defers entirely to job status, because none of those contradicts the job's
+reported outcome.
+
+This is why remote NOT CHECKED can exit 0 in some branches and 1 in others,
+while `loki proof verify`'s NOT CHECKED always exits 2: they answer different
+questions. `proof verify` IS the verdict -- its only output is "was this
+receipt proven", so an unproven result can never exit 0. The remote helper's
+verdict is a secondary integrity check bolted onto a job-status command whose
+primary question is "did the build pass"; most unprovable outcomes do not
+change that answer, but the nopubkey case is carved out by the code itself as
+a hard failure, and TAMPERED always is. (`_deploy_receipt_verdict`'s own
+header comment, elsewhere in `autonomy/loki`, makes the same point about this
+helper for the UNSIGNED case specifically -- "that function returns 0 for
+UNSIGNED, which is right for its caller (submit) and wrong here (integrity is
+not provenance)" -- it does not speak to NOT CHECKED, whose nopubkey behavior
+is documented at its own branch as cited above.)
+
+To get the `proof verify` exit-code contract (0/1/2/64/66) against a receipt
+fetched from a remote build, run `loki proof verify <job-id>` afterward
+against the written `.loki/proofs/<job-id>/proof.json` -- that is a genuine
+verify call and returns the codes documented above, not the ones in this
+section.
+
 ## `loki proof chain [workspace]`
 
 Runs the whole verification chain (`tools/verify-chain.py`) and passes its exit

package/docs/v10/BACKLOG.md

@@ -170,6 +170,29 @@ Status values: todo, in progress, shipped (version), parked (reason).
 123. **More verdict-class leftovers from the 113 sweep:** the `audit.py verify` CLI and `compute_chain_tip_in_dir` still report valid, exit 0, when nothing was checked (the cross-chain verifier reads them, so changing them needs its own review); the cockpit, overview, checklist, gate-card, standalone, proofs.html and cost.html verdict relabels have no test of their own (only the receipt and audit surfaces are pinned by the moat case); the standalone receipt list shows the oldest receipts first (see 118).
 124. **Dashboard innerHTML audit:** the standalone receipt and learning panels interpolated run-written text into innerHTML unescaped (fixed in cycle 4, `f6050ef1`, with hostile-input tests). No systematic audit of the other `innerHTML` sites in `dashboard-ui/components` and `build-standalone.js` has been done; add a guard that flags a template literal or string concatenation of a response field into innerHTML without an escape.
 
+125. **P7 scanner (`tests/moat/p7-no-fabricated-data.sh`) bypass shapes found by PF-2 round 5's review but not fixed there (pre-existing before and after `fa5de15f`, not a regression -- each is a candidate for its own small slice):**
+    - **B-1 reassignment fallback:** `let rows = data; if (!rows.length) rows = [rows]; setRows(rows);` -- `DECL_ARR` only matches the `const/let/var x = [` declaration, never a later bare `x = [` assignment.
+    - **B-2 destructuring / parameter defaults:** `const { rows = [rows] } = data;` or `function load(rows = [rows]) {}` -- neither is a declaration of the form `name = [`.
+    - **B-3 object-property value on `this.x` outside a setter:** `this._state = { phases: [rows] };` -- `THIS_ARR` needs `this.x = [` directly, misses a literal nested inside an object RHS.
+    - **B-4 paren-wrapped `||`/`??` outside a setter:** `this._rows = d.rows || ([rows]);` -- `FALLBACK_ARR` requires `[` immediately after the operator; a wrapping `(` defeats it (the setter-argument span arm already catches this shape inside a setter call).
+    - **B-5 module-level named fallback table:** `const FALLBACK_ROWS = [rows];` at column 0, used later as `data.length ? data : FALLBACK_ROWS` -- the column-0 exemption plus the identifier-branch ternary both let it through; rule 7's name-based catch only fires if the constant name contains sample/mock/demo/fake/placeholder.
+    - **B-6 ternary against `null`/`undefined`:** `const r = loading ? null : [rows];` -- `is_literal(null)` is true, so the both-branches-literal exemption suppresses it; should only treat an array/object literal (never null/undefined/empty-string) as the "literal other branch."
+    - **B-7 fabricated data returned from a helper:** `function getRows(d) { if (!d) return [rows]; return d; }` then `setRows(getRows(d))` -- no arm follows a function's return value.
+    - **B-8 `Array.from` generator producing invented rows:** `Array.from({ length: 3 }, (_, i) => ({ id: i, action: 'Deployed', user: 'Admin' }))` -- the `Array.from` arm only checks a literal first argument, not a generator callback whose body invents field values.
+    - Two more from the same review, not yet given IDs: a positive-control risk (a real typed options list chosen against live data, e.g. `isAdmin ? adminOpts : [{value:'view',...}]`, could false-positive under the ternary/setter-span arms -- fix with an allow-annotation if it ever fires on real code, don't weaken the arm); and re-running `tests/moat/p6-*.sh` in isolation to confirm its 300s timeout during the PF-2 review was purely a load artifact (load average ~30 from concurrent session agents), not a real regression the merge introduced.
+
+126. **(CORRECTED and CONFIRMED as a real CI-breaking bug, not just a local artifact -- see the retraction below.) `tests/test-airgap-ollama-host.sh` does not isolate `.loki/state/`, so a stale `.loki/state/provider` file written by an EARLIER test IN THE SAME CI SHARD's shared checkout silently overrides the test's own `LOKI_PROVIDER=opencode` env var** (the CLI's own precedence rule: saved project state wins over the env var, by design). This actually broke `Tests` (shard 3/4) in CI on `ba6610dc` -- root-caused by reproducing the exact CI shard-3 sequence locally: `tests/test-iteration-grace.sh` sources `autonomy/run.sh` from the shared repo checkout's CWD (not its own isolated `$SCRATCH` dir) at two call sites (`probe()`, ~line 42 and ~109), and `autonomy/run.sh:1741-1744`'s provider auto-detection writes `.loki/state/provider` as an unconditional side effect of sourcing. Every later test in the same shard's shared checkout inherits that leftover file. Removing it reproduces the airgap test passing again; the CI failure is not a local-checkout coincidence. **Retraction**: an earlier draft of this item concluded the opposite (called it "not a product bug", attributed it purely to local manual-testing residue, and proposed fixing only `test-airgap-ollama-host.sh`'s own isolation) -- that conclusion was WRONG. It was drawn from a local reproduction where I had ALSO independently left a stray `.loki/state/provider` in my own manual testing, which coincidentally matched the CI symptom and stopped the investigation short of finding the real cross-test contamination source. Lesson: a reproduced symptom is not the same as a verified mechanism -- confirm the EXACT trigger, not just that removing the artifact makes the symptom go away. Two fixes landed and merged: `test-iteration-grace.sh` (`b3d7cdda`) and `test-exit-code-contract.sh` (`e05e09fb`), both isolating CWD before sourcing `run.sh`. Verifying the shard is now clean surfaced a THIRD contaminator: `tests/test-code-review-self-copy.sh` sources a self-copy of `run.sh` with NO `cd` at all. Fix dispatched. This bug class (source `run.sh`, or a copy of it, before `cd`ing into an isolated scratch dir) has now appeared in at least 3 registered-in-CI files; `test-review-diff-moat.sh` also reproduces it standalone but is not registered in any CI path today (orphaned test, latent bug, not a current shard contributor). A systematic repo-wide sweep for this exact pattern (`source .*run\.sh` or a self-copy of it, with no preceding isolating `cd`) is now clearly warranted as its own slice, rather than continuing to discover instances one CI failure at a time -- each new fix's own verification pass keeps finding the next one. **FIXED (2026-09-27, merge 41c2f604):** the repo-wide sweep closed 22 more files (19 originally scoped plus 3 new instances found mid-sweep: `test-doc-scope-generator.sh`, `test-p0-gate-behavior.sh`, `tests/council/test_managed_review_flag.sh`, the last of which sources the bug via a real `bash run.sh --help` subprocess, not just `source`). Verified: all 22 run clean in sequence with no `.loki/state/provider` left behind, the victim test then passes 4/4, moat suite matches main exactly (3 of 9, no rule failed), shellcheck clean. Also independently isolated at the victim side: `test-airgap-ollama-host.sh` now sets its own `LOKI_DIR` (`0f056336`), so it is immune regardless of any remaining, still-undiscovered contaminator elsewhere in the suite. **Retroactive quorum (2026-09-27):** this MEDIUM-tier merge shipped without its 2-reviewer quorum first (a real process gap, self-caught and disclosed in PROGRESS.md). Reviewer 2/2 (Sonnet) returned APPROVE: independently re-derived the root cause (found it is actually UNCONDITIONAL, firing even when `LOKI_PROVIDER` was explicitly set, not just on auto-detect -- a stronger bug than originally described), redid the 23rd-instance search after an advisor-caught blind spot in the first pass (~35 additional call sites found repo-wide, all already isolated or targeting unrelated scripts, none a missed instance), and added a RED-check not in the original ask: removed one file's `cd` fix in an isolated worktree, reproduced the exact original bug (`.loki/state/provider` written into the worktree root), then confirmed reverting the fix restored green. No blocking findings. Reviewer 1/2 (Opus) independently also returned APPROVE: byte-diffed pre/post output across all 22 files (differs only by the 2 new isolation lines), confirmed the sleep-plus-`-nt` mutation harness is genuinely load-bearing (found `test-exit-code-contract.sh` passes VACUOUSLY on real bash 3.2 without the sleep, even while contaminated -- so the sleep is not cosmetic there), ran all 22 through a real 4-shard parallel `tests/run-all-tests.sh` invocation matching local-ci's own sharding with no leaks, and confirmed the moat suite's 2-of-9 (vs. 3-of-9 on a fully-provisioned checkout) is a fresh-worktree `node_modules`-absence artifact, not a regression. **Retroactive quorum: 2/2 APPROVE, no blocking findings from either reviewer -- gap closed.** Both reviewers flagged the same non-blocking point independently: `test-airgap-ollama-host.sh` no longer actually detects this bug class (it was isolated separately via `LOKI_DIR` in `0f056336`), so the real regression detectors going forward are each of the 22 files' own new `-nt` checks, not the original victim test.
+
+127. **(CORRECTED 2026-09-26: an earlier draft of this item claimed `56eb866f` was already merged and fixed. It was reviewed and unanimously approved same-session as S-22 but never actually merged -- a real gap on main until now. Now genuinely fixed and merged: `56eb866f` merged via a dedicated merge commit, pushed. `council_should_stop`'s shadow-write block is now skipped entirely when `PROJECT_DIR` is unset, plus -E on the python3 call; real code-execution RED/GREEN confirmed via a live marker-file demonstration, polled across the backgrounded+disowned call.) Sibling of BACKLOG 63 (S-22): `council_should_stop` (~line 4635 in `autonomy/completion-council.sh`) had the identical unguarded `cd "${PROJECT_DIR:-$(pwd)}"` pattern feeding `python3 -m memory.managed_memory.shadow_write` -- more severe than S-22's own retrieve-path bug since this one EXECUTES a module, not just imports it for reading.** Two more copies of this pattern remain open: `autonomy/run.sh:19861` has the identical unguarded `cd "$PROJECT_DIR" && python3 -m memory.managed_memory.shadow_write` (found during the `56eb866f` fix, not fixed there, out of that slice's file set -- same fix shape needed); `autonomy/completion-council.sh:4204` (`council_managed_should_stop`) has `project_dir="${PROJECT_DIR:-$(pwd)}"` but only feeds a `git diff` read, not a python module execution, gated behind the narrower `LOKI_EXPERIMENTAL_MANAGED_AGENTS` flag -- lower severity, still worth the same guard for consistency.
+
+128. **Stale documentation asserts a `{"runner":"none","pass":true}` writer shape that doesn't exist.** Found while fixing S-07's rework #2 (BACKLOG 33): `references/core-workflow.md:81` and `docs/VERIFIED-COMPLETION-PLAN.md:90,315,316` assert the same false shape corrected in D20 (the real writer, `enforce_test_coverage` at `run.sh:12691-12692`, writes `pass:"inconclusive"`, a string, never boolean `true`). Not behaviorally load-bearing (nothing parses these docs at runtime) but misleading to a future reader. Also: `tests/test-council-devils-advocate.sh` Case 2, `tests/test-da-veto.sh`, `tests/test-council-convergence-floor.sh:92` use synthetic `pass:true` fixtures instead of the real writer shape -- harmless today since `runner=='none'` is unconditional at every site that reads them, but should be replaced with the real shape for honesty.
+
+129. **FIXED.** S-24's tamper-detection seal (BACKLOG 70) only hardened the DIGEST computation, not the snapshot WRITER/READER paths. Found by the adversarial reviewer of the awk-bypass fix (c315cbe9): `_loki_untracked_merge` (writes `preexisting-untracked.z`), `_loki_covered_paths` (reads it after verify), and `_loki_untracked_status`'s `git` invocation were all still bare PATH lookups (`python3 -E`, not `-I` + absolute path; `git` unresolved). An agent that plants a malicious `.pth` file or a fake `python3`/`git` earlier on PATH during one session could forge the CONTENT of the snapshot file itself before the (correctly hardened) seal ever computed its digest over that already-forged content -- the seal then faithfully approved the forgery. Reproduced both classes empirically before fixing: (a) a `.pth` in user site-packages fired arbitrary code during `_loki_untracked_merge`'s and `_loki_covered_paths`'s `python3 -E` calls and could rewrite their declared output after the legitimate write; (b) a fake `git` shadowing the real one on PATH caused `_loki_untracked_status` to omit a real untracked path from its output, which then propagated all the way into the sealed snapshot as if that path never existed. Fixed by adding `_loki_snapshot_py_tool` and `_loki_snapshot_git_tool` (same fixed-root-path-first pattern as `_loki_snapshot_hash_tool`, each candidate probed with a real run, not just `-x`) and routing every python3/git call in the writer chain through them: `_loki_untracked_merge`, `_loki_covered_paths` (both now `-I -S`, not just `-E`/`-I` -- `-S` is required to skip `import site` entirely: `-I` implies `-s` and already skips USER site-packages, but not the resolved interpreter's OWN site-packages directory, which on a Homebrew-installed python3 is itself user-writable; `/usr/bin/python3`'s own site-packages is root-owned, so `-I` alone would suffice there specifically, but `-S` is the correct universal fix since the resolver can fall back to a PATH interpreter), `_loki_untracked_status`, `_loki_tracked_by_user_since_anchor` (feeds the writer's "tracked" exclusion set), `_loki_snapshot_preexisting`'s own `rev-parse --show-toplevel`, and the `hash-snapshot` invocation that writes `.sha.z` (the sibling sealed file). Post-fix, both reproduced bypasses were re-run and confirmed closed (the `.pth`/fake-git have zero effect on the writer/reader's actual output). **Explicitly out of scope, left as BACKLOG 131**: `_loki_untrack_agent_committed_user_files`'s five bare `git` calls (feed the READER, `_loki_covered_paths`, with the paths it checks) and the bare `git reset`/`git commit`/`git update-index` calls in the commit path itself -- a fake git already defeats the commit gate directly at commit time regardless of what the snapshot says, so resolving only the reader's git feed would not change that attacker's achievable outcome; a real fix needs a process-wide resolved-git convention, tracked separately rather than folded into this change.
+130. **S-24 follow-up, non-blocking, from the same review round:** (a) `_loki_snapshot_verify`'s `SNAPSHOT_TAMPERED` audit log doesn't record the live vs. sealed digest values, so an operator can't distinguish a genuine content change from a flaky hash-tool failure (both produce the identical message) -- add both digests to the audit line; (b) a verify-then-read race exists between `_loki_untrack_agent_committed_user_files`/`commit_session_changes`'s verify call and their later file read, where a background process could swap the file in between (compounded by BACKLOG 129's reader-side exposure, now narrowed by the BACKLOG 129 fix but not closed for the git-fed paths -- see BACKLOG 131); (c) `.loki/state/session-created.z` is not covered by the seal at all -- an agent could add a user's pre-existing files to it, causing a later resume to leave those files out of the snapshot and commit them as session work.
+131. **Process-wide resolved-git convention needed (split out of BACKLOG 129's fix scope); reviewed 4 times total across two rounds (2/2 then a 2/2 top-up, all four APPROVE), with corrections from both rounds folded in below.** `_loki_untrack_agent_committed_user_files` (autonomy/run.sh:9969-10022; CORRECTED 2026-09-27: 9 bare `git` calls in this one function, not "5" as an earlier draft said -- `git rev-parse --verify` (9982), `git merge-base` x2 (9984, 9988), `git cat-file` (9989), `git rev-parse --show-toplevel` (9999), `git -C diff` (10000), `git reset` (10013), `git -C update-index` (10014), `git commit` (10015); the reset/update-index/commit trio is INSIDE this same function, not in `commit_session_changes` as an earlier draft misattributed -- `commit_session_changes` starts at line 10024 and has its own separate `git reset -q` at 10127) still use unresolved `git`, along with roughly 290+ other bare `git` invocations across `autonomy/run.sh`. (a) **Understated, per the first round's reviewers**: framed as "low-value to fix since a fake git already defeats the commit gate directly" -- true, but that argument only excuses NOT fixing the commit-time calls; the reader's own git feed still means BACKLOG 129's git-side hardening protects the snapshot's stored CONTENT, not what the commit outcome actually is, until this lands -- say that plainly rather than "closed" or "already covered elsewhere." A fake `git` shadowing the real one already defeats the commit gate directly (it can no-op `git commit`, or lie about what `git reset` did) independent of anything the snapshot says, so this is a materially larger fix than BACKLOG 129's writer/reader scope and was deliberately left out of it. (b) `_loki_snapshot_digest`'s python3 fallback (used only when neither sha256sum nor shasum resolves anywhere) is not yet routed through `_loki_snapshot_py_tool`/`-S`; a top-up reviewer independently reproduced that Homebrew python3 `-I` alone (without `-S`) still fires a `.pth` planted in its own site-packages, confirming this gap is real, not theoretical. (c) **Understated, per the first round's reproduction attempt, then widened by the top-up round**: `.git/config`'s agent-writable `core.fsmonitor`/`core.untrackedCache` settings don't just "shape" what a correctly-resolved `git status` reports -- `core.fsmonitor` makes git run a command the agent CHOSE on every status call and trust what it reports, which could be a full bypass of the git-side hardening entirely (an attempted untracked-cache/directory-mtime PoC did not succeed, so the full bypass is not yet proven either way -- treat as open, not dismissed). A top-up reviewer separately confirmed `core.worktree` is not yet named here and is a related agent-writable vector (it can redirect `rev-parse --show-toplevel` and `status` to point at a different tree entirely) -- add it to this enumeration; the same reviewer tried setting it as an attack and found the writer currently fails closed (`rev-parse --show-prefix` fails outside the worktree) rather than being fooled, so this specific vector is not yet a proven bypass, only a named one. Mitigate `core.fsmonitor`/`core.untrackedCache` with `-c core.fsmonitor=false -c core.untrackedCache=false` on the status call, or investigate and disclose definitively; mitigate or investigate `core.worktree` separately.
+
+132. **Mutant-detection test relies on bash-version-specific `cd ""` behavior, found during the BACKLOG 127/S-22 shadow-write fix's quorum top-up.** `tests/test-council-shadow-write-project-dir.sh`'s mutant check (strip only the `-n PROJECT_DIR` guard, leave the `cd "$PROJECT_DIR"` rewrite in place) stays GREEN on bash 5.3 (Homebrew) because bash 5.3's `cd ""` hard-fails with `cd: null directory` and short-circuits the `&&` chain -- but the identical mutant reproduces RED on real bash 3.2.57 (macOS system `/bin/bash`, what `#!/usr/bin/env bash` resolves to on a plain macOS machine), because bash 3.2's `cd ""` is a silent success that leaves cwd unchanged. The merged fix itself is correct on both interpreters (verified directly by two independent reviewers); only the test's mutant discriminator is interpreter-luck under bash 5. Fix: run the GREEN/mutant comparison under `/bin/bash` explicitly, not `#!/usr/bin/env bash`, so a future edit that dropped only the `-n PROJECT_DIR` guard cannot look safe locally while shipping a live hole on the macOS default interpreter.
+
 ## Later milestones
 
 M1 one command, M2 Seal and Wall, M3 assign like a teammate, M4 system map, M5 the line, M6 ship and operate, M7 one screen, M8 legacy lane, M9 enterprise readiness, M10 simplify and ship v10.0.0. Items get broken out here when their milestone comes up.