canarylisted

<!-- fleet-imperative: v3 --> > **Invocation for `vc-canary` (launcher `canary`)** > > Same three-path _shape_ as the fleet — see > [DELEGATION_MATRIX.md](../DELEGATION_MATRIX.md): > > | Path | Literal | > | ----------------------- | ------------------------------------------ | > | 1. User-launched worker | `vibecrafted canary <agent>` | > | 2. Interactive | `/vc-canary` — execute **in this session** | > | 3. Agent-operator | `vibecrafted canary <agent>` via dispatch | > > Root defaults to **`$PWD`**. Do not invent `vibecrafted workflow` as a stand-in. <!-- /fleet-imperative --> # vc-canary — ownership catalog ## Overview Canary answers: _this repo needs a proper catalog, but first I must know **what** to catalog._ It builds a **repo-atlas** from loctree organs (not from `context --full`), spawns **one agent per scope** (variable N), adds missing docstrings only, commits once, then reports findings for discussion. ## Canonical Orientation Gate Before building the repo-atlas, consume fresh `vc-init` evidence for the repo. If absent, run `vc-init` first — canary's ownership catalog is only as sound as the orientation it starts from. Use `Loctree:loctree` (repo-view, focus, slice, impact, find, follow) to materialize the Code-Derived Application Map that seeds `scopes.json` and the per-scope briefs. Sensing planes via raw grep, docs, or "I remember this repo" instead of Loctree organs is a