loki-mode 11.60.7 → 11.60.9

package/SKILL.md

@@ -3,7 +3,7 @@ name: loki-mode
 description: Runs an autonomous software factory that knows what it is supposed to deliver and proves it did, with a signed receipt. Use when the user says Loki Mode or asks to build, fix or verify software autonomously.
 ---
 
-# Loki Mode v11.60.7
+# Loki Mode v11.60.9
 
 **Current entry points (Loki 10 engine):** `loki "<task>"`, `loki owner/repo#N` and `loki quick "<task>"` run the Loki 10 engine and end with a signed receipt (`loki verify`). `loki backlog owner/repo --all` runs many issues in parallel. Guide: `docs/v10/GUIDE.md`. The skill instructions below, and `loki start`, describe the previous bash loop. PRD-file starts (`loki start ./prd.md`) and the opencode provider still run on it until FC38-SWEEP ports them; the legacy-engine command and the LOKI_ENGINE switch remain removed. Prefer `loki owner/repo#N` for issues.
 
@@ -476,4 +476,4 @@ Implemented, planned and deprecated items, with the version each landed in: `ski
 
 ---
 
-**v11.60.7 | [Autonomi](https://www.autonomi.dev/) flagship product | core skill**
+**v11.60.9 | [Autonomi](https://www.autonomi.dev/) flagship product | core skill**

package/VERSION

@@ -1 +1 @@
-11.60.7
+11.60.9

package/dashboard/__init__.py

@@ -7,6 +7,6 @@ Modules:
     control: Session control helpers (status, atomic writes, origin check)
 """
 
-__version__ = "11.60.7"
+__version__ = "11.60.9"
 
 __all__ = ["__version__"]

package/docs/CLI-REFERENCE.md

@@ -1,6 +1,6 @@
 # CLI reference
 
-Generated from `loki-ts/src/cli/registry.ts` by `scripts/generate-stale-zero.sh` for v11.60.7. Do not edit by hand.
+Generated from `loki-ts/src/cli/registry.ts` by `scripts/generate-stale-zero.sh` for v11.60.9. Do not edit by hand.
 Hidden and legacy-only commands are omitted; see `docs/v10/CLI-MODERN.md` for the full inventory.
 
 | Command | Description |

package/docs/INSTALLATION.md

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

package/docs/v10/FAILURE-CLASSES.md

@@ -549,6 +549,14 @@ L0 review rule (ENGINE-LAWS.md L0): a fix that adds an `if` or a regex about the
 - Mechanism: the cold one-time init is warmed in a beforeAll with its own 60s budget, and every test that performs a real rasterize passes an explicit RENDER_TIMEOUT_MS (30s); a test that does real wasm work must not rely on the 5s default.
 - Fixture: loki-ts/tests/cockpit.test.ts. Red evidence: with RENDER_TIMEOUT_MS=1 and the warm disabled both render tests fail "timed out after 1ms"; with the fix 26 pass, 0 fail.
 
+## FC-TEST-BULK-FIXTURE-DEFAULT-TIMEOUT A test that writes thousands of files and runs git reddens on a loaded host at bun's 5s default (MAIN-RED P12-12d)
+- User saw: P12-12d "untracked growth is seen even with a very large tracked change list" red on origin/main 4b0bbb0ca and bc2e0a8ff. Raw: `(fail) ... [21552.81ms]` then `this test timed out after 5000ms` at 1-min load 27; no assertion failed.
+- Law: evidence or it did not happen; never weaken the assertion. The test and session.ts are unchanged since 2026-10-16/17 (git log -S2100), so this is a cost-versus-default-budget fault in the test, not a product regression.
+- Cause (measured): the test writes 2100 files twice plus git add/commit, about 20s under load; bun's default per-test timeout is 5000ms.
+- Siblings swept: same family as FC-50; the only other bulk-file git fixture in session.test.ts is the sibling test in the same describe, which is small.
+- Mechanism: the fixture size is a named SPILL=1100 (just over the 1000-file per-list budget it must exceed) and the test carries an explicit 60_000 timeout.
+- Fixture: loki-ts/tests/engine10/session.test.ts. Red: unmodified, `bun test tests/engine10/session.test.ts -t P12-12d` fails "timed out after 5000ms"; green: 2 pass, 0 fail. Mutant (one shared file budget across both lists in diffSignature) fails the test by assertion, 1 pass 1 fail.
+
 ## FC-51 A publish-path change silently dropped a field a later gate depends on (PROMOTE-GITHEAD)
 - User saw: 11.3.1 stuck on the npm `next` tag; Promote run 37784566223 failed "FATAL: loki-mode@11.3.1 has no gitHead on npm", so the release never reached latest, Docker latest or Homebrew. Every later release would stick the same way.
 - Law: evidence or it did not happen; a change to one stage must keep every field a downstream stage reads.
@@ -1599,3 +1607,12 @@ L0 review rule (ENGINE-LAWS.md L0): a fix that adds an `if` or a regex about the
 - Siblings swept (every site that stages files): commit stage (seal.ts) and backstopCommit (commit_filter.ts, via supervisor) both go through dropSet and are fixed together; attempts.ts, modernize/scheduler.ts and verify.ts stage inside fresh worktrees that hold no user untracked files; check_result.ts and pr_lessons.ts add explicit run-owned paths only; discard.ts already protects them.
 - Mechanism: untouchedUntracked (e10ext/preexisting_dirty.ts) returns the intake-untracked files whose bytes and mode still match the snapshot; dropSet resets them from the staged set. A file the run edited stays the run's change. Crash-written files are not in the snapshot (see FC-CRASH-WORK-READ-AS-PREEXISTING).
 - Fixture: loki-ts/tests/e10ext/commit_filter_guard.test.ts (commit stage and backstop); red before the change, green after; mutants: ignore the snapshot, treat an edited file as untouched.
+
+## FC-PROVIDER-VERSION-PROBE-FULL-ENV The cline `--version` probe in providers/mcp_config.ts spawned with the full parent env, handing GH_TOKEN, GITHUB_TOKEN and SSH_AUTH_SOCK to an external binary, and main went red on full_env_spawn_guard from 35411094c (CW-10) on
+- User-visible vs raw: raw (a credential-exposure boundary and a red guard on main, not a user message).
+- Law: no child process receives the ambient GitHub credentials (FC-40); a spawn gets tokenFreeEnv or a listed reason.
+- Cause (measured): `clineVersion()` called `spawnSync("cline", ["--version"], { env: process.env })`. The version probe needs no credential, so no allowlist row is justified. tests/util/full_env_spawn_guard.test.ts reported `unlisted: loki-ts/src/providers/mcp_config.ts` alone, in `bun test tests/util` (524 tests, 1 fail) and in the full tests/providers run.
+- Order sensitivity: not reproduced. The guard is a pure static scan (walk SRC, regex per call window, compare with the allowlist file); it holds no state, mocks nothing and reads only files, so its result cannot depend on test order. "Passes in some batches" is explained by batches that never include the file (diff-selected shards run it through the walk-all-src marker only when selected). No change to the guard was needed; the behavioral test below fails independently of the guard.
+- Siblings swept: every other `process.env` spawn in providers/ is already listed with a reason (claude_flags.ts, runner/providers.ts) or token-free; mcp_config.ts is the only unlisted one (guard output).
+- Mechanism: spawn through `tokenFreeEnv(process.env)` (util/safe_git.ts), the shared scoped env builder.
+- Fixture: tests/providers/mcp_config.test.ts runs a fake `cline` that records GH_TOKEN, GITHUB_TOKEN and SSH_AUTH_SOCK with canary values set in the parent; red with `env: process.env` (restored in the mutant run), green with tokenFreeEnv. The full_env_spawn_guard goes red on the same mutant.