apache/maka

Removing a key from an exact object shape silently makes every stored record carrying that key undecodable. This is not hypothetical — it shipped in #4879 and was caught in review: dropping partialOutputRetained from TURN_STATE_MESSAGE_SHAPE made 67 of 67 turn_state rows in a real user store fail decodeMessage, which would have left those Sessions unopenable after upgrade. Fixed in 3a4371a74 by adding a retired list to defineObjectShape. The invariant, stated once: an exact shape carries two contracts whose variance is opposite — what it emits may shrink freely, what it accepts may only grow. allowed expressed both as one set, so a type-level field deletion was silently translated into a persisted-data-level deletion. Why the type system made it worse rather than better: Covers<Expected, Actual> requires the optional list to exactly cover the type's optional keys, so once the field left TurnStateMessage, keeping the key in optional was a compile error. The compiler pushed toward th

What happened The Desktop E2E test a nested scroller near the history boundary does not request an earlier range (apps/desktop/e2e/transcript-scroll.spec.ts:498) fails intermittently on CI, before it exercises anything it is about. The test resizes the viewport, waits six painted frames, and then asserts its two preconditions in one shot: await page.setViewportSize({ width: 900, height: 1500 }); await waitForPaintedFrames(page, 6); const metrics = await scrollMetrics(page); expect(metrics.scrollTop).toBeLessThanOrEqual(Math.max(640, metrics.clientHeight * 2)); expect(metrics.distance).toBeLessThanOrEqual(4); // <- fails here Observed on CI: Error: expect(received).toBeLessThanOrEqual(expected) Expected: <= 4 Received: 58 at apps/desktop/e2e/transcript-scroll.spec.ts:505:28 A viewport change makes the transcript re-pin to the tail. Six painted frames is a guess at how long that takes, not a wait for it, so under CI load the assertion samples the scroller mid-pin and reads a dist

Last piece of #4283. Everything else that issue asked for is on main; this is the one lossy edit to model-visible history that still lives outside the ledger. Problem When a provider rejects a mid-turn request as too long, the runtime drops historical image Tool Results from the request and retries once. The set it dropped is kept only in memory: packages/runtime/src/ai-sdk-compaction.ts: the ContextLength branch builds state.omittedImageToolResults on the mid-turn state, and projectHistoricalImageOmissions re-applies that map to every later request in the same turn. packages/runtime/src/provider-image-overflow-recovery.ts: collectHistoricalImageToolResults and omitHistoricalImageToolResults do the selection and the rewrite. Nothing about the omission is written to the operational ledger. On the next Turn, after a restart, or on a branch, the effective-history reducer rebuilds from the durable projections, the images come back, and the request either overflows again (one more rejecte

Problem A committed Side Conversation inherits the parent Session's transcript so the user can ask an auxiliary question against a hot context without paying for it twice. On the wire, provider prompt caching (Anthropic's request-level cache_control; OpenAI's automatic prefix caching) is what makes that inheritance nearly free: the fork's first request should match the parent's cached prefix and hit. It cannot. The side-conversation boundary instructions are joined into the single system prompt string, so the fork's system block differs from the parent's at the first divergence point — before the inherited history. Prefix matching stops at the system block and the entire inherited transcript is re-read at full input price on the fork's first request. The feature's own economic premise (cheap context reuse) is defeated by its own implementation. Mechanism Fork creation copies the parent transcript and pins the same connection + model (session-revision-coordinator.ts, #createInput), b

What happens Open Settings → a provider connection whose provider serves a model that models.dev has started listing since this Maka build was cut. The connection detail shows that model a row asking the user to declare its capabilities by hand — reasoning, vision, thinking levels — even though the Runtime Host already knows all of them and is describing the model correctly everywhere else in the app. Why installRefreshedModelMetadata() swaps a module-level variable in the process that calls it (packages/core/src/model-metadata.ts:71). The Runtime Host calls it at startup, so the Host's activeMetadata() is the refreshed catalog. The Desktop renderer is a different process — often on a different machine — and its own activeMetadata() is, and always will be, the snapshot compiled into that build. That is by design: since #4411 clients are supposed to read Host-resolved catalogEntries rather than resolve a catalog themselves. apps/desktop/src/renderer/settings/provider-connectio