add-repo

add-repo

Every command below is ${CLAUDE_PLUGIN_ROOT}/bin/harness <verb> … — run it yourself via Bash. Never ask the user to type a harness command; the user only answers the questions below.

1 · Ask

• Repo name (must be new — case-insensitively distinct from every already-registered name) and its local path.

2 · Discover, then confirm

${CLAUDE_PLUGIN_ROOT}/bin/harness discover --repo <path> — same discovery /init-workspace uses. It first ensures the repo is clean and on its default branch: a dirty repo, or one mid-rebase/merge, refuses with a clear error — surface that to the user verbatim, never auto-stash/discard. If the guessed default branch doesn't resolve (no origin/HEAD), ask the user to name it explicitly, then pass --branch <name> yourself; a repo with no origin and a stray local branch that happens to be named main can't be told apart from a genuine one, so confirm rather than assume. Known risk: running discover against a path that's actually already registered, with a /dev-workflow run in progress against it, can switch that run's feature-branch checkout back to default — if there's any chance the path is already registered, check first rather than running discover on it. The same hazard reaches a path that is merely inside a checkout some other registered repo already covers (the monorepo shape below): the branch switch flips the whole shared tree, so check for an in-flight run on every logical repo sharing that checkout, not only on this exact path.

Present the proposals (language, test_cmd, default branch) as defaults-to-confirm, not facts:

• Confirm test_cmd by actually running it — don't accept the proposal unconfirmed, and never collapse this repo's own command onto another registered repo's.
• A proposal may carry no test_cmd: no single command covers that root (a .NET root with no solution file, or two side by side). Ask the user; never synthesise one. init-verify gates on invocability only, so a command that cannot even locate its project still reports pass, and the first verify-red then seals a red-proof over a build error.
• A monorepo_split proposal means this "one repo" is actually several logical repos sharing one .git at the physical root. Register each proposed root as its own logical repo — one /add-repo pass per root (this run registers one; tell the user the rest each need their own run), not one registration at the checkout. monorepo_split lists the root of every proposal, checkout-relative in the platform's own separators (backslashed on Windows), . meaning the checkout itself; the path to register is <checkout>/<root> (plain <checkout> for .). Suggest <repo>-<root> names (xtream-backend for the . root holding the solution, xtream-frontend for frontend/) and let the user overrule the names, not the shape. init-verify passes any path inside a git work tree, root or subtree, and says <path> (subtree of <checkout>) when they differ — confirmation, not a warning. Confirm each root's test_cmd from that subtree (cd <checkout>/frontend first): proposed commands are subtree-relative and the harness runs them with the registered path as cwd. Say plainly what the user gets: per-task worktrees still isolate (built from the physical checkout, task works in <worktree>/<subtree>, staging bounded to the subtree), but outside worktrees both logical repos sit on the SAME branch — preflight cuts it in the shared checkout — and a parent root legally contains its child, so only review catches a parent task editing the child's files.