loki-mode 11.63.7 → 11.63.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.63.7
+# Loki Mode v11.63.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.63.7 | [Autonomi](https://www.autonomi.dev/) flagship product | core skill**
+**v11.63.9 | [Autonomi](https://www.autonomi.dev/) flagship product | core skill**

package/VERSION

@@ -1 +1 @@
-11.63.7
+11.63.9

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.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.63.7. Do not edit by hand.
+Generated from `loki-ts/src/cli/registry.ts` by `scripts/generate-stale-zero.sh` for v11.63.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.63.7
+**Version:** v11.63.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

@@ -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.
@@ -1760,3 +1792,19 @@ L0 review rule (ENGINE-LAWS.md L0): a fix that adds an `if` or a regex about the
 - Siblings swept: the other help suites (test-help-discoverability.sh, test-help-no-removed-surfaces.sh, test-help-start-flags.sh, test-help-changelog-drift.sh) were edited by 826deafd2 itself; no other file in tests/ names the Build:/Session: headers (git grep).
 - Mechanism: the help-structure block runs `loki help all`; the entry-count bound is 32 with the measured count in the comment. No assertion text changed except the bound.
 - Fixture: tests/cli/test-alias-forwarding.sh itself, 211 passed, 0 failed on both routes. Mutants: point the block back at `loki help` (all 9 red), rename a header (1 red), bound 31 (1 red), Usage text (1 red).
+
+## FC-AUTH-CAUSE-ONLY-IN-IMPL-LOG A rejected API key ends the run as "exit 1 (general error)" while the cause sits only in the implement log
+- User-visible vs raw: `ANTHROPIC_API_KEY=<bad> loki start "<brief>"` printed `Reason: exit 1 (general error)` and `next: loki doctor`. Raw: `.loki/iteration-<run>-impl.log` held `Invalid API key · Fix external API key`, and the SDK frame carried `error: "authentication_failed"` with `api_error_status: 401` (measured with `claude -p --output-format stream-json`). The run ran every later stage on a key the provider had already rejected.
+- Law: a failure the provider names is reported by that name at the moment it happens, with the fix command (ENGINE-LAWS: user-visible output states the cause, not the exit code).
+- Cause: `session.ts` classifies fatal auth only from child stderr plus `[sdk-loop error: ...]` lines. `sdk_stream_parser.ts` never wrote such a line for the structural `authentication_failed` assistant frame, so the machine's fatal:auth path (`machine.ts` sessionKind) never fired; stdout text is deliberately never classified (forgery guard in fatal_e2e.test.ts).
+- Siblings swept: every stage that opens a provider session (wall, plan, implement, already_done, deep council, fix) calls `ctx.sessions.run`, which the machine wraps once, so one classifier covers all of them (`git grep -n 'sessions.run(' loki-ts/src`). Child-stderr route already classified and is unchanged. The `billing_error` assistant frame is the same shape but maps to quota_exhausted, which waits and reruns by design (P12-09); it is not changed here and stays a follow-up.
+- Mechanism: the stream parser writes `[sdk-loop error: Failed to authenticate (authentication_failed): <provider text>]` for the structural frame only. `session.ended` records the provider text as `provider_error`; `reasonOf` appends it to "provider authentication failed", and `nextOf` names the fix: `claude login`, or the key to replace when the provider says API key.
+- Fixture: loki-ts/tests/runner/sdk_stream_parser.test.ts, loki-ts/tests/engine10/output.test.ts and loki-ts/tests/util/run_summary.test.ts cases named FC-AUTH-CAUSE-ONLY-IN-IMPL-LOG. Red with the parser line, the event field or the reason suffix removed.
+
+## FC-AGENT-TEXT-FORGES-ENGINE-MARKER Agent-controlled text could write a line the engine trusts as its own, so plain assistant prose or a provider CLI's stdout could end a run as fatal:auth
+- User-visible vs raw: user-visible. An assistant text block (or any stdout line of a provider CLI) reading `[sdk-loop error: Failed to authenticate (authentication_failed): Invalid API key, ...]` plus exit 1 gave stop `fatal:auth`, and with the cause-in-Reason slice it was printed as the Reason with key advice. Reproduced by rev-c on main.
+- Law: the engine classifies only text the provider or the engine wrote, never the agent transcript (A-113); an engine-written marker must be unforgeable from agent text.
+- Cause (measured): sdk_stream_parser capture() appended assistant and result text verbatim to the iteration log, and providers.ts writeCaptured wrote a CLI provider's stdout verbatim; session.ts matches `^\[sdk-loop error: .*\]$` and retry_class SDK_ERR matches the marker anywhere in the same text.
+- Siblings swept: every line-anchored reader of the log text (session.ts parseMarkers reads LOKI_ALREADY_DONE and LOKI_SPEC_CONFLICT, which the agent is meant to write, so they are not engine markers; budget.ts isRateLimited is an unanchored keyword heuristic on prose by design, not a trusted marker). Engine-written markers in the log: `[sdk-loop error:` (parser frame line, providers.ts catch) and `[rate_limit]` (a keyword the heuristic already matches in prose, so a forgery gains nothing). Also covered: the claude, codex, cline, aider and opencode CLI paths (all four writeCaptured stdout sites) and the `said` text inside the real frame line.
+- Mechanism: retry_class.ts neutralizeEngineMarkers rewrites `[sdk-loop error:` to `[agent-text sdk-loop error:` anywhere in agent text (capture(), the frame's `said`, and every CLI stdout before writeCaptured). sdkAuthCause also returns redactSecrets(...) because provider_error goes into events.jsonl unredacted.
+- Fixture: sdk_stream_parser.test.ts cases named FC-AGENT-TEXT-FORGES-ENGINE-MARKER (forged assistant and result text at line start and mid-line, mid-line quote read as null by sdkAuthCause, real frame still classified and redacted for an sk-ant- value) and fatal_e2e.test.ts (forged stdout plus exit 1 is not fatal). Each is red with neutralizeEngineMarkers as identity, the `^` anchor dropped, or the redaction removed.