docs(skills): require channel-bound clients for UI automation

.agents/skills/worktree-development/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: worktree-development
-description: Safely run, test, and debug Kit from a development worktree without replacing another worktree's daemon or migrating production state. Use before launching a development Kit binary, working with a local daemon, testing persistence/migrations, or connecting clients built from different worktrees.
+description: Safely run, test, and debug Kit from a development worktree without replacing another worktree's daemon, migrating production state, or sending input to production sessions. Use before launching a development Kit binary, working with a local daemon, testing persistence/migrations, driving a client with UI automation, or connecting clients built from different worktrees.
 ---
 
 # Worktree development
@@ -17,7 +17,8 @@ Kit's default `~/.kit` contains configuration **and** mutable runtime state: `ki
 ## Choose the narrowest mode
 
 - **Build, vet, unit tests:** No live daemon is needed. Run tests with an explicit disposable `KIT_HOME`, for example `KIT_HOME="$(mktemp -d)" go test ./...`. Preserve the isolated directory when investigating failures. Tests must still set one: a channel-bound build's default home is isolated but shared across runs, which a test must not depend on.
-- **Client UI against existing sessions:** Keep the existing server and home. Connect only when the client/server protocol and behavior are known to be compatible. Do not restart the daemon to make a client work; if incompatible, use a matching client or ask which server the user wants to keep.
+- **Client UI against existing sessions:** Keep the existing server and home. Connect only when the client/server protocol and behavior are known to be compatible. Do not restart the daemon to make a client work; if incompatible, use a matching client or ask which server the user wants to keep. This mode is for looking, and for the user's own hands-on validation: the sessions shown are the user's real sessions, so an agent must not send them input (see the UI automation guardrail).
+- **UI automation (agent clicks, keystrokes, pasted text, scripted shortcuts):** Use a channel-bound client on an isolated home, for example `KIT_MACOS_CHANNEL=NAME apps/macos/script/build_and_run.sh` for Kit Dev or a `--define channel=NAME` build for the TUI. Starting the isolated home's server, if one is needed, still requires the user's go-ahead. Prefer previews, fixtures, and test harnesses when they can show the behavior without a live client.
 - **Client attached to another home's server:** `kit attach <home-path>` (or a name saved with `kit servers add`) connects to the server already running for that home and never starts, stops, or replaces it; it fails with a start hint when none is running and refuses an incompatible server. `kit servers` probes each saved server without side effects. The attaching client still reads settings and themes from its own `KIT_HOME`.
 - **Development server, migrations, persistence, or unknown compatibility:** Use a disposable or stable worktree-specific `KIT_HOME` outside `~/.kit`. It owns its own daemon, database, attachments, and logs. This mode intentionally does not share live sessions with production. Building with `--define channel=NAME` is the way to bind a worktree to its own home, and to run several evolving homes side by side. Credentials and themes persist in a channel's home across rebuilds, so isolation does not mean reauthenticating every run.
 - **Explicitly authorized production-home changes:** State which executable, daemon, and database will be affected. Preserve a recoverable backup before a migration and coordinate shutdown/snapshotting with the owning daemon; never copy a live SQLite database by copying `kit.db` alone (WAL may hold committed data).
@@ -26,6 +27,7 @@ Kit's default `~/.kit` contains configuration **and** mutable runtime state: `ki
 
 - `kit server stop`, `kit server restart`, ordinary `kit`, `kit attach local`, `kit web`, `kit -p`, and `kit server start` are not harmless ways to check compatibility. Do not run them against a shared home without confirming the intended effect. A channel-bound build cannot reach the shared home without an explicit `KIT_HOME`, but an explicit home is still a deliberate act: asking for `~/.kit` with a channel-bound binary gets `~/.kit`.
 - Never point two independently evolving daemon versions at the same `KIT_HOME`/database or symlink a development home to production runtime files. Do not copy or link managed auth files as a shortcut; reauthentication or explicit credential handling is preferable.
+- Never send automated input to a client connected to `~/.kit`. An unchanneled Kit Dev bundle and an unchanneled TUI show production sessions, so a stray keystroke or Return can post a message, answer a question, or run a command in the user's real work. Never send input to the installed Kit app (`com.akonwi.kit`) or any window that isn't the development client you launched; confirm the frontmost app and the window under the pointer belong to that client before every interaction, and stop if focus moves elsewhere. If input may have reached a production session, tell the user which session and what was sent.
 - Do not infer compatibility from protocol number alone: same-protocol worktrees can have unversioned behavioral differences. Do not use isolation as a reason to skip that check when a matching server safely supports the task; isolation only removes the failure mode of forgetting a variable.
 - If you encounter an unexpected daemon, protocol mismatch, schema change, or migration failure, stop. Report the worktree, binary identity, selected home, and non-secret daemon identity before proposing an action; never auto-restart or retry against `~/.kit`.