← Back to journal

Prepare, Edit, Check: A Smaller Recovery Feedback Loop

How KodeBack separates an unchanged baseline from later candidate edits.

Evidence basisKalu, Korpus, and frozen Ushman source/docs snapshot reviewed September 17, 2026; no new runtime qualification performed
DisclosureEngineering or methodology note based on a September 17, 2026 snapshot. Source-level behavior is not a public availability or universal compatibility claim. Any scenarios are illustrative, not customer outcomes.
Published by Kalu KodeRequest a KodeBack assessment →

Scope: Engineering or methodology note based on a September 17, 2026 snapshot. Source-level behavior is not a public availability or universal compatibility claim. Any scenarios are illustrative, not customer outcomes.

A recovered candidate becomes more useful when an engineer can make a small edit and ask a precise question about its effect. The important word is precise. A preview can show what the page looks like; a comparison needs a fixed reference and an explicit contract.

The September Kalu source includes a prepare-and-check workflow for bounded boot parity. It is a source-level capability, not a general-availability announcement or a promise of complete application equivalence.

Establish the comparison before changing the candidate

kalu parity prepare validates a sealed capture, creates an editable candidate in a new workspace, records the selected boot contract outside that candidate, and checks the unchanged baseline. That order matters. The system needs to know whether the original comparison is stable before an edit becomes the suspected cause of a difference.

Preparation is not permission to redefine expectations whenever the candidate changes. The saved plan and profile remain separate from the editable tree. That keeps an accidental candidate regression from quietly teaching the checker a new answer.

Preview and measurement have different jobs

kc serve can preview the workspace’s candidate while an engineer edits it. Refreshing a browser is useful for inspection, but it does not establish parity. kalu parity check performs a fresh comparison against the saved contract and observes the current candidate generation.

In a synthetic example, changing a declared visible landmark should create an observable disagreement. Reformatting an unrelated source region might not. The useful report explains the assertions that passed or failed rather than implying every line of the application was exercised.

Keep the first contract narrow

The initial prepare-and-check preset covers boot. It does not execute a complete action journey or establish canvas and gameplay equivalence. The controlled profile also does not guarantee determinism for every application. These limits are part of the workflow, not exceptions to its marketing promise.

A developer can use this model to separate three questions: can the unchanged candidate be compared, does the edited candidate satisfy the same boot contract, and what additional behavior still needs a different observation?

That is the feedback loop we want recovery to support. Not “edit until it looks plausible,” and not “one green check proves the app.” Prepare a bounded reference, keep the candidate editable, and remeasure the claim that the workflow actually owns.

Explore an authorized recovery assessment. Begin with a non-confidential description; do not send credentials or private source material in the first message.