feat(config)!: split the Pi and oh-my-pi plugin installers

[worktrunk-bot]

wt config plugins pi installed an oh-my-pi hook. It wrote a HookAPI module to ~/.omp/agent/hooks/pre/worktrunk.ts and read $PI_CONFIG_DIR / $OMP_PROFILE / $PI_PROFILE — all oh-my-pi's. Pi (earendil-works/pi) loads ExtensionAPI extensions from ~/.pi/agent/extensions/, so a Pi user who ran that command got a file Pi never reads, and wt config show printed a PI section off which omp.

This splits them into two commands, because they are two agents:

	wt config plugins omp	wt config plugins pi
Writes	~/.omp/agent/hooks/pre/worktrunk.ts	~/.pi/agent/extensions/worktrunk.ts
Source	dev/omp-hook.ts (HookAPI)	dev/pi-extension.ts (ExtensionAPI)
Config roots	$PI_CONFIG_DIR, $OMP_PROFILE/$PI_PROFILE, $PI_CODING_AGENT_DIR	$PI_CODING_AGENT_DIR
Detected by	which omp	which pi

wt config show now renders PI and OH-MY-PI as separate sections, each gated on its own binary.

The pi rename is the breaking part

wt config plugins pi install has meant oh-my-pi since 0.77.0, and it now means Pi. Already-installed hooks keep working — the path is unchanged — so what breaks is the command name in scripts and dotfiles. Both halves of that now say so rather than failing quietly:

• pi install would write a Pi extension for someone who has only oh-my-pi, and nothing downstream would mention it: the PI section of wt config show is gated on which pi, which they don't have. It now warns before writing — ▲ oh-my-pi is on PATH and Pi is not; for the oh-my-pi hook, run wt config plugins omp install.
• pi uninstall would look at ~/.pi/agent/extensions/, print Plugin not installed, and exit 0 — a no-op that reads as a completed removal while the hook sits untouched under ~/.omp/. It now adds ↳ An oh-my-pi hook is installed; to remove it, run wt config plugins omp uninstall.

An oh-my-pi user who reruns pi install despite the warning is still routed home by wt config show: the hook source text changed in the rename, so the byte-compare misses and the OH-MY-PI section prints Plugin outdated. To update, run wt config plugins omp install.

The open decision is whether that's enough, or whether pi should warn-and-redirect for one release before it changes meaning. The flip is what's implemented here; the deprecation is a small change on top if preferred.

Provenance and verification

The first commit is @ashebanow's, from feat/pi-and-omp-plugin-targets, cherry-picked unmodified — this PR exists because #4133 asked for the implementation and the branch was already there and already verified. @ashebanow, if you'd rather carry this yourself, say so and I'll close it.

That verification is the part CI can't do: the commit message records an end-to-end run against pi 0.85.1 (extension discovered at ~/.pi/agent/extensions/, agent_start → 🤖, agent_end → 💬, session_shutdown → clear, worktree as cwd) and oh-my-pi 18.1.16 for all four config-root variables. I checked the static half against pi's extensions doc and core/exec.ts: the install path is auto-discovered, the import matches, and ExecOptions carries cwd.

The remaining four commits are mine. One moves the Pi extension's "waiting for input" marker from agent_end to agent_settled, which is what pi's own docs direct status integrations at — under agent_end an auto-retry or auto-compact flips wt list to 💬 and back to 🤖 while the agent never stopped. agent_settled has no oh-my-pi counterpart, which is why the hook keeps agent_end. The rest are the two redirects above, the FAQ's delete inventory and a stale opencode.rs docstring the split left behind, and a consolidation: wt config show had two copies of the same twenty-line "installed / outdated / not installed" section renderer and the new OH-MY-PI section would have made a third, so all three now call one function that differs only in the heading and the install command. Its config show output is byte-identical — those snapshots are untouched.

Local test run

cargo clippy --all-targets --all-features is clean; cargo test --test integration is 2178 passed / 2 failed and cargo test --lib --bins is 1543 passed / 1 failed. All three failures are sandbox limitations unrelated to this change, in copy tests that bind a unix socket (PermissionDenied on socket(AF_UNIX, …)) or assert a 0644 mode the sandbox's umask writes as 0664. Snapshots were regenerated with INSTA_UPDATE=always — cargo-insta isn't available in this sandbox.

One finding from the review is deliberately not fixed here: the default test env pins WORKTRUNK_TEST_{CLAUDE,CODEX,OPENCODE,GEMINI}_INSTALLED=0 and neither PI nor OMP, so config show snapshots fall through to the host's PATH. Pinning both in src/testing/mod.rs rewrites the recorded env: block in all 1027 snapshots that carry one, which is a separate change from this one. The two snapshots this PR's new pi install warning would have made PATH-dependent pin the CLIs themselves instead.

Closes #4133.

[worktrunk-bot]

Four fixes going onto this branch next, plus two things left open. The renderer consolidation in cc9eb96c reads clean and its config show output is byte-identical (the snapshots pass untouched); it also deleted the two lines that were codecov/patch's only misses on the previous head, so that check needs re-reading rather than the arithmetic I'd worked out.

Fixing

The Pi extension sets the "waiting for input" marker on the wrong event. Pi's extension docs say of agent_end: "Pi may still auto-retry, auto-compact and retry, or continue with queued follow-up messages. Use agent_settled for status integrations that need to know Pi will not continue running automatically." With agent_end, an auto-retry or an auto-compact-and-retry flips wt list to 💬 and then straight back to 🤖 while the agent never stopped working — the one distinction the marker exists to make. Pi's own status-integration example, examples/extensions/titlebar-spinner.ts, uses agent_start / agent_settled / session_shutdown: the same three-event shape as this extension. agent_settled has no counterpart in oh-my-pi (zero hits in can1357/oh-my-pi), which is why the hook carried agent_end over and why the divergence is Pi-only.

The FAQ's delete inventory missed omp. "What can Worktrunk delete?" → Other cleanup still reads wt config plugins opencode uninstall / wt config plugins pi uninstall. The create-side table and the "To remove:" line above it both picked up the new command; this bullet is the one CLAUDE.md → Data Safety names as the review checklist for a change to the deletion surface, so it's the one that matters.

A doc comment points at code that moved. opencode.rs's opencode_plugins_dir docstring says the empty-value handling matches "PI_CONFIG_DIR in config::pi" — config::pi no longer reads PI_CONFIG_DIR; config::omp does.

config plugins pi uninstall --help had no snapshot while all three omp pages got one. The comment above those cases in help.rs gives the reason they exist ("The uninstall pages describe when each command skips, which depends on what the harness's config still holds"), and pi uninstall is the one handler in this PR that gained conditional output. Adding the case, plus a line in its after_long_help naming the oh-my-pi redirect, so the page describes the behavior the snapshot pins.

Open

Install has no redirect, and a misfire there is invisible. uninstall got a hint; install is the command that sits in dotfiles, and it flips outright. An oh-my-pi user who reruns wt config plugins pi install now writes ~/.pi/agent/extensions/worktrunk.ts, and wt config show never mentions it — the PI section is gated on which pi, which they don't have. The description's argument that config show routes them ("OH-MY-PI … Plugin outdated") holds for the hook they still need, but the stray file under ~/.pi has no surface at all. The symmetric fix is a hint on install when omp resolves and pi doesn't, which also bears on the deprecation-release question the description leaves open — so not mine to pick.

The default test env pins WORKTRUNK_TEST_{CLAUDE,CODEX,OPENCODE,GEMINI}_INSTALLED=0 but neither PI nor OMP, so config show snapshots fall through to the host's PATH. That was a latent dependency on which omp; this PR adds which pi, and anyone who verified this branch against pi 0.85.1 has pi installed. Pinning both rewrites the recorded env: block in every affected snapshot, which is more churn than the flake warrants without your say.

[worktrunk-bot]

The re-read of codecov/patch I said the refactor called for: it fails again on 9291a0aa, for the same unreachable reason but at new lines, so the arithmetic below supersedes what the review quoted.

100 of 103 patch lines hit, 97.1%. All three misses are in src/commands/config/show.rs, and all three are the )?; closing one render_file_plugin_status(…) call — the Err edge of a function whose only fallible operations are writeln! into a String, which fmt::Write for String never fails. They arrived with cc9eb96c's consolidation, which replaced the two equivalent misses on 9fb083ef (and the two that predate the PR on main, in what was render_pi_status / render_opencode_status) with one per call site. So the count moved from 2 to 3 while the reachable surface went from three copies to one — no test can close any of them, and neither commit I pushed touches those lines.

Per CLAUDE.md → Coverage that leaves this in the "no deterministic trigger" bucket: it needs your approval before merge rather than a test.

test (linux), code-coverage, lint, fast-checks, check-docs, feature-check, and affected tests (linux) are green on that commit. test (macos) and test (windows) were still running when the poll budget ran out — unverified rather than green.

[worktrunk-bot]

Both tests that reach the new pi install redirect pass --yes, so the eprintln!() that separates the warning from the install prompt never runs under test — the spacing has no regression pin, and the line would land as a fresh codecov/patch miss on a PR that already needs a coverage decision. Pushing test_pi_install_redirect_precedes_the_prompt: a snapshot of the declined path, in the shape test_opencode_install_prompt_declined already uses, which covers the line and pins the two-message layout.

The deprecation-vs-flip decision in the description is still open.

[worktrunk-bot]

That coverage exemption is no longer needed — codecov/patch is success on a87d2734, at 99.08% (108 of 109). The three )?; misses are gone rather than waived: the section renderer now returns the String instead of writing into &mut String behind anyhow::Result, so the Err edge that fmt::Write for String can never take isn't there to miss. The one remaining miss is the blank-line branch in pi.rs, which d0b22229 covers.

test (macos) and test (windows) are the only checks still outstanding, on the current head.

[worktrunk-bot]

d0b22229 is clean — it covers the one branch the earlier heads left uncovered and pins the two-message layout. No findings on it.

One thing this PR has never had named, though, and it is the reason to hold it for a human rather than anything wrong with the code.

The uninstall surface was restructured, and .claude/skills/running-tend/references/review-pr.md → Data-Loss Surface holds a PR that does that. Before this branch, wt config plugins pi uninstall removed $PI_CONFIG_DIR|~/.omp/agent[/profiles/<name>]/hooks/pre/worktrunk.ts. After it, that command removes ~/.pi/agent/extensions/worktrunk.ts and the new wt config plugins omp uninstall owns the old path. Both reach std::fs::remove_file through uninstall_file_plugin in src/commands/config/mod.rs.

What I checked, so the hold is about the decision rather than a suspected bug:

• omp.rs's omp_agent_dir / plugin_path are a faithful move of the pre-split pi.rs logic — same PI_CODING_AGENT_DIR precedence, same OMP_PROFILE/PI_PROFILE handling, same .omp default. A named-profile user's hook is still reachable.
• uninstall_file_plugin keys its removal on target.exists(), not on a content match, so the rename of the hook source (dev/pi-plugin.ts → dev/omp-hook.ts) does not strand an already-installed old hook — omp uninstall still removes it.
• Each target is a worktrunk-authored file the paired install regenerates byte-for-byte from include_str!, which is the reference's own "everything under its target can be regenerated" exemption.

So the contents test points at exempt, but the command that deletes a user's file changed meaning in the same release that the command that writes one did, and that pairing is exactly what the hold exists to put in front of a person. Requesting @max-sixty.