loki-mode 9.54.2 → 9.56.0

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/VERIFIED-COMPLETION-PLAN.md

@@ -87,8 +87,10 @@ Confirmed by reading source, not assumed:
   NOT `verification-results.json`.** Written by `enforce_test_coverage`
   (run.sh:6220-6396), shape:
   `{"timestamp","runner","pass":true|false,"min_coverage","summary"}`, with the
-  special **no-suite** case `{"runner":"none","pass":true,"summary":"No test
-  runner detected"}` (run.sh:6373-6379). `enforce_test_coverage` runs earlier in
+  special **no-suite** case `{"runner":"none","pass":"inconclusive","summary":"No
+  test runner detected"}` (`pass` is the string `"inconclusive"`, never the
+  boolean `true`, for this case; see D20 in `docs/v10/DECISIONS.md`).
+  `enforce_test_coverage` runs earlier in
   the same iteration (run.sh:12231, gated by `PHASE_UNIT_TESTS`, default true),
   before the council check (run.sh:12382), so this file is reasonably fresh.
   (See Section 3 deviation note for why we do NOT use verification-results.json
@@ -312,8 +314,8 @@ bypass the evidence gate entirely.
 | Greenfield first run: only untracked new files (no commit/stage yet) | nonzero (untracked) | any non-red | PASS | new files are real work; counted via `git ls-files --others --exclude-standard` |
 | Fabricated "done", nothing built (not even untracked) | empty | any | **BLOCK** | nothing shipped anywhere |
 | Real changes but tests red | nonzero | runner=X, pass=false | **BLOCK** | a runner ran and failed |
-| Docs-only change, no test suite | nonzero (docs files) | runner=none, pass=true | PASS | nonzero diff; no suite to fail |
-| Project with no test suite, real code | nonzero | runner=none, pass=true | PASS | code shipped; tests not expected |
+| Docs-only change, no test suite | nonzero (docs files) | runner=none, pass="inconclusive" | PASS | nonzero diff; no suite to fail |
+| Project with no test suite, real code | nonzero | runner=none, pass="inconclusive" | PASS | code shipped; tests not expected |
 | No git repo | inconclusive | any non-red | PASS | cannot prove fabrication |
 | Empty/missing run-start SHA (new repo, zero commits) | inconclusive | any non-red | PASS | never had a baseline |
 | test-results.json missing/unparseable | nonzero | inconclusive | PASS | mirror "no file = no gate" |
@@ -380,7 +382,7 @@ function directly. Cases:
 3. **Real diff + red tests -> blocked.** `runner=pytest,pass=false` => returns 1;
    `reason: tests_red`.
 4. **No-test project -> not falsely blocked.** Real diff,
-   `runner=none,pass=true` => returns 0.
+   `runner=none,pass="inconclusive"` => returns 0.
 5. **No git repo -> not falsely blocked.** Run in a non-git dir => returns 0.
 6. **Knob off -> behaves as before.** `LOKI_EVIDENCE_GATE=0` with an empty diff =>
    returns 0 and writes NO file.

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
 
@@ -133,6 +134,7 @@ banners you might expect. These variables control the remaining `[INFO]` and
 |---|---|---|
 | `LOKI_DURABLE_STATE` | `0` | `1` enables durable state **and** the richer process-exit contract that lets Kubernetes distinguish a deterministic failure from a crash. See [exit codes](./exit-codes.md). |
 | `LOKI_SDK_LOOP` | unset | Routes the run through the Bun/TypeScript runner instead of bash. Both implement the same exit contract. |
+| `LOKI_ALLOW_AGENT_GITHUB_TOKEN` | unset | By default `GH_TOKEN`, `GITHUB_TOKEN`, `GH_ENTERPRISE_TOKEN`, and `GITHUB_ENTERPRISE_TOKEN` are withheld from agent sessions. The two routes differ: on the bash route (`autonomy/run.sh`) the withheld tokens are re-granted only for Loki's own trusted calls, namely the `gh()` CLI wrapper, the `_loki_net` helper used by the optional local-PR path in `on_run_complete()`, the session-end `create_session_pr` call, and `autonomy/lib/proof-check.sh`'s network probe. On the Bun route (`loki-ts/src/runner/github_token.ts`'s `withholdGithubTokens()`) the tokens are dropped from the process outright, with no re-grant and no push/PR step of its own. Exactly `1` lets the agent inherit the tokens as before, on either route; that is a Rule of Two exposure, and a one-line stderr warning is printed. |
 
 `LOKI_DURABLE_STATE=1` is the one to set in a Job or task definition. Without
 it every failure collapses to exit 1 and the platform cannot tell "re-running

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,62 @@ 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.
+
+133. **`scripts/v10-pulse.sh`'s `PULSE_MOAT_RESULT` file isn't tied to the commit it was measured against.** Found by a reviewer during S-26's rework re-review: the moat-regression check now correctly requires a supplied, actually-measured `tests/moat/run.sh` capture (fixing the original structural blindness), but nothing yet verifies that capture was taken against the SAME commit the rest of the pulse's metrics are computed for. A stale capture from an earlier commit would read as clean today, reintroducing a narrower version of the original false-clean problem through the input side rather than the inference side. Not blocking S-26's merge (nothing writes this file yet -- it's a manual/future-hook input), but the hook-wiring work (docs/v10/PROGRESS.md's still-open `.claude/settings.local.json` item) must have whatever writes `PULSE_MOAT_RESULT` also record the SHA it was measured against, and `scripts/v10-pulse.sh` should reject (report UNKNOWN, not clean) a capture whose recorded SHA doesn't match `$PULSE_MAIN_REF`'s current HEAD.
+
+134. **`autonomy/completion-council.sh`'s test-result readers (`council_heuristic_review`, `council_evaluate_member`, `council_devils_advocate_review`) run a bare PATH-resolved `python3 -E -c` with no `-I`/`-S` and no fixed-path resolution -- lighter hardening than the equivalent fix already shipped for `autonomy/run.sh` (BACKLOG 129's `_loki_snapshot_py_tool`), with the identical bypass class it closed.** Found by an S-17 HIGH-tier reviewer (out of scope for that slice, which is test-coverage-only and does not touch this production code -- a bucket-(b) pre-existing gap the diff doesn't worsen, per D21, not a veto on S-17). `-E` ignores PYTHONPATH but does not stop Python from loading `.pth` files in the resolved interpreter's own site-packages directory at startup, which runs BEFORE this file's `sys.path` scrub ever executes. Reproduced live: with HOME pointed at a scratch directory holding a planted `.pth` in user site-packages that swaps `sys.modules['json']` to always report `pass:true`, `council_devils_advocate_review` flipped a genuinely failing test-results.json from `OVERRIDE_CONTINUE` to `CONFIRMED_COMPLETE`. Same fix shape as BACKLOG 129: route these 3 call sites (and any sibling `python3 -c` sites in the same file not already covered) through a resolved-interpreter helper matching `_loki_snapshot_py_tool`'s pattern (fixed root-owned paths first, `-I -S`, PATH-walk fallback with the same accepted residual gaps 129 already documents). Pair the fix with a new moat case that plants a user-site `.pth` under a scratch HOME and confirms it no longer flips the verdict.
+
+135. **`council_managed_should_stop` (autonomy/completion-council.sh:4280) is a 6th test-result reader not covered by S-17/BACKLOG 43's shadow-import moat case.** It already has the D7 hardening (sys.path filter present, confirmed by direct read), and is gated behind three default-false experimental flags (`LOKI_EXPERIMENTAL_MANAGED_COUNCIL`/`LOKI_EXPERIMENTAL_MANAGED_AGENTS`/`LOKI_MANAGED_AGENTS`), so it is not currently exploitable in production. Found by an S-17 HIGH-tier reviewer during a full-repo grep for every function reading `.loki/quality/test-results.json`. Non-blocking on S-17 itself (out of that slice's scope), but the case's name (`P2.council-readers-not-shadowed`) and its description now read as covering all readers when one remains untested. Extend the case to also drive this 6th reader under its experimental flag, mirroring the existing mutation-cycle pattern.
+
+136. **`scripts/v10-pulse.sh` trusts LOCAL git tags for its release-tag lookup, which can silently lag the real npm-published version by however long it takes this checkout to `git fetch --tags`.** Found operationally: 90 minutes after v9.55.0 shipped and was live on npm, the pulse still reported "106 commits since v9.54.2" because the local checkout had never fetched the new tag. A `git fetch origin --tags` immediately corrected it to the true "26 commits since v9.55.0". This is not a code bug in the pulse script itself (its `--match "v[0-9]*"` lookup is correct given what tags it can see) but an operational gap: nothing prompts a tag fetch before the pulse runs, so a stale local checkout silently under-reports how overdue a release actually is, or over-reports it if a newer tag genuinely doesn't exist yet. Fix direction: the pulse should cross-check its local tag-derived answer against `npm view loki-mode version` (which it already fetches for the release-count metric) and report UNKNOWN, not a confident number, when the local tag and the npm-published version disagree in a way that indicates a stale local `git fetch`.
+
+137. **S-02's fix (client-route helpers now resolve their own repo root dynamically instead of a hardcoded path) breaks `tests/moat/p7-no-fabricated-data.sh`'s own workaround for the same bug.** `P7.webapp-client-routes-exist` copies `tests/lib-extract-client-paths.mjs`/`tests/lib-match-client-routes.py` into a temp dir and sed-rewrites their (formerly hardcoded) `REPO`/root literal to retarget them at whatever tree P7 is scanning. With the hardcode removed (S-02's fix), there's nothing left for the sed to find, and the copied files now self-locate to the temp dir instead of the intended scan target. Confirmed by S-02's own builder: `REPO_ROOT` is not exported/passed to these subprocess calls anywhere in the moat harness, so this cannot be fixed from S-02's own file set. Fix: update `tests/moat/p7-no-fabricated-data.sh:477-501` to either run the two helpers in place (no copy-and-rewrite) or pass the intended root explicitly as an argument/env var, matching how the helpers now expect to receive it.
+
+138. **A TOCTOU credential-exposure gap in GF-3's GitHub-token withholding: an agent can plant a `.git/hooks/pre-push` (or set `credential.helper`/`core.fsmonitor`/`core.sshCommand` in agent-writable `.git/config`) during its session, and Loki's own wrapped push later runs that hook WITH `GH_TOKEN` exported.** Reproduced live by TWO independent GF-3 reviewers using different harnesses: reviewer 3 confirmed a child process during the agent session correctly saw no token, but a planted pre-push hook saw `GH_TOKEN=ghp_SECRET` when the wrapped push ran; reviewer 2 independently reproduced the same mechanism in the `default` scenario (`LOKI_DELEGATE_PR=1`, the product default) with 17 of 18 push-env-dumps showing no token and exactly the one dump during Loki's own trusted push showing both `GH_TOKEN`/`GITHUB_TOKEN` present, confirmed via a canary value to be Loki's push and not the provider's. Does not affect CI (both workflows set `LOKI_DELEGATE_PR=0`, and CI tokens are read-only) and is a strict improvement over the pre-GF-3 state (the agent held the token outright before), so this is bucket-(b) per D21, not a veto on GF-3. The P9 case's own header/scope language is accurate (it scopes its claim to "provider environment or argv," not to hooks/config in the working tree); only a shorthand in the case's plain-English one-line description could be read more broadly than the actual guarantee. Fix direction (confirmed independently by both reviewers): trusted git calls should ignore agent-controlled hooks/config -- e.g. `-c core.hooksPath=/dev/null -c credential.helper= -c core.sshCommand=` on Loki's own push, or push from a Loki-owned clone rather than the agent's working tree, rather than relying on `--no-verify` alone (which does not cover `credential.helper`/`core.fsmonitor`/`core.sshCommand`).
+139. **Shipped composite GitHub Actions (`.github/actions/issue-to-pr/action.yml`, root `action.yml`) still put `GH_TOKEN` in the SAME step as the agent invocation.** Found by the same GF-3 reviewer as BACKLOG 138. The new GF-3 tripwire only checks for a persisted checkout token (the `extraheader` git-config mechanism), not the token's actual permission scope, and on hosted Linux an agent can read another process's environment via `/proc/<ppid>/environ` regardless of what its OWN environment shows. Ranked by the reviewer as the top follow-up from this review round. Fix direction: fetch the issue content in an earlier, separate step and hand the agent step only a file, never a step that also holds the token.
+140. **`docs/environment-variables.md`'s description of `LOKI_ALLOW_AGENT_GITHUB_TOKEN` says tokens are "used only by Loki's own push and PR steps" -- imprecise on two counts, per a second reviewer's independent read.** True for the bash route's push/PR step, but (a) the Bun route (GF-3's `github_token.ts`) drops the token outright and has no push/PR step of its own, and (b) even on the bash route the withheld tokens are ALSO re-granted for direct `gh` CLI calls and `autonomy/lib/proof-check.sh`'s network calls, not just the push/PR step the doc names. The doc also omits the two enterprise-token variables (`GH_ENTERPRISE_TOKEN`, `GITHUB_ENTERPRISE_TOKEN`) entirely. Minor doc-precision gap, not behaviorally load-bearing; fix by naming all 4 re-grant sites and distinguishing the two routes' handling explicitly.
+141. **GF-3's P9 injection moat case (`tests/moat/p9-rule-of-two.sh`) unsets `LOKI_SDK_LOOP`/`LOKI_SDK_MODE` for its injection scenarios, so `P9 PROVEN` in the moat registry is currently bash-route-only.** The Bun route's token-withholding protection rests solely on `loki-ts/tests/runner/github_token_withheld.test.ts` (a unit test), not on the moat suite's own real-injection harness. Follow-up: extend (or add a sibling to) the existing P9 injection case to drive the Bun route through the same real-injection harness, once loki-ts/dist is confirmed rebuilt and current.
+
+142. **Found while building S-40's Bun-route P9 leg (BACKLOG 141): `loki-ts/src/providers/claude_flags.ts:186`'s `ensureClaudeHelpCache()` calls `Bun.spawn(["claude", "--help"], {stdout: "pipe", stderr: "pipe"})` with no explicit `env` option, and on Bun 1.3.13 a bare `Bun.spawn` uses Bun's own environment snapshot taken at process startup, not the live mutated `process.env` -- so `withholdGithubTokens()`'s `delete process.env["GH_TOKEN"]` (etc.) never reaches this spawn.** Reproduced two ways: a minimal `PROBE_VAR`-set-then-delete-then-bare-spawn repro, and an end-to-end run of the real `loki-ts/dist/loki.js` inside the same sandboxed harness `tests/moat/p9-rule-of-two.sh`'s `inj_run` builds -- the main `-p <prompt>` provider call (via `shell.ts run()`, which explicitly passes `env: {...process.env}`) came back clean, but the `--help` capability-detection probe leaked both canary tokens. Scope-checked every bare `Bun.spawn`/`spawnSync`/`execFileSync` in `loki-ts/src` outside `.test.` files: `council/voter_agents.ts` and `util/bash_delegate.ts` both already pass `env` explicitly and are clean; `claude_flags.ts:186` is the only bare spawn that both omits `env` and launches the literal `claude` binary. `P9.injection-cannot-reach-token` is a proven case in `tests/moat/cases.txt` (not pending), so a correct Bun-route sub-case would go RED on current main from this real gap. Fix direction: pass `env: process.env` (match whichever exact convention `shell.ts run()`/`voter_agents.ts` use) at the spawn call, rebuild `loki-ts/dist/loki.js`, verify the fix is present in the built artifact (grep a unique string, not the function name, since minification renames it), and land the fix together with the new Bun-route P9 sub-case as its regression guard. **FIXED (S-40, merged 2f506f3e).** A reviewer found 2 additional out-of-scope bare spawns (`doctor.ts`, `quality_gates.ts`) and confirmed both are unreachable from `withholdGithubTokens()`'s call path (loki doctor never calls runAutonomous()), so genuinely out of scope, not silently missed.
+
+143. **CONFIRMED STRUCTURAL (4 occurrences, all the SAME shard index): GitHub Actions "Shell tests (shard 2/4)" has now hung 4 times (23min, 22m42s, 23m50s, 20m22s) against a configured `timeout-minutes: 20`, well past GitHub's own enforcement point, while every other shard/job on the same runs finished in under a minute.** All 4 manually cancelled and a fresh push retriggered a clean run each time. This is no longer "watch for a third occurrence" -- 4 hangs on the identical shard index across one session is structural, not noise. Possible causes to investigate: a specific suite in shard 2's partition hanging on a resource wait (network, lock file, background process not exiting), a GitHub-side runner/queue issue unrelated to this repo's code, or `timeout-minutes` not being honored correctly for this job's shape (e.g. a step-level timeout vs job-level, or a step that traps/ignores the timeout signal). Fix direction: add a per-suite or per-step timeout inside the shard runner itself (not just the job-level `timeout-minutes`) so a single hanging suite can't consume the whole shard's budget silently, and instrument which specific suite was running when the hang occurred (a log timestamp before/after each suite in the shard).
+
+144. **P7's fabricated-return-from-helper scanner arm (S-29 BACKLOG 125 B-7's fix, merged/in-review) only recognizes function declarations, arrow functions, function expressions, and typed variants -- not class methods.** Found by S-31's builder during their own honest ceiling-disclosure while building the fix: a neutrally-named class method (`_getRows() { return [{...fabricated...}]; } ... this._rows = this._getRows();`) is caught by no rule, including the pre-existing rule 5 (`this.x =` direct-literal arm), because the fabrication is one level removed through the method call. Flagged as the DOMINANT uncovered shape in `dashboard-ui`'s `LokiElement`-based components, which use this exact class-method pattern extensively. No known live instance confirmed yet (a full-repo scan diff was empty both before and after S-31's fix), so this is a real, structurally-plausible gap, not yet a proven live bypass. Fix direction: extend the helper-return-tracking arm to also recognize a class method declaration (`methodName(...) { ... return [literal]; ... }`) as a trackable helper head, with the same sink-resolution logic already built for standalone functions.
+
+145. **P7's `Array.from` generator scanner arm (S-32 BACKLOG 125 B-8's fix, merged) loses an outer scope's loop variable when Array.from generators are nested.** Found by S-32's reviewer 2: `Array.from({length}, (_, r) => Array.from({length}, (_, c) => ({...fabricated...})))` -- the inner generator's parameter substitution only zeroes its own immediate arrow's params, not the outer enclosing generator's index variable it references by closure (e.g. `r`). That leftover free identifier makes `is_literal` reject the whole row as non-literal, so a real fabricated field sitting next to it goes undetected. A different mechanism from BACKLOG 144's class-method gap and from a separately-found destructured-params gap (both already disclosed as this arm's ceiling) -- this one is specifically about nested-scope variable leakage through the substitution step. No known live instance confirmed. Fix direction: when substituting arrow params with 0 for the fabrication check, also substitute any enclosing (outer) generator's own parameters if the inner callback is itself inside another Array.from generator's callback body.
+
+146. **P7's entire fabricated-data scanner (`FLOWS_TO_STATE_TMPL`/`SETTER` regex, used by every detection arm) only recognizes a literal setter name (`\bset[A-Z]\w*\(`) or `useState(` as a data sink -- a computed/dynamic sink call bypasses every arm, not just one.** Found and re-verified by S-31's rework builder while fixing the useMemo bypass: `window[sinkName](rows)` or `this[dynamicKey](rows)` (rows being fabricated) reproduces identically with S-31 fully reverted, confirming this is scanner-wide and pre-existing, not introduced by any of the P7 sibling slices (S-27 through S-32) built this session. No known live instance confirmed in web-app/dashboard-ui today (computed sink names are an unusual/obfuscated pattern, not mainstream React idiom). Fix direction: broaden the sink-matching regex to also resolve a bracket-indexed or computed member-expression call when the property/key resolves to a name already known to be a setter-like binding (harder than the literal-name case; likely needs its own dedicated slice rather than a quick regex tweak, given the scope of every arm that would need updating).
+
+147. **P7's `DECL_USEMEMO` arm (S-31 BACKLOG 125 B-7's rework, in review) only detects a `useMemo` factory that returns a literal directly (`useMemo(() => [...], deps)`), not one that calls ANOTHER already-registered fabricator (`useMemo(() => helperCall(), deps)`, where `helperCall` is itself a HELPER_HEAD-registered function that returns a fabricated literal).** Found during S-31's own second-round review: the rework's comment initially claimed this composed form was "covered by DECL_USEMEMO," which is inaccurate -- DECL_USEMEMO only inspects the factory body for a direct literal return, never a call expression, so this shape is invisible to both DECL_USEMEMO (no direct literal) and HELPER_HEAD's own call-site machinery (the useMemo-bound name is a value, never itself called as `name(args)`). No known live instance confirmed. Fix direction: `HELPER_LOCAL_DECL_TMPL` already matches `{name}\s*\(` with `fabricators` populated -- adding an optional `(?:React\.)?useMemo\(\s*\(\)\s*=>\s*` prefix ahead of the fabricator-call pattern is a plausible one-line close for the concise-arrow form, offered as a candidate by a reviewer, not a requirement.
+
+148. **`tests/moat/run.sh`'s baseline-detection (`read_baselines()`, and now `unreached_release()` too since S-20 mirrors it) has a real blind spot on symlinked baseline files: `git grep -l`/`-L` both return rc=1 ("no match") on a mode-120000 blob even when it has real content.** Found by S-20's reviewer 2 while stress-testing the rework: a symlinked `tests/moat/pending.txt` at a normal, reachable release tag is invisible to the existing (pre-S-20) `read_baselines()` too, not something S-20 introduced -- confirmed via direct reproduction. This falsifies the code's own comment claiming the `-l`/`-L` union covers "exactly every tag whose tree has the file at all" (true only for regular-file blobs). No known live instance in this repo's actual tag history. Fix direction: add a third check for a symlinked baseline file (`git ls-tree` mode 120000) at the tags already being walked, treating it the same as a real baseline (fail closed, don't silently miss it) rather than leaving the gap unaddressed.
+
+149. **REAL, LIVE, CONFIRMED-EXPLOITED GAP (escalated from BACKLOG 44's test-coverage framing): Rule-of-Two's GH-token withhold (`_loki_withhold_github_tokens`/Bun's `withholdGithubTokens()`) strips only 4 env vars, never the GitHub CLI's own `hosts.yml` credential store, which the provider's genuinely-live `$HOME` still exposes.** Found by S-18's builder, reproduced empirically on BOTH routes (bash and the real shipped `loki-ts/dist/loki.js`, no mocks): a planted `~/.config/gh/hosts.yml` canary was read and exfiltrated by the real `gh` CLI in the DEFAULT scenario, while the existing GH_TOKEN/GITHUB_TOKEN env-var canary checks stayed correctly green in the same run -- proving the env-var withhold works exactly as intended and this is a wholly separate, currently-uncovered vector, not a weaker instance of the same one. Root cause: the provider's real `$HOME` is intentionally kept live (documented at `autonomy/run.sh:1310`) so Claude's own OAuth continues to work between iterations; nothing scopes that HOME exposure away from the GitHub CLI's own credential resolution (`$GH_CONFIG_DIR`/`$XDG_CONFIG_HOME`/`~/.config/gh/hosts.yml`, keyring or plaintext depending on `gh auth login --insecure-storage` and platform keyring availability). Severity is highest on machines using `--insecure-storage`, headless/containerized Linux without a keyring backend, or any dev machine where `gh auth login` was run interactively -- CI runners that only ever export `GH_TOKEN`/`GITHUB_TOKEN` (never `gh auth login`) are unaffected, since there is no `hosts.yml` to read there. Fix direction (builder's own recommendation, least invasive): scope `$GH_CONFIG_DIR` to an empty, per-run directory before the provider session starts, on both routes, so `gh`'s own credential resolution finds nothing -- this does NOT touch `$HOME` itself, so Claude's own OAuth continues to work untouched. Must not be a blanket HOME sandbox. Extend `tests/moat/p9-rule-of-two.sh`'s existing `P9.injection-cannot-reach-token` case (same case ID, additive) with the hosts.yml-canary probe the builder already built and validated, once the fix lands -- landing the test before the fix would correctly flip the case red on a known, already-tracked gap. **PARTIALLY FIXED (S-18 first attempt, REJECTED by review 2026-09-27): GH_CONFIG_DIR scoping alone is confirmed insufficient -- macOS Keychain-backed gh auth and git's default `credential.helper = !gh auth git-credential` both survive it. Rework in flight, see D23.**
+
+150. **BACKLOG 143's fix (S-44) revealed the true root cause of every "shard 2/4 hangs" incident this session (10+ occurrences): it was never a hang.** `tests/test-ci-json-argmax.sh` legitimately takes 5-22 minutes (builds a real ~29K-116K-line finding diff to exercise `loki ci --format json` against Linux's ARG_MAX), and the workflow's own `cancel-in-progress` concurrency group killed shard 2 mid-run every time a new push landed before that suite finished -- the exact push-storm-cancels-CI pattern this session already knew about at the commit level (see PROGRESS.md's turn-12-era incident), just never connected to the shard-level symptom until S-44's builder traced it via `gh run view --log` on the actual cancelled runs. S-44's fix (per-suite timeout + logging) correctly makes a TRUE hang fail loudly and name itself, but does NOT stop `cancel-in-progress` from killing shard 2 on a fast push cadence -- that requires shard 2 finishing inside the push interval, and argmax alone can consume most of a 20-25 minute window. Fix direction: shrink the argmax fixture's finding-diff size (does it need to be 29K-116K lines to genuinely exercise ARG_MAX, or would a smaller value that still crosses the real OS limit suffice), or move `test-ci-json-argmax.sh` out of the sharded, cancel-in-progress-affected job entirely into its own non-cancelled workflow/job.
+
 ## 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.