This release adds 3 notable features for engineering teams evaluating rollout.
✓ No known CVEs patched in this version
Topics
+13 more
Summary
AI summaryStructured scope record, deterministic setup recipe, and engineering-hours estimate added to loki verify.
Full changelog
Adoption-friction + accuracy batch (ranks 6, 7, 10; RED/GREEN measured)
Driven from docs/research-2026-07/gap-analysis-backlog.json. Built in isolated
worktrees, each proven with a fixture RED/GREEN test, wired into run-all-tests.sh
AND local-ci.sh. All three are bash/python-only (no loki-ts mirror exists for
loki verify or the proof generator), so no Bun-parity surface is touched.
- rank 10 -- code-scope / locality record (accuracy, ADVISORY-first).
loki verifynow emits a structured scope record in evidence.json:
{files_changed, net_lines, verdict, advisory:true, thresholds}. Verdict is
"ok" under soft thresholds, "warn" over them, and "block" ONLY when an operator
explicitly sets a hard cap (LOKI_SCOPE_MAX_FILES/LOKI_SCOPE_MAX_NET_LINES)
and it is exceeded. Critically, the record NEVER feeds verify_compute_verdict and
never emits a gate, so by default it CANNOT change the exit code or block a build
(zero friction regression, verified). Greenfield builds are byte-identical by
construction (the helper is reachable only vialoki verify, neverloki start).
Test: tests/test-verify-scope-record.sh (4/4). - rank 7 -- deterministic setup-recipe writer (adoption-friction). After a
verified runtime boot,loki verifynow writes .loki/setup-recipe.json
{install, seed, env_keys, start, port, health_path} so later verify/e2e runs
replay the exact steps instead of re-detecting heuristically (Devin's saved-setup
pattern; the CONSUMER already existed). SECURITY: env_keys are variable NAMES
ONLY -- the writer never reads the value side of any env line, proven by a test
that plants a secret value and asserts it is absent from the recipe. A failed
boot writes no recipe. Test: tests/test-verify-setup-recipe.sh (3/3, incl. the
secret-leak assertion). - rank 6 -- work-based engineering-hours estimate in proof.json
(adoption-friction). proof.json gains a top-leveleffort_estimate
{hours, low, high, method, model, inputs_hash, calibrated, label,
estimator_version}. It is a work-based estimate (diff insertions/deletions +
files + tests + brief size), so two builds of different scope get materially
different hours (a 1-line tweak vs a full-stack feature differ by >3x -- the old
flat "iterations x 15min" gave both the same 30min). HONESTY: it FAILS OPEN to
the deterministic heuristic when no model is available (method="heuristic",
model=""), and method="llm" ONLY when an opt-inLOKI_EFFORT_LLM=1model call
actually returned a parseable number -- it never fabricates an LLM figure. Every
estimate is labeledcalibrated:false("uncalibrated") until a real
ground-truth calibration dataset exists (tracked follow-up). effort_estimate is
a TOP-LEVEL key, kept out of the facts block, so the LLM opinion can never leak
into the deterministic proof headline. inputs_hash is a sha256 over the canonical
inputs (recomputable from the written receipt) for auditability. The existing
loki metricsiterations-based report is unchanged. Test:
tests/test_effort_estimate.py (7/7); no proof-verify change needed (re-hashes the
whole dict; 50 proof pytests still pass).
Weekly OSS security release digest.
The CVE patches and breaking changes that affected production tools this week. One email, every Sunday.
No spam, unsubscribe anytime.
Share this release
About Loki Mode
Multi-agent autonomous SDLC framework. Spec to deployed app. PRD, GitHub issue, OpenAPI/JSON/YAML, or one-line brief. 5 AI providers, 11 quality gates.
Related context
Related tools
Beta — feedback welcome: [email protected]