What KodeBack Init Does Not Do

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.

The word “init” can invite assumptions. A user may expect dependencies to be installed, a development server to start, or a recovered application to be ready for use. KodeBack’s current initialization boundary is narrower and should be explained that way.

kodeback init validates a sealed capture, rederives the appropriate projection, applies an explicitly selected pack, and publishes an editable candidate under the workspace. It does not install dependencies, start the application, contact the origin, or execute an arbitrary recipe.

Publication has its own evidence

Writing a candidate is still a meaningful operation. The source records reads, expected starting bytes, certification, and publication receipts. The operation needs to establish that the intended candidate was published from the intended input, not merely that a directory now exists.

That is why initialization should not be described as a casual copy command. The candidate has a different owner and purpose from the sealed capture. The original acquisition evidence must remain intact while the new editable workspace becomes available for later work.

Repetition should not overwrite a new reality

An identical repeated publication can be treated idempotently. A divergent candidate is different: the command should not silently overwrite a maintainer’s edits just because the workspace was originally created by KodeBack.

Consider a synthetic project where an engineer changes one module after initialization. Re-running the same command should not turn that edit into disposable scratch work. The current source refuses a divergent candidate rather than widening its publication authority.

The next gate remains the next gate

After initialization, an engineer may still need installation, build, boot, or behavior evidence appropriate to the selected workflow. None of those outcomes can be inferred from the init result. Candidate validity and application readiness are separate claims.

This is a source-snapshot explanation, not public installation guidance or a general recovery guarantee. The available pack and supported input shape remain part of the product boundary.

For a buyer evaluating a recovery handoff, the distinction is useful. Ask what the published candidate establishes and what remains to be checked. A tool that names its stopping point makes it easier to plan the next engineering step than one that calls every created workspace a finished recovery.