[plur9]

Stacked on #15 (base fix/second-machine-from-snapshot).

One command makes a new machine a mirror of an existing Datacore install: the same person, the same access, so sessions there behave the same. It automates the manual second-machine steps from the 2026-10-23 install test.

On the existing machine: datacore join --prepare <new-machine>

• Adds the machine to the private roster (infrastructure.yaml: kind workstation, ssh alias, its own ledger actor) and to the owner principal's hosts / writes_as in principals.yaml. Comments are kept, and backups go to ~/.datacore/state/.
• Refuses before changing anything when:
  • the actor is already written by another machine or principal (two machines writing as one actor fork that writer's log);
  • the actor is this machine's own;
  • the name is already on the roster under another actor;
  • a registry file does not parse.
• Writes ONE bundle (mode 600, default ~/.datacore/join/<name>.join.yaml). It holds the snapshot with the private registry, plus the gitignored local files: .datacore/config/*.local.yaml, manifest.local.yaml, install.yaml roles and every CLAUDE.local.md. Every carried file and the bundle itself are scanned for secrets; a hit names the file and line, never the value, and stops before anything changes.
• Prints the scp line and the one command to run on the new machine. --dry-run checks everything and writes nothing.

On the new machine: datacore join <bundle>

1. init --from-snapshot (or restore onto an existing install), then moves any detached clone back onto its branch.
2. Local files, using the WHOLE / MERGE / ALLOWED lists of .datacore/lib/local_files_sync.py, read from the install when present (a built-in copy otherwise). It never overwrites a file the machine already has. Roster files gain only the allowed keys they lack, and install.yaml roles only for spaces the machine has. A file the repo would commit is refused.
3. The same registration on this machine, plus ~/.datacore/identity.env (DATACORE_ACTOR=<actor>). It refuses before any change when this machine already declares another actor, or when the bundle's roster or this machine's roster does not parse.
4. Credential store: the machine cannot grant itself access. It prints its ssh public key and the owner's store-side steps (copy the source instance manifest to instances/<new>.yaml, push, authorise the key), then waits; exit 2 means it cannot wait, and a rerun continues. Only after that does it clone the store and run scripts/install.sh, creds sync and creds doctor, reporting counts and failing ids only. It never commits or pushes to the store.
5. Checks: identity resolves to the new actor, every repo (root, spaces, own-repo modules) is on a branch, every space is clean, datacore doctor is green. Then a summary of what is done and what the owner still has to do.

Tests

• bun test: 227 pass, 0 fail (30 new in tests/join.test.ts, using real git repos). They include the refusal cases: actor collision, the source's own actor, a taken name, unparsable registry (prepare, dry run, and join on both the bundle's and the machine's copy), an existing identity, existing files not overwritten, the secret scan of the bundle, and the store never being written.
• tsc --noEmit: clean.
• Read-only run against a real install: the rules were read from local_files_sync.py, 23 files were collected, there were 0 secret hits, and --prepare --dry-run planned the registration and left the registry md5 unchanged with no bundle written.

Not covered

The real initDatacore inside join (the tests swap in a stand-in), ssh to a real store host, the default creds binary, the Enter-to-continue wait (needs a TTY), and Windows.

🤖 Generated with Claude Code