Nested workspaces

Workspaces are ordinary clones, so Workler also works inside them. Running workler add inside a managed workspace creates the new workspace under that workspace's own .worktrees/ — useful when you work on multiple features and each feature workspace needs more checkouts, e.g. one per subagent:

project/
  .worktrees/
    feature-a/
      .worktrees/
        agent-1/
        agent-2/

cd "$(workler path feature-a)"
workler add agent-1
workler add agent-2

How the nested level behaves

• Every command operates on the nearest enclosing workler project. list, path, remove, apply, and add run inside feature-a only see feature-a's own workspaces — the root's other workspaces don't leak in.
• Rules come from the checked-out .workler. A nested workspace applies the .workler file as checked out in its parent workspace — commit .workler if nested workspaces should inherit the rules.
• link targets resolve to the immediate parent. agent-1/node_modules links to feature-a/node_modules, which may itself be a link back to the root — the chain resolves transparently.
• Bare workler apply refreshes from the immediate parent. Run inside agent-1, it re-applies feature-a's rules to agent-1.
• Nesting depth is unlimited. Each clone's workler.root git config points at its immediate parent, so discovery always finds the nearest level.

Why this is useful for agents

Give each coding agent its own full checkout:

• Agents can fetch, switch branches, and commit without any shared repository state — no lock contention, no ref surprises, none of git worktree's same-branch restrictions.
• Each agent workspace starts ready to run: node_modules linked, .env copied.
• From feature-a, plain workler status shows what every agent's checkout is doing, and workler branch-sync mirrors each agent's branches back as refs/workler/agent-1/... for review — without letting an agent move any of your branches.

Cleaning up

Nested workspaces are removed like any other, from their own level:

cd "$(workler path feature-a)"
workler remove agent-1

Removing feature-a itself from the root also removes everything nested under it. remove's local-changes check only sees feature-a's own files — its nested checkouts live under a git-excluded .worktrees/, so their contents don't count. Before removing, rescue any agent work you care about (e.g. run workler branch-sync inside feature-a, then again at the root).