loki-mode 11.63.7 → 11.63.8

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.63.7
+# Loki Mode v11.63.8
 
 **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.63.7 | [Autonomi](https://www.autonomi.dev/) flagship product | core skill**
+**v11.63.8 | [Autonomi](https://www.autonomi.dev/) flagship product | core skill**

package/VERSION

@@ -1 +1 @@
-11.63.7
+11.63.8

package/dashboard/__init__.py

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

@@ -1702,6 +1702,38 @@ L0 review rule (ENGINE-LAWS.md L0): a fix that adds an `if` or a regex about the
 - Mechanism: in the P9 AST scan, a literal `await import("...safe_git...")` is accepted only as the initializer of an object destructuring whose every element is a plain identifier property (no rest, no computed key, no string key, no nested pattern) and none of whose names is an opt-in helper. Any other dynamic or require form still flags. A destructured safeGit with allowToken is still caught by the raw allowToken grep outside the two fetch callers.
 - Fixture: tests/moat/p9-rule-of-two.sh positive controls for a rest destructure, a computed-key destructure, a renamed opt-in helper and a destructured safeGit carrying allowToken (each must be flagged), and a negative control for the real `{ reviewerGitEnv }` form (must not flag). Mutant: accept any destructure shape; the rest and computed controls must go red.
 
+## FC-FULL-SUITE-IGNORES-PROJECT-INTERPRETER The deep-verify full pytest suite ran under bare `python`, not the project's own interpreter, so a repo with a working .venv and no `python` on PATH could never prove its suite
+- User-visible vs raw: user-visible. An uninterrupted run on a Python fixture with a working .venv and ruff ended PARTIAL because the full-suite check could not run (bare `python` missing or without pytest), while per-test runs under the same repo used the venv.
+- Law: every check that executes project code resolves its interpreter through one resolver (project venv first), and no stage hardcodes a bare interpreter name.
+- Cause (measured): `FULL_SUITE_CMD` in util/check_result.ts was a static table (`python -m pytest -q`); the per-test path used `resolveTool` but the full-suite path (engine10/stages/deep.ts, project_model/package_suite.ts) did not.
+- Siblings swept: deep.ts and package_suite.ts (both consumers moved), non-pytest runners (vitest, jest, bun, node, npm, go, cargo: no interpreter, stay static), per-test pytest (already resolveTool).
+- Mechanism: `fullSuiteCmd(runner, repoDir)` resolves pytest through `resolveTool(repoDir, "python", "python3", "python")`; both consumers call it.
+- Fixture: tests/engine10/deep.test.ts "pytest full suite runs under the project .venv python when no bare `python` is on PATH" (red on the static table, green after).
+
+## FC-SUITE-RUN-LINE-BREAKS-ON-SPACED-PATH The full-suite baseline run line joined an absolute project interpreter path into a bash -c string unquoted, so any repo under a path with a space never ran its base suite
+- User-visible vs raw: user-visible. For a Python repo under a spaced path (for example `~/My Projects/app`) the intake baseline got `bash: .../My: No such file or directory` (rc 127), so a failure already red on base could not be excused and the run ended FAILED or PARTIAL for a harness reason.
+- Law: a command assembled from argv for a shell is quoted word by word; a path the harness resolves is never trusted to be space-free.
+- Cause (measured): FC-FULL-SUITE-IGNORES-PROJECT-INTERPRETER made `fullSuiteCmd` return an absolute `.venv/bin/python`; `fullSuiteSpecs` (project_model/package_suite.ts) joined `[cmd, ...args]` with spaces into `SuiteSpec.run`, which `baselineSuites` runs through `bash -c`. Reproduced by rev-c: rc 127 with a space in the path, rc 0 and "1 passed" without.
+- Siblings swept: `deep.ts` runs the same argv with no shell (unaffected); `packageSuiteSpecs` uses the project model's own command string (already a shell line, unchanged); `SuiteSpec.cmd` stays the plain display join so recorded commands and the root-baseline dedup (`normCmd(run)`) are unchanged for space-free repos.
+- Mechanism: `shellQuote` moves from runner/providers.ts to util/shell.ts, with `shellWord` (quotes a word only when bash would split or expand it). `fullSuiteSpecs` builds `run` with `shellWord` per token.
+- Fixture: tests/engine10/deep.test.ts "FC-SUITE-RUN-LINE-BREAKS-ON-SPACED-PATH" (a repo under `My Projects/app` with a `.venv/bin/python` runs rc 0 via `bash -c spec.run`; a plain go line stays byte-identical). Mutant dropping the per-word quoting gives rc 127 and the test goes red.
+
+## FC-LINT-TOOL-NEVER-USED-BY-PROJECT verify demanded lint:ruff of a Python repo that neither declares ruff nor has it installed, so the check ended not_run and the run PARTIAL
+- User-visible vs raw: user-visible. The 05:44Z python fixture run (kvparse, bench workdir loki-bench-loki-jxegolv0) had no .venv, no ruff config and no ruff on PATH; verify recorded lint:ruff not_run (reason "ruff not found on PATH") and seal listed "not run: lint:ruff" as NOT PROVEN, so a correct change could not reach VERIFIED.
+- Law: a verifier demands only the checks the project itself uses; a tool the project never names and the machine does not have is not applicable, while a tool the project names and the machine lacks stays not_run.
+- Cause (measured): runLintChecks (engine10/stages/verify.ts) ran lint:ruff for every changed .py with resolveTool's last resort `ruff`, which fails to spawn when nothing resolves.
+- Siblings swept: lint:shellcheck (bash -n always runs; shellcheck is a general tool on the changed set, unchanged), lint:eslint (already gated on an ESLint config in the package), lint:tsc (already gated on tsconfig.json). ruff was the only named-tool check with no project gate.
+- Mechanism: lint:ruff runs when ruff resolves (project .venv, uv, or PATH) or the project declares it (projectDeclaresRuff: ruff.toml, .ruff.toml, or `ruff` in pyproject.toml, setup.cfg, tox.ini, .pre-commit-config.yaml, Pipfile or a requirements file). Otherwise no check is recorded.
+- Fixture: tests/engine10/verify.test.ts "FC-LINT-TOOL-NEVER-USED-BY-PROJECT" (no ruff, nothing declared: no check; declared but absent: not_run). Mutant (gate always true) turns the first test red.
+
+## FC-VISUAL-EVIDENCE-NA-READ-AS-NOT-PROVEN Seal listed "visual evidence skipped: no package.json" for a repo with no UI and no changed page file, so a CLI or library change was NOT PROVEN for evidence it never had to produce
+- User-visible vs raw: user-visible. The same python fixture run and the first-run gate `scripts/first-run-gate.sh --entry start-empty` (eng-mcpchain, #357 criterion 3) ended PARTIAL with this line among the NOT PROVEN items.
+- Law: an item is NOT PROVEN only when the run could have produced it and did not; a capture that has no subject is not applicable.
+- Cause (measured): sealEvidence (features/visual_evidence.ts) added every capture skip reason to notProven, including the two that mean there is nothing to boot ("no package.json", "no dev, preview or start script") when no changed file is a page file.
+- Siblings swept: the LOKI_VISUAL_GATE evidence_failed branch (same predicate now), "no changed page files" (existing, pinned by the no-web-pages test, left as is), a changed page file with no package.json (still NOT PROVEN and still a gate failure), and LOKI_VISUAL_EVIDENCE=1 (API transcript requested, still reported).
+- Mechanism: one predicate in sealEvidence, noUi = skip reason is one of the two no-boot reasons AND the API transcript was not requested AND no changed file isPageFile; it suppresses both the NOT PROVEN line and evidence_failed.
+- Fixture: tests/features/visual_evidence.test.ts "FC-VISUAL-EVIDENCE-NA-READ-AS-NOT-PROVEN" (changed .py: no line, no failure; changed page file with no package.json: line and failure).
+
 ## FC-RUNS-ENV-LEAKS-ACROSS-PROJECTS `loki runs` applied the caller's LOKI_DIR to every registered project, so one run list was reported once per project (repo "a" and repo "b")
 - User-visible vs raw: user-visible. `loki runs --json` returned the same run twice under two repo labels.
 - Law broken: a row's repo label names the project whose runs directory it was read from; a per-process env knob that points at one directory cannot be applied to N projects.