Worktree Setup

Make the repository's documented development command run from the current worktree without manual reconfiguration or mutable-state sharing with another checkout.

Procedure

1. Confirm the project root, Git common directory, current worktree path, and branch. Read repository instructions and canonical development documentation before changing setup behavior.
2. Discover the documented development command and its prerequisites from scripts, manifests, lockfiles, environment examples, container configuration, and existing automation. Reuse project-native tooling.
3. Inventory every mutable or exclusive resource used at runtime: ports, databases, schemas, containers, networks, volumes, queues, caches, buckets, emulators, sockets, PID files, uploads, build outputs, and temporary directories.
4. Derive one stable worktree identifier from the canonical worktree path. Sanitize it for resource names and add a short hash when truncation or collisions are possible.
5. Configure each resource to use that identifier or another deterministic per-worktree value. Treat browser-local state as isolated only when origins differ.
6. Install dependencies and provision services, migrations, and seed data through idempotent repository commands.
7. Run the same documented development command expected in the primary checkout. Do not require users to remember a worktree-only command.
8. Verify startup and one meaningful read/write path. When practical, run the primary checkout or a second worktree concurrently and prove that ports and mutable data do not collide.
9. Update the narrowest canonical development documentation when setup behavior or commands changed. Keep machine-specific values and secrets out of Git.

Isolation Contract