Multi-machine development

Kin development may span a workstation and the peer repositories it coordinates with. Git commits and explicit product-owned commands are the seams; shared mutable checkouts are not.

Roles

Environment	Primary role
Workstation	Harness and TUI iteration, focused tests, documentation, and release proof
Kinra Gateway	Gateway behavior and its own deployment, backups, and rollback
Ops library	Fleet selection, private route and secret appointment, edge, and observation records

Each repository remains its own truth authority. Kin consumes stable Gateway and deployment contracts; it does not copy fleet topology or host appointments into this repository.

Bootstrap a development machine

From an existing checkout:

task setup
task check
task run

task setup creates the pinned repository environment and editable install. Use task run or uv run kin to launch that checkout. Configure connections through /login or /models; secrets remain in the local mode-0600 credential store. The terminal host and shell startup files remain operator-owned.

For a consumer install, use get.kinra.ai and the installation guide, not the development bootstrap.

Worktree isolation

Several Kin processes may share one checkout, but they also share every file. Use Git worktrees whenever independent filesystem mutation matters.

Deployment and cross-repository changes use clean, dedicated worktrees. Never reset or clean a developer’s active checkout to prepare a build. Kin’s task deploy and task get-server:deploy commands bind their exact targets from Kin’s own clean pushed checkout. Another product’s change uses that product repository’s own clean worktree and gate.

A safe cross-repository shape is:

<kin-worktree>           Kin implementation and release candidate
<kinra-site-worktree>    public manual and site verification

Do not combine another repository’s evidence into Kin’s task ship result or claim live state from a config diff.

Evidence

Retain the bounded release, result, verification, or recovery receipt the owning command produces. Add exact commands, counts, timings, or digests only when a real consumer needs them. Never commit credentials, raw logs, prompts, model output, journals, databases, workspaces, weights, or built images. See Testing for Kin’s promotion gate.