Protected Surfaces: The Names a Cleanup Must Not Improve

Minified source invites renaming.

A local binding named a may clearly represent a route registry, a velocity vector, or a message handler. Giving it a meaningful name can make the recovered project dramatically easier to maintain.

The same short token inside a string may be load-bearing contract data.

Local meaning and external identity are different

Consider these two changes:

const a = storage.getItem("a")
const savedTheme = storage.getItem("a")

The second local name is more useful. The string still has to remain "a" if that is the key used by deployed data.

The same rule applies to many surfaces:

• URL routes and query keys;
• local and session storage keys;
• event names;
• JSON and protocol fields;
• browser-extension messages;
• Electron IPC channels;
• shader uniforms and attributes;
• CSS classes referenced across runtime boundaries;
• worker messages;
• asset paths;
• scene-node names;
• public exports and plugin registration keys.

Changing these values can break behavior without producing a syntax error.

Why global replacement is unsafe

A textual replacement cannot reliably distinguish a binding occurrence from a string, property key, comment, generated region, or unrelated identifier with the same spelling.

Even AST-aware binding renames have boundaries. An exported symbol may be consumed dynamically. A property accessed through bracket notation may belong to a serialized contract. A string table may construct several keys at runtime.

The mutation tool needs both syntactic identity and contract evidence.

A protected surface is a declared boundary

A recovery workspace can record known protected values and entrypoints before cleanup begins. The declaration may come from:

• captured network requests;
• manifests and host configuration;
• runtime observations;
• framework and adapter rules;
• source-map evidence;
• operator intent;
• tests and parity states;
• static analysis of externally reachable consumers.

The list is not proof of completeness. It is a machine-checkable floor: these known contracts must not drift without explicit authorization.

Safe rename plans bind exact source

A robust rename operation should identify the binding, declaration location, references, source fingerprint, and proposed replacement. Preview and apply should use the same plan.

Before mutation, the system can check:

• whether the plan is stale;
• whether the binding is exported or crosses a host boundary;
• whether any reference overlaps a protected literal or generated surface;
• whether the target collides or shadows another binding;
• whether syntax and type roles remain valid.

After mutation, project and runtime evidence can check what static analysis cannot establish.

Sometimes the right name is intentionally ugly

Recovered code may contain a route called /x, an event called q, or a GLTF node called Cube001. If that identity is external, preserving it is not unfinished cleanup.

Maintainability can come from naming the owner around it:

const LEGACY_SESSION_STORAGE_KEY = "a"
const PLAYER_CAMERA_NODE_NAME = "Cube001"

The code becomes legible while the contract remains exact.

Uncertainty should queue, not mutate

When a token could be either local noise or contract data, the system should ask for evidence or retain it. An abstention leaves cosmetic debt. A false rename can corrupt user state, break a route, or disconnect a host integration.

KodeBack’s semantic-recovery work therefore measures success by useful, safe readability—not by the percentage of short names eliminated. The names that survive can be the strongest sign that the cleanup understood where source stops and the outside world begins.