feat(core): make worktree APIs project-based - #48867

what is reload here

reload() rebuilds the strategy registry by replaying the active ctx.worktree.transform(...) callbacks against fresh defaults. That recomputes the available strategies, selected default, and configured parent directory.

It is the existing State.reload() behavior, moved with the registration state. The config adapter also calls it when its loaded config entries change, so those transforms see the new values.

The distinction is:

ctx.worktree.reload()               // replay registration/config transforms
ctx.worktree.refresh({ projectID }) // discover worktrees and update saved inventory

reload() does not rerun plugin setup or discover worktrees. It remains a plugin-only method; it is not an additional HTTP/SDK worktree endpoint.

Implementation: State.reload and the config adapter.

why is this deleted, where did this move to

This file only scheduled a background refresh() whenever a location booted. The discovery/reconciliation implementation itself is still in Worktree.refresh.

I removed the location-boot trigger and replaced it with explicit project-based calls at the UI demand points:

• App inventory loader: first demand for a project starts discovery; worktree.updated causes a saved-inventory re-read.
• TUI worktree picker: opening it or pressing refresh runs discovery.
• The TUI Open dialog and app session-workspace menu also explicitly refresh when opened for a project.

The reason was to stop every location boot from independently discovering the same shared project. The behavior change is that simply loading a location no longer discovers external worktrees. Non-UI callers use worktree.refresh({ projectID }) explicitly; list stays a database read.

I don't like this rename, change it back to ops and have these individual ops take a projectID if needed as an arg

Agreed. The project-bound wrapper is unnecessary; this should remain a single ops object with explicit project arguments:

ops.list(projectID)
ops.find(projectID, directory)
ops.create(projectID, input, tx?)
ops.remove(projectID, directory, tx?)

I introduced inventory(projectID) just to capture the ID for the SQL predicates. Passing it directly is simpler, preserves the existing naming, and avoids recreating the helper object and functions for each binding.

Implemented in 519de27. The project-bound inventory(projectID) wrapper is gone; this is a single ops object again, with explicit arguments: ops.list(projectID), ops.find(projectID, directory), ops.create(projectID, input, tx?), and ops.remove(projectID, directory, tx?). Core typecheck and all 35 worktree tests pass.

so because this awaits plugins we can't call this in a plugin setup right

do we currently have any patterns in opencode to detect this and throw a friendly error?

Calling ctx.worktree.create(...) from plugin setup in the canonical checkout currently works because this PR has an explicit fast path:

// PluginHost passes its existing registry:
worktrees.create(input, currentWorktreeStrategies)

// load() returns before awaiting activation:
if (current?.directory === directory) return current.get()

That uses registrations made so far; later plugins have not necessarily registered yet. There is a server test for this setup call.

Your concern applies when that fast path is bypassed—for example, calling the ordinary SDK/HTTP endpoint from setup—or when setup calls form a cycle between projects. Those can still wait on their own activation.

I checked the plugin loader, readiness service, and plugin bridge, and did not find a reusable guard that turns this into a friendly error. Currently awaitActivation is just ready.await; the latch is held closed during activation. The existing approach here is avoiding the same-runtime wait, rather than detecting and rejecting it.

A friendly-error guard would need to identify a call originating from the activation it is about to await. Checking only whether plugins are loading would also reject normal API callers that should legitimately wait.

Updated in b051e91: remove now loads the canonical runtime and awaits plugin activation before resolving the worktree’s recorded strategy. It still ignores the currently selected default and returns StrategyUnavailableError when the recorded owner did not register. I also updated the HTTP description/docs and changed the server coverage to evict the canonical runtime first, then verify removal reloads the custom strategy.