Do Not Measure Recovery by Lines Rewritten

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 recovery tool can rewrite a great deal of code without making a project easier to maintain. It can also leave a difficult region untouched while substantially improving the engineer’s understanding of the rest.

That is why lines rewritten is a weak headline metric for recovery. It rewards activity without asking whether the activity established ownership, preserved behavior, or made the next change safer to reason about.

Count the decisions an engineer can now make

A useful assessment might establish that a dependency has an authenticated reference, that a source-map fragment is attributable, or that a candidate can be compared under a declared boot contract. Each result removes a specific uncertainty.

It might also establish that a mixed chunk cannot yet be safely externalized, or that a required interaction lies outside current observation coverage. Those outcomes can prevent expensive work from proceeding on a false premise. They should not be discarded because they did not generate many new files.

Separate the scorecard dimensions

We propose describing a recovery candidate through several distinct dimensions: source provenance, dependency evidence, editable ownership, observed behavior, and remaining restrictions. A project can improve on one dimension while remaining blocked on another.

For example, a cleaner directory layout does not prove that singleton identity survived a dependency replacement. A passing build does not prove that a route was exercised. A readable function name does not establish that the name is historically original. One composite score can hide those differences.

Make unresolved work visible at handoff

The handoff should explain which regions remain generated or vendor-owned, which comparisons were run, and which follow-up changes would invalidate the evidence. It should also distinguish a measured failure from a capability that was not evaluated.

This is a proposed reporting lens, not a published benchmark or a claim that every current KodeBack command emits one unified scorecard. The source architecture already separates these authorities; the communication should preserve that separation rather than collapse it into a percentage.

A recovered project is useful when an engineer can understand what they have, make a bounded change, and judge the evidence around that change. Counting rewritten lines is easy. Describing regained engineering control is harder, and much closer to the outcome we want to build.