Preflight Discovery Is Not Refactor Proof
What a bounded read-only preparation step can establish before any candidate is created.
Scope: Research and architecture note. KodeProof development is frozen; this is not a release announcement.
A preparation command can tell an engineer a great deal about a project without proving that a proposed change is safe. That distinction is central to the KodeProof source-level preflight.
KodeProof development is currently frozen while Kalu focuses on KodeBack and KodeCapture. This article is a research and architecture note about the bounded implementation, not an active release or availability announcement.
Inventory the project without running it
The current refactor prepare path reads a bounded local TypeScript closure, relevant package and configuration material, lockfile identities, and existing scripts. It independently rereads and verifies the result. It does not execute those scripts, install dependencies, or create scratch workspaces.
That makes preparation a useful first question: what can the tool establish about this project from admitted static inputs? It is not yet a question about whether existing tests can observe the behavior a refactor must preserve.
A successful exit has a narrow meaning
The source explicitly leaves proof setup in a characterization-required state after bounded discovery completes. Existing scripts are inventory, not behavioral evidence. Finding a test command in package.json does not prove that it runs meaningful assertions or that those assertions cover the proposed change.
In a synthetic project, a script could always exit successfully. A preflight should report that the script exists without treating its name as proof that the project is protected.
Limits belong in the result
The preparation path has bounded file and byte limits and refuses unsupported dependency, configuration, and path forms. These are not arbitrary inconveniences to bypass. They define which project closure the implementation can actually inspect and verify.
A missing dependency or unsupported configuration should therefore remain a typed blocker rather than being replaced by an ambient file or a guessed resolution.
The broader lesson applies to recovery as well as refactoring. Discovery can reduce uncertainty without authorizing a mutation. A useful tool should make that progress visible while keeping the next evidence requirement intact.
When evaluating a preflight result, ask what was read, what was not read, and what behavior still needs characterization. A successful inventory is a good beginning. It becomes misleading only when the word “prepared” is allowed to mean “proved.”