|
1 | | -## [7.9.13] |
| 1 | +## [7.9.14] |
2 | 2 |
|
3 | | -Configuration and audit consistency. A maintenance release that makes the settings layer honest: it honours two override promises the code made but never wired, removes a stale comment that misdescribed the continuation cap, and surfaces two existing timeout settings in the UI. No behaviour changes — every default resolves to exactly the value it did before. The work came out of a plan-first audit of the v7.9.7 outpost backlog, most of which turned out to have been resolved already in v7.9.7 itself; what remained were these configuration and consistency items. |
| 3 | +Visibility and consistency. A second hygiene release that closes three small loops left open after the v7.9.13 audit. The substantive piece is documenting and exposing the causal-suspicion behaviour chain that has existed since v7.9.7 P7 but was hidden behind a misleading comment; the two smaller pieces close a clamp() gap in the v7.9.12 timeouts and explicitly allowlist the legitimate install-scripts. No behaviour changes that the user would notice in normal operation — the loop still runs the way it has since v7.9.7, just now visibly and with regression protection. |
4 | 4 |
|
5 | | -### Continuation cap comment corrected |
| 5 | +### Causal-suspicion chain made honest and visible |
6 | 6 |
|
7 | | -A v7.9.9 comment in three files claimed the continuation-attempt cap had been raised from 6 to 10, but the literal stayed 6 everywhere. The investigation found this was not a forgotten edit: v7.9.10 had addressed the cloud-truncation problem a better way. `computeEffectiveMaxContinuations` lifts no-prefill/cloud models to `CLOUD_NO_PREFILL_FLOOR` (10) at run time, while local verified-prefill models keep 6 where it suffices. So 6 is the correct local-prefill floor and the 10 already lives where it belongs, in the cloud path. The stale "6 → 10" comments in `Settings.js`, `ContinuationLoop.js`, and `ModelBridgeContinuation.js` now describe the per-capability mechanism accurately. The value is unchanged. |
| 7 | +The v7.9.7 P7 release wired a multi-module behaviour chain through three modules: `CausalAnnotation` writes a warning-lesson synchronously after each promotion, `SymbolicResolver` filters those lessons out of DIRECT recalls (steering the next LLM call away from the suspect action), and `IdleMind` cools down goal-generation on the matching tokens for 1h. The three modules share a string contract — `source: 'plan-failure-reflection'` plus `strategy.classification: 'causal-suspicion'`. |
8 | 8 |
|
9 | | -### Stream timeouts are now settings-driven |
| 9 | +The chain has worked since v7.9.7. What did not work was the comment in `CausalAnnotation.js` that called the `causal:promoted` bus event a fire-into-the-void with no consumer — historically true for the bus event, but ignoring the synchronous lesson path twelve lines below. That half-truth fooled an audit into planning a re-implementation of a function already complete. The new comment names all three modules, the shared string contract, and the synchronous-write rationale — so the next reader sees the loop, and the next refactor cannot break it through a rename without noticing. |
10 | 10 |
|
11 | | -`Constants.js` had long promised that the streaming timeouts were overridable via `settings.json` `llm.streamTimeouts.{firstChunk,chunk,total,continuationTotal}`, but no code read that setting — the override interface existed only at the options level. This release wires `settings.json` into those options through `ModelBridgeContinuation`, the same pattern already used for `llm.continuation.maxAttempts`. These timeouts affect only Ollama code-generation calls (`taskType === 'code'`), the single path that routes through `ContinuationLoop` → `StreamingCompletion`, and the comment now names that scope exactly. Four validation bounds were added for the new settings. |
| 11 | +A new `getReport()` method on `CausalAnnotation` exposes promoted actions to the dashboard. It follows the Frontier convention used by `emotionalFrontier`, `lessonFrontier`, etc.: returns `{ dashboardLine, count, topSuspect }`. The renderer adds a `🎯 Causal: ...` line right below the existing `lessonFrontier` line, with a distinct icon and label from the v7.1.6 `suspicionFrontier` (novelty-based, ⚠) — two different concepts that share name fragments but track unrelated signals. Format is compact: `fs.unlink (89%/9)` for a single action, `N suspect actions — ...` plus top 3 with `+N more` suffix when applicable. Sorted by suspicion desc, observations desc on tie. |
12 | 12 |
|
13 | | -### Timeout settings made constant-referenced |
| 13 | +A new integration test `v7914-causal-suspicion-chain.contract.test.js` exercises the chain end-to-end with `assert.strictEqual` on the contract strings — a refactor that renames `'plan-failure-reflection'` to `'planFailureReflection'` for JS-naming-consistency would now break the test, instead of silently breaking the loop. |
14 | 14 |
|
15 | | -To keep the settings tree from drifting away from its source of truth, the `streamTimeouts` defaults reference the `TIMEOUTS` constants directly rather than hardcoding the numbers. The two model-response timeouts introduced in v7.9.12 (`localTimeoutMs`, `cloudTimeoutMs`) were hardcoded duplicates of their constants; they are now constant-referenced too. A guard test asserts all six timeout defaults equal their constants, so a future edit that replaces a reference with a literal is caught. |
| 15 | +### Local and cloud response-timeout clamps |
16 | 16 |
|
17 | | -### Model timeouts surfaced in the UI |
| 17 | +The v7.9.12 timeouts `localTimeoutMs` and `cloudTimeoutMs` had `FIELD_REGISTRY` min/max in the UI write path but no `clamp()` in `Settings.js`. A direct edit to `settings.json` could put values out of range, bypassing the validation entirely. Two `clamp()` calls in `_sanityClampOnLoad` close that gap: local 30s–15min, cloud 60s–15min. Ranges match the registry exactly; a guard test asserts the equality so the two cannot silently diverge, the same anti-drift pattern v7.9.13 introduced for the streamTimeouts. |
18 | 18 |
|
19 | | -`set-local-timeout` and `set-cloud-timeout` have been in the field registry with validation since v7.9.12 but had no input in the settings UI. Both now appear in the Limits tab under a "Model timeouts" section, with their min/max/placeholder matching the registry exactly so display and validation cannot diverge, and i18n in English, German, French, and Spanish. The expert-level `streamTimeouts` stay JSON-only to keep the tab uncluttered. |
| 19 | +### Install-script allowlist |
| 20 | + |
| 21 | +`package.json` now declares `trustedDependencies: ["esbuild", "puppeteer", "electron-winstaller"]` — the three packages npm warns about at install time, each with a load-bearing install script (esbuild platform binary, Chrome-for-Testing download, 7z arch select). The field explicitly allowlists them as a documentary record of the legitimate scripts running during install. Whether npm's current allow-scripts warning suppresses with the field present varies by npm version; the entry stands on its supply-chain auditability value regardless. |
| 22 | + |
| 23 | +### Lessons from the bestandsaufnahme cycle |
| 24 | + |
| 25 | +Of the seven v7.9.7 outpost-trace points (P5, P6, P7, P8, P9, P10, P15), the v7.9.13 audit found that four (P5, P8, P9, P15) had been resolved in v7.9.7 itself, P6 was a different problem than the memory note suggested, and the v7.9.14 audit found P7 was also already resolved as a behaviour loop — only visibility and regression protection remained. P10 was never a code task. The hit rate for "memory note open ≠ code open" is high enough that the remaining nominally-open points (P5, P8, P9 re-validation; P10 was non-code) should get a quick code-check before the next release line begins, rather than being treated as still-open backlog. |
20 | 26 |
|
21 | 27 | ### Notes |
22 | 28 |
|
23 | | -- Test files: 513 → 516 (three v7.9.13 contract suites) |
| 29 | +- Test files: 516 → 520 (four v7.9.14 contract suites: comment+dashboard, chain integration, clamp, trustedDependencies) |
24 | 30 | - Documentation updates: `docs/CAPABILITIES.md`, `docs/ARCHITECTURE-DEEP-DIVE.md` (test-file count) |
25 | 31 |
|
26 | 32 | --- |
|
0 commit comments