loki-mode 11.17.65 → 11.17.67

package/SKILL.md

@@ -3,7 +3,7 @@ name: loki-mode
 description: An autonomous software factory that knows what it is supposed to deliver, and proves it did. Use when the user says Loki Mode or asks to build, fix or verify software autonomously.
 ---
 
-# Loki Mode v11.17.65
+# Loki Mode v11.17.67
 
 **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.
 
@@ -483,4 +483,4 @@ See `CHANGELOG.md` entries [7.5.7], [7.5.8], [7.5.13] for the per-fix list and r
 
 ---
 
-**v11.17.65 | [Autonomi](https://www.autonomi.dev/) flagship product | core skill**
+**v11.17.67 | [Autonomi](https://www.autonomi.dev/) flagship product | core skill**

package/VERSION

@@ -1 +1 @@
-11.17.65
+11.17.67

package/dashboard/__init__.py

@@ -7,6 +7,6 @@ Modules:
     control: Session control helpers (status, atomic writes, origin check)
 """
 
-__version__ = "11.17.65"
+__version__ = "11.17.67"
 
 __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.17.65. Do not edit by hand.
+Generated from `loki-ts/src/cli/registry.ts` by `scripts/generate-stale-zero.sh` for v11.17.67. 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.17.65
+**Version:** v11.17.67
 
 **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

@@ -1160,3 +1160,20 @@ L0 review rule (ENGINE-LAWS.md L0): a fix that adds an `if` or a regex about the
 - Siblings: the cline and aider stubs have no probe today (they only warn on login); the e2e claude stub answers `--help` and `auth status` before touching files.
 - Mechanism: the codex stub exits 0 for `login ...` before any edit, and providerLoginIssue runs the probe in tmpdir() so no probe ever executes in the caller checkout.
 - Fixture: loki-ts/tests/engine10/providers.test.ts snapshots untracked files under loki-ts before and after each provider run and expects none new (red on the old stub, green now).
+
+## FC-STACKED-ON-LOKI-RUN A new run started on an earlier unaccepted Loki run branch inherits that run's output (FC-15 family)
+- User saw: `loki start anthropics/claude-code#21527` in a checkout still on loki/e10-20261018T205304Z-fdfc, the output of an earlier run sealed BLOCKED (spec conflict). The start line said `PR target: origin/main, base: loki/e10-20261018T205304Z-fdfc`; the new run branched from that HEAD, so its branch, its HANDOFF Accept line and any PR carried the earlier run's rejected commit (980a166, fabricated CHANGELOG and README lines). The acceptance "CHANGELOG.md stays unmodified" was vacuously true because the fabrication sat in the base. Raw: the raw arm starts from the user's tree and has no such commit.
+- Law: L4 (the base is a contract), L2 (trust fails closed: unreviewed, rejected output is not a base), L5 (an honest line names what was skipped).
+- Cause: intake.ts took base_sha, tree and the new branch from HEAD unconditionally. FC-15 only voided an ALREADY_SATISFIED claim resting on such commits; it never stopped the run building on them.
+- Rule: when every commit in <PR target>..HEAD carries the Loki-Run trailer, the run branches from the PR target tip instead (the target tip rather than the merge-base, so a squash-merged run still finds its work on the target). The old branch is untouched. One line names the skipped branch and commit count; it is recorded as intake data stacked_loki_skip and shown through noteOf in the summary and PR body. Any commit without the trailer (the operator built on it deliberately), an empty range or an unresolved target keeps base = HEAD.
+- Siblings swept (known follow-up: group runs, where the group baseRef stays HEAD while its units skip; the predicate never fires off a loki/e10-* run branch, so not on main after a fast-forward accept, not on loki/epic-*, loki/group-*, loki/unit-* branches, and not when LOKI_PR_BASE is set by a stacked slice of `loki issues run`): unmergedEvidence/lokiOwn (still reports the mixed Loki plus operator range); the supervisor start line (baseLine now calls the same predicate, so it agrees with intake); ctx.baseSha (set before intake from HEAD; intake now updates it, which the Wall base run, verify, seal and the PR stage read); base_sha, the tree cache key and the contract snapshot (all taken after the checkout).
+- Mechanism: one predicate `stackedOnLokiRun` in loki-ts/src/util/base_guard.ts, used by intake.ts and baseLine. No new knob.
+- Fixture: loki-ts/tests/engine10/intake.test.ts describe "FC-STACKED-ON-LOKI-RUN" (all-Loki range branches from origin/main with the old branch intact and the note recorded; an operator commit in the range keeps HEAD; an unresolved target keeps HEAD) plus the FC-15 case D updated to the skip.
+
+## FC-LAZY-CONTROL-ENV Lazy-fetch control silenced by ambient git env or a racily clean index (GIT-ENV-LEAK, sibling of FC-25c-ci)
+- User-visible vs raw: Tests run 39174561642 (main 8cc81a1b8) failed shard 6/8 on tests/test-untracked-status-fsmonitor.sh with "control: plain git status did not run the lazy-fetch hook MARKER=no"; the same file passed an hour earlier and 5 of 5 locally.
+- Law broken: a test must be hermetic; a control that depends on inherited process env is not a control.
+- Cause (reproduced 2026-10-18, git 2.55.0): GIT_SSH_COMMAND (autonomy/run.sh:5868 exports GIT_SSH_COMMAND=false) or GIT_NO_LAZY_FETCH in the inherited env makes the plain `git status` skip core.sshCommand, so the hook marker is never written. `env GIT_SSH_COMMAND=false bash tests/test-untracked-status-fsmonitor.sh` and `env GIT_NO_LAZY_FETCH=1 ...` each fail the control exactly as in CI. A second cause remained in a clean env: 1 of 20 runs failed the control because `git status` re-hashes f.txt (and so lazy-fetches the attributes blob) only when the index entry is racily clean; otherwise stat matches and no fetch happens.
+- Siblings: both lazy-fetch fixtures in the file (run_lazy_case and the filter-case repo); any test asserting a repo-local ssh, fsmonitor or filter command runs.
+- Mechanism: both fixtures unset GIT_SSH, GIT_SSH_COMMAND, GIT_NO_LAZY_FETCH, GIT_CONFIG_COUNT, GIT_CONFIG_PARAMETERS, GIT_DIR, GIT_WORK_TREE and set GIT_CONFIG_NOSYSTEM=1 GIT_CONFIG_GLOBAL=/dev/null, and run_lazy_case sets f.txt mtime to 2030 (as run_eq_case already does) so status always re-hashes. The control runs first; a dead control is a FAIL that marks the real leg NOT PROVEN, never a skip or pass. The real assertion is unchanged.
+- Fixture: the same file passes 21/0 on 40 consecutive clean runs (was 19/1 once in 20) and with GIT_SSH_COMMAND=false GIT_NO_LAZY_FETCH=1 set.

package/docs/v10/PROGRESS.md

@@ -2569,3 +2569,9 @@ v11.17.21 published (Release success on 462fbc40a; npm latest 11.17.21, next 11.
 
 ## 2026-10-18T22:54Z (CoS) v11.17.65
 - FC-TEST-LEAKS-INTO-REPO: writer was providers.test.ts codex stub via preflight providerLoginIssue in process cwd. Fix 3c09faeb5: probe cwd tmpdir, stub exits 0 on login. Guard red on parent (codex case fails at providers.test.ts:184, calc.ts appears), green now: providers+preflight 58 pass 0 fail; help-drift rc 0, sigpipe rc 0. TL review APPROVE (note: relative LOKI_CODEX_CLI path resolves against tmpdir; warning only, follow-up).
+
+## 2026-10-18T22:58Z (CoS) v11.17.66
+- FC-STACKED-ON-LOKI-RUN: #21527 rerun on 11.17.64 based its run on loki/e10-20261018T205304Z-fdfc. Fix 304566e37 (base_guard.stackedOnLokiRun + intake checkout from target tip). HIGH review BLOCK on e869305 (B1/B2), APPROVE on f810c19; merged content equals approved (diff only 3c09faeb5 released files). intake.test.ts 54 pass; engine10 subset 138 pass 0 fail rc=0. help-drift was red (no backticked loki invocation in newest 5 sections); this section restores it.
+
+## 2026-10-19T00:10Z (CoS) v11.17.67
+- FC-LAZY-CONTROL-ENV: Tests 39174561642 shard 6 red on 8cc81a1b8. Causes reproduced: env GIT_SSH_COMMAND=false or GIT_NO_LAZY_FETCH=1 fails the control; clean env failed 1/20 (racy index). Fix 4735b5c14: env isolation + f.txt mtime 2030 + control-first fail. 40/40 clean runs 21/0; hostile env 21/0. TL APPROVE with mutation (drop GIT_NO_LAZY_FETCH in run.sh:10826 -> real leg FAIL 20/1, restored 21/0); select-tests 119/0.