The attached repository does not contain one continuous K3s implementation. It contains a legacy scheduler compatibility lane and a stricter Factory execution design. The safe process shares the cluster foundation while keeping their workload transports separate.
The old scheduler path can be canaried as a temporary adapter. The Factory path must use immutable input, Kubernetes API lifecycle, constrained publication, and no reusable host credential in the coding pod.
Repair the attached rollback defect and preserve the original unmanaged file.
Collect current cluster, node, policy, storage and recovery-door evidence.
Each later phase is one package, one command, one receipt, one review.
Incremental migration around existing buildbox/SSH behavior. Feature-gated and suitable only for bounded canaries.
Restricted, immutable, API-observed execution for coding workloads. This is the long-term architecture.
Versioned config, node enrollment, registry, namespaces, RBAC, resources and networking.
Receipts, observability, backup/restore, upgrades, outage drills and rollback.
Fleet roles plus concrete host identity, committed together after proof.
Declaration, loader, expansion, engine, hardening and CLI are present.
Submitter/watcher exist, focused tests pass, global flag remains off.
Baseline runner exists; stricter plan records unresolved ship blockers.
No one-command transactional node enrollment implementation exists.
modules/workstation/claude/lib/remote-seat-provision.mjsmodules/workstation/claude/tests/remote-seat-provision.test.mjsfactory-agent-k3s.mjs and related “preserved WIP” filesorigin/wt/factory-kubernetes-jobThe older plan relies on host-coupled SSH/hostPath mechanisms that the newer Factory plan explicitly forbids.
The Factory plan records a general host GitHub token crossing the coding-container boundary.
Cleanup, cancellation, init failure and bounded recovery-retention are not total across every exit path.
Host availability and recovery history make a dated plan insufficient proof of today’s cluster.
Fleet roles and concrete access identity live in separate files; old onboarding instructions target a removed hosts array.
A single K3s server is not ready for critical cutover without datastore + server-token backup and restore proof.
A non-expiring agent/server token must not be copied into package files, logs, shell history or candidate storage.
Trusted-builder labels must be applied after identity verification by the control plane, not by the joining kubelet.
The plan both deletes and depends on the direct SSH path. Those are separate operational decisions.
Compressing manual steps is not enough; enrollment needs resumability, proof-before-register and exact rollback.
bash tools/k3s/enroll-node.sh <new-node>A failed gate does not produce the next mutating phase. It produces a correction package or explicit rollback based on captured evidence.
bash apply-overdeck-k3s-phase0.sh /home/user/Projects/overdeckorigin/main.| Gate | Audit result |
|---|---|
| Remote seat focused suite | Pass |
| Rollback failure injection | Pass |
| Legacy K3s unit suite | Pass |
| Factory K8s focused tests | 6 passed |
| Fleet focused suites | Pass as non-root |
| Live K3s integration | Skipped: no audit kubeconfig |
| Collector offline test | Pass |
The owner-side script repeats deterministic gates in the real checkout and records environmental skips rather than manufacturing a green result.