KodeBack Journal
Recovery notes grounded in shipped evidence.
How we reason about donor authority, source maps, vendor boundaries, protected contracts, semantic recovery, parity, and maintainable handoff.
A Match Inside a Bundle Is Not Ownership of the Bundle
Why containment evidence should not become permission to remove surrounding application code.
Why Reference Bytes Need Their Own Provenance
A dependency comparison is only as meaningful as the package artifact it compares against.
Read the Fingerprint Lanes, Not Just the Headline
Why a completed fingerprint can still contain unavailable or unresolved evidence.
A Library Revision Is Not an Exact Package Patch
How to interpret a useful version clue without turning it into an unjustified install pin.
Why the Candidate You Edit Is Not the Tree We Measure Live
How an owned scratch view makes a parity run easier to interpret.
A Proposed Parity Plan Is Not a Passing Result
Why KodeBack refuses to turn an automatically proposed comparison into qualification.
The CSS Regression a Boot Check May Not See
Why semantic DOM parity must not be sold as complete visual equivalence.
Read a Capture Before You Create a Candidate
Why dependency fingerprinting can be useful without browser execution or workspace mutation.
Controlled Boot Is Not a Deterministic Universe
What KodeBack fixes, what remains native, and why the saved profile matters.
When the Unchanged Candidate Will Not Pass
Why a blocked baseline should stop the comparison rather than start a cycle of speculative edits.
What KodeBack Init Does Not Do
Candidate publication is a useful milestone, but it is not installation, execution, or qualification.
Prepare, Edit, Check: A Smaller Recovery Feedback Loop
How KodeBack separates an unchanged baseline from later candidate edits.
Calibrating Semantic Renames Instead of Trusting Confidence
A model’s confidence is not a rename safety threshold. Reliable automation needs adjudicated examples, independent evidence, risk curves, and a protected-surface veto.
When Client-Side Recoverability Becomes an Architecture Risk
Frontend code is expected to be recoverable. Risk rises when recoverable logic includes secrets, entitlement decisions, privileged host channels, or server-authoritative rules.
Donor, Evidence, Candidate: Three Trust Surfaces in Source Recovery
A recovery workspace becomes safer when deployed bytes, derived evidence, and editable source have different owners and different authority.
Identify Vendor Code Before Rewriting the Bundle
Production JavaScript mixes application logic, third-party libraries, generated wrappers, and bundler runtime. Cleanup should begin only after those ownership boundaries are measured.
Protected Surfaces: The Names a Cleanup Must Not Improve
Routes, storage keys, event names, asset identities, host channels, and serialized fields can look like bad identifiers while acting as external contracts.
Why a Source-Recovery Pipeline Must Be Restartable
Long recovery work survives interruptions only when stages are checkpointed, evidence is freshness-bound, and restart decisions are explicit.
Runtime Smoke Is a Contract, Not a Screenshot
A candidate that starts is not necessarily a candidate that booted correctly. Runtime smoke needs declared routes, readiness, errors, resources, and ownership evidence.
Source Maps Are a Fast Track, Not a Finish Line
Source maps can restore authored files and names, but they do not by themselves recover a reproducible project or prove runtime ownership.