Framework scanners, routes, singleton identity, provider scope, styles, assets, workers, and generated consumers can all make a filesystem move observable.

At the filesystem level, moving a file looks mechanical: change the path and rewrite imports.

Frameworks make paths observable.

A file can be discovered by a route scanner, plugin registry, component glob, test convention, style pipeline, worker loader, or generated consumer. A store or provider may also rely on singleton identity that a careless move duplicates.

Relocation therefore needs semantic proof.

Profile the framework from configuration

Package names can suggest which framework is present. They should not manufacture scanner rules.

A relocation profile should derive roots, suffixes, route generation, plugin order, aliases, resolver behavior, style handling, asset conventions, and inert destinations from checked-in configuration and designated parsers.

Dynamic or unparseable configuration remains unknown. Missing evidence pins the move instead of falling back to filename folklore.

Build a whole-program reference census

The census needs more than import statements. Relevant references can include:

static and finite dynamic imports;
globs and file-based routes;
registries and resolvers;
bootstrap and plugin declarations;
provide/inject keys;
templates;
styles, assets, and workers;
tests and mocks;
generated consumers;
package and application entrypoints.

Every required textual rewrite should bind the consumer, exact preimage, before specifier, and after specifier.

Open dynamic domains or immutable generated consumers are reasons to pin.

Identity can be behavior

Moving a store, service, provider, plugin, or exported Symbol can create two runtime instances if old and new paths both resolve or if scanner rules activate both copies.

A safe move may need to prove:

one implementation remains;
aliases and environments resolve canonically;
evaluation count remains one;
stable store or symbol identity survives;
provider scope is unchanged;
no duplicate scanner or query path exists.

A re-export façade can fail this contract while making imports look compatible.

Styles and assets are part of the module

Scoped style tokens, CSS Module mappings, selector consumers, composes, asset URLs, worker URLs, lazy CSS, and global cascade order can all depend on location.

Text matching is not enough for a style mutation proof. If the designated parser cannot establish the relationship, relocation should stop or require a specialist lane.

Acceptance needs independent gates

A high-confidence plan still needs execution evidence. A robust acceptance can include:

static reanalysis of exact preimage and virtual postimage;
clean client and applicable server builds with semantic manifest comparison;
browser scenarios for cold load, deep links, navigation, provider trees, styles, and affected business flow;
idempotency and atomicity checks.

Hashes, chunk names, and file counts are useful diagnostics but not semantic equality by themselves.

The checker should be separate from the plan producer and rederive the critical facts.

Apply only the accepted postimage

Final apply verifies exact source preimages, rewrites consumers before deleting old modules, uses a workspace lock, and snapshots every touched path.

If a write or postimage check fails, snapshots are restored. Unrelated accepted components can remain independent when the conflict graph proves they do not interact. A second apply should do nothing.

KodeProof treats relocation as a first-class behavior change because repository structure participates in runtime semantics. The visible move may be one file; the actual contract spans every system that discovers, initializes, styles, or identifies it.

Relocating a File Is a Semantic Change