Overdeck · K3s migration

Future one-command enrollment, proven without a real candidate

Phase 2 retains a deterministic future-onboarding engine. The shipped example-node identity is synthetic; the current fleet already consists of debian1, debian2 and debian3, so no live enrollment is authorized.

Phase 2 · dry-run only
17ordered enrollment steps
0live mutations permitted
3independent recovery doors

Owner experience

Install OSSupported Debian-family host
→
Authenticate TailscaleOne online, unique device identity
→
Run one command laterOnly after a real new machine exists
→
Receive proofNode, recovery, workload and Git receipt
tools/k3s/enroll-node.sh example-node --dry-run \ --fixture tools/k3s/test/fixtures/phase2-example-node.json

Transaction groups

1–3 · Identity and qualification

Tailscale pin, global collision checks, supported-host preflight.

4–7 · Recovery and host convergence

Durable ledger, three-door snapshot, serial access convergence, existing host profile.

8–10 · Temporary join

Ten-minute token metadata, pinned agent configuration, K3s join over tailscale0.

11–15 · Trust proof

Exact Node identity, quarantine, node-pinned Job, token revocation, tokenless restart proof.

16–17 · Source of truth

Paired non-dispatch registry publication and final audit receipt.

Trusted workstation

Owns the plan, ephemeral helpers, cluster observation, receipt validation and Git publication.

no reusable token in fileschecksum-verified helpersprotected labels controller-owned

Candidate cannot

Access Git credentials, cluster-admin kubeconfig, permanent K3s bootstrap authority or trusted scheduling state.

no self-trustno dispatch enablementno Phase 2 write command

Phase boundary

Phase 2: inspect, calculate, preview, validate, publish repository implementation.

Current Phase 3: verify and harden the already-enrolled debian1/debian2/debian3 cluster. Future enrollment remains separately locked.

Paired source-of-truth preview

nonecandidate execution state
falsebuild / E2E order membership
falsefallback dependency

The two previews are content-addressed and must be published as one logical transaction. Enrollment cannot silently add dispatch capacity.

Package workflow

Verify ZIPSafe paths, checksums, launcher coupling
→
Isolated worktreeCurrent origin/main remains untouched
→
Run gatesUnit, failure, deterministic integration
→
Validate receiptIndependent fail-closed authorization
→
Draft PRNever merge or push main directly

The Phase 2 receipt proves only the generic onboarding engine. It does not authorize or imply a current fourth node.