PROP-053: vibe clean and Maven-style verb chaining

1. The owner's mandate

03The owner's words (2026-08-24), verbatim: «Для чистки нужно сделать отдельную команду vibe clean, аналог mvn clean. Она очистит vibedeps. Способ использования командной строки стоит переделать на способ похожий на Maven. Чтобы можно было сказать "vibe clean install", и вот тогда он вначале удалит всё, и потом перегенерирует вообще весь vibedeps. Если сделать vibe clean install org.vibevm.ai-native/rust-ai-native --offline, он должен вначале очистить всю папку, потом установить всё, потом обновить только тот пакет, что попросили.» And the refinement: «Суть команды clean в том, что я хочу, чтобы она работала похоже на Maven, но чтобы учитывалась специфика нашей работы с промтами.»

2. What clean removes — and what it must never touch

04vibe clean removes exactly the derived prompt state of the workspace it runs in: (a) the dependency world — the whole vibevm/vibedeps/ root of the workspace; (b) the generated boot artifacts — vibevm/vibespecs/boot/STATIC.*, INDEX.md and INLINE.*, each carrying the generated-by-vibe marker. That is the mvn-clean analogue: what an install writes, clean deletes.

• 05Never touched — the authored surface: every authored file under vibevm/vibespecs/ (the boot snippets 00-*/90-* included — vibe never writes them), vibevm/vibefacts/, the instruction files (CLAUDE.md / AGENTS.md / GEMINI.md, their <vibevm> blocks included — an install rewrites the block in place, so clean has nothing to reclaim there), and every project file outside the derived set. This is the prompt-work specificity of the mandate: our target/ equivalent holds materialised PROMPTS, and the boundary between authored prompt and derived copy is the layout itself.
• Never touched — vibe.lock. The lock is the recorded resolution, not derived state: keeping it is what makes vibe clean install --offline reproduce the exact world from the machine cache with zero network — the mvn analogy is target/ vs the dependency resolution, and the lock sits on the resolution side.
• Never touched — the machine cache (~/.vibe/cache, PROP-010). It is our ~/.m2: clean is per-workspace, the cache is per-machine, and the offline reinstall path depends on it. Cache hygiene has its own verbs (vibe cache …).
• The run reports what left: the slot count removed and each generated artifact deleted, one line each — never a silent sweep. A clean over an already-clean tree reports «nothing to clean» and exits 0.
• Clean refuses to run outside a vibe project (no vibe.toml at or above the cwd) — a guard against sweeping an unrelated directory.

3. Verb chaining — the Maven phase line

06vibe clean install [<pkgref>…] [flags] is the phase chain: run clean first, then the install line exactly as if vibe install … had been typed. Flags after the chain (--offline, --assume-yes, …) belong to the install phase; clean itself takes none. vibe clean alone runs just the clean.

• 07With a pkgref, the chain is clean → install-everything → refresh-the-named: after the wipe, the full world reinstalls from the lock/manifest (PROP-011 §2.2 semantics — held pins, no drift), and then the named packages alone are re-resolved fresh against their declared constraints (the scoped vibe update semantics for an installed package; plain addition for a new one — both through PROP-011 ##EXPLICIT-PKGREF-FULL-SOLVE, so the world never shrinks to the named closure).
• A failing phase stops the chain: clean install with a failing install leaves the tree cleaned and the failure reported — never a half-rolled-back mix.
• The only chain this PROP ships is clean install. A general phase grammar (clean update, clean check, …) is future work and must not be improvised ad hoc — each pairing needs its own semantics ruling.