A gated verb migrates a repository off its committed component set

[sameera]

As a repository owner, I want to remove the committed Nexus components deliberately, so that I am never surprised by tracked files disappearing from a branch I was working on.

Acceptance Criteria

• Given the install location is empty or unresolvable, when the migration verb runs, then it removes nothing and reports that the components must be installed first.
• Given the install location is populated, when the verb runs, then it reports what that location holds — the resolved path and whether its content is a copied release or a pointer at a checkout — before it removes anything.
• Given a repository whose .claude/ carries Nexus-namespaced files both under the managed subtrees and at its root, when the verb runs, then all of them are removed.
• Given that same repository carries files under .claude/ that are not Nexus-namespaced, when the verb runs, then they are untouched.
• Given the verb completes, when the repository's git status is read, then the removals are unstaged working-tree changes and no commit was made, and the verb printed the git commands the owner may run.
• Given the verb completes, when the repository's ignore file is read, then it carries namespaced ignore entries for commands, agents and skills under .claude/, and no blanket ignore of .claude/.

Notes

The verb's scope is deliberately wider than the deploy mirror's. The mirror matches only the first segment under a managed subtree; the verb also matches Nexus-namespaced files at the .claude/ root, because repositories carry such files there and a migration that leaves them behind has not removed Nexus.

No blanket .claude/ ignore, because that would hide an adopter's own components.

It builds no discovery of repositories on a machine, no dry-run flag, no per-file confirmation and no backup. The files are tracked, so git is the undo.

The verb ships in the same release as the install verb. Shipping it later would open a window in which a repository holds two component sets with no remedy to name.

There is no scheduled escalation from warning to refusal. Its target population is the repositories that exist now, and it cannot fire in the case it exists for — an old command body runs, invokes its old repository-relative script path, and never reaches any guard.