Installing

Installation gives Coldstart's machinery a home on one machine. It copies only a declared payload into a dedicated installation root—the directory that will hold the machinery—and writes a receipt for what it owns. It does not activate a project.

For the order-app maintainer, this is the first of the three setup keys. The laptop changes; the repository and personal profile do not.

Why not copy a folder by hand?

For a small private script collection, copying a folder and replacing it later may be enough. The manual approach becomes costly when the source contains development-only material, an update drops old files, or another person needs to know what can be removed safely.

Coldstart uses a payload list rather than scanning the source tree for things that look useful. The list names files and directories to include and patterns to skip. Before copying, the installer rejects missing entries, upward path traversal, protected user-owned areas and source/destination overlap. Material outside the list is not silently promoted into the install.

This boundary is useful because the receipt has a defensible meaning: it records the payload the installer actually owned. It is not a complete release package definition, and a copied development payload is not evidence that a buyer-facing distribution exists.

One destination, one precedence

The installer chooses its destination in a fixed order: an explicit root, then a configured root, then the development default. It resolves that path before comparing it with protected locations.

It refuses a machine home, the coding agent's configuration home, the source tree, nested source/destination shapes and an existing non-directory. A foreign non-empty directory is refused unless the operator deliberately uses the narrow force case.

Force does not mean “overwrite anything.” It changes only the decision to enter that foreign directory. The closed payload and receipt still limit what the installer may copy and later prune.

Two entry points, one bounded contract

The Bash entry point names macOS, Linux and Git Bash as intended platforms. The PowerShell entry point mirrors its flags and root rules. A parity test compares the paths they install, their receipt bytes, the installed classifications and root-selection behavior.

That test also plants selected defects and requires the comparison to fail. This provides evidence that the represented differences are detected. It does not prove that every operating system, filesystem, shell version or later runtime action behaves alike.

The setup review exercised the pinned installer tests on one macOS environment with the declared runtimes available. The installer cases passed there. One separate project-init launcher case was skipped because that test did not recognize the available PowerShell executable name. The skip is not an installer failure, but neither is it a platform pass.

Re-running follows the receipt

After a successful copy, the installer writes the sorted ownership receipt. On a later run, a path that disappeared from the payload can be pruned only if the old receipt says the installer owned it. Directories are removed only when that operation leaves them empty.

This lets an update converge on the current payload without treating the whole installation root as disposable. Files not owned by the receipt remain outside the prune decision.

An optional settings path follows the same restraint: the pristine state can be backed up, but the installer does not add project hook registrations. It finishes by pointing toward project opt-in.

Exit meanings

• Exit 0 means the requested install or dry run completed.
• Exit 1 means the operation was refused or failed.
• Exit 2 means the invocation or installer machinery was invalid.

These meanings distinguish a bad target from a broken entry point. They do not turn a green exit into a release or support claim.

What installation leaves untouched

Installation does not seed the order app, move its plans, register project hooks, create a personal profile or decide how existing documents should be reconciled. Those are different owners.

The machine now has a possible source of machinery. The next question is which single repository, if any, should opt in.

Next

Continue with the project key: activating one project.