# Adopt an existing project

One can start a new system or place an existing application under the same
canonical lifecycle. Adoption is a reviewed conversion, not a permanent
bridge between two mutable control planes.

## Establish the project boundary

Run `one init` from the directory that will own the project. It creates or
adopts the bounded `one.one` entry point, explicit application sources, and
initial exact `one.lock`:

```console
cd existing-application
one init . --dry-run --offline --proposal-lock-output proposed.one.lock
one init . --offline
one check --offline
```

Review `proposed.one.lock` before the second command. The dry run is the review
boundary. It reports every acquired package,
language profile, toolchain, provider claim, source closure, trust record, and
unresolved choice before the lock is accepted. `one check` remains read-only
and never repairs or advances the lock implicitly.

## Import ecosystem inputs once

An existing `Cargo.toml`, `package.json`, `pyproject.toml`, deployment manifest,
or provider resource can be acquired as an exact adoption input. One retains
its original bytes, source, parser or adapter revision, identity candidates,
ambiguities, and loss report. You review the mapping before it establishes any
One-owned meaning.

After acceptance, portable dependencies and toolchains live in the selected
`.one` sources and exact `one.lock`. Resolver adapters may construct private,
receipted Cargo, npm, PyPI, or peer workspaces for upstream tools, but the old
manifest does not remain a second mutable project-control path.

Application source code does not need to be rewritten into `.one`. Keep Rust,
TypeScript, Python, and other bodies in their own language when that is the
selected implementation profile; the `.one` implementation item associates
the exact source artifact with the contract it claims to realize.

## Adopt running infrastructure deliberately

Discovering a similarly named database, queue, cluster, or deployment is not
adoption. A reviewed infrastructure adoption verifies:

- exact external identity and ownership posture;
- observed shape and the baseline from which drift will be measured;
- credentials or workload authority without treating them as project source;
- current data, retention, transfer, and deletion obligations;
- recovery evidence and the effect boundary; and
- the explicit policy for later drift.

Adoption records current fact; it does not itself issue mutation authority.
The first change still follows `check -> test -> invoke -> plan -> build ->
apply -> inspect` with an immutable plan and ordinary grants.

## Cut over without a hidden compatibility lane

Before calling the adoption complete, make the selected `.one` source and
`one.lock` the only portable project control plane, move machine-local bindings
to `.one/execution.toml`, leave provider configuration with its provider, and
remove obsolete generated or handwritten configuration only after the exact
new lifecycle reproduces the required behavior.

Next: [understand source and meaning](/one/model/source-and-meaning), then
[author the product](/one/authoring/product).