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.
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.