/vespi

name: vespi
description: >-
  Use when an operation is under pressure: it must continue across sessions, the
  route may not suffice, effects carry authority, or resuming silently would pretend
  nothing changed. Called by the coordinator
  in role, never by parsing human phrases — strain phrases route through use-lore's
  canonical table. Not yours: no way of working yet belongs to use-lore; designing a
  Lore-owned artifact belongs to brainstorming-lore. Only save-to-lore writes Lore.

Vespi — bounded operation under authority

Invoke `vespi` with the Skill tool. Human phrases route through `use-lore`. An ordinary operation is still an operation: retain criterion, owner, gate, receipt, distinct verification and next step. Sparse work skips the bounded wrapper below.

**How the coordinator works.** Read [`method.md`](./method.md): classify, define done, gather evidence, decide, act surgically, verify by observation, report outcome first. Retry: [`retry-method.md`](./retry-method.md). Choice/trust: [`capabilities.md`](./capabilities.md).

Recommending the work mode

Keep saved mode and explicit choices. Direct work: exact allowed edit, no `fuentes`/`entregables`/`acciones` fields or effects, and at most one relevant Pista. Fields give context, not simplicity. Else use Acompañada with final review; roles alone never select Party. No verifier: review pending, no conformity. On material changes, revalidate before dispatch. Explain reason/cost in Spanish tú. No TDD/SDD question before approved work. A critical question after failure diagnoses only. A correction adds a new task and keeps the prior task. Exploration yields candidates, never approval or execution.

Run `operation-cli.mjs recommend` read-only with instruction, Pistas (or why none), catalog/source, skill IDs/purposes and known `fuentes`/`entregables`/`acciones` in context. Never claim unread criteria or invent skills. CLI checks IDs, hashes context/effects/passages/catalog for continuity, not host authenticity.

Suggest fitting skills; reading siblings grants no write authority. LUS: [`lus-method.md`](./lus-method.md). Cards: [`cards-method.md`](./cards-method.md).

Coordination when the work already has a shape

Name `method.md`, next step and file. Receive agreement/evidence, separating human decisions from agent proposals. Split unresolved work into owned outputs, dependencies and gates. Choose fitting skills/tools and the least sufficient effort; spare resources do not justify parallelism. Independently check deliveries; “done” and exit 0 are claims. Arbitrate conflicts, separating scientific findings from product decisions and simulation from effects. Checkpoint completed/running/pending/blocked work, next decision and owner; changed scope/authority returns to the person.

Give each ready, authorized operation a bounded stretch; name the served and next one at its checkpoint. Repeat only for a recorded dependency, authorized urgency or no other ready operation. Waiting consumes no turn and is no failure. This is turn coordination, not scheduling or a permanent agent mode.

Pause/resume retains operation identity, served stretch, budget, attempts, pending review and uncertain effects. Recheck authority/continuity; a fresh name/worker grants no fresh budget or priority.

Before concurrent work, optionally run `node skills/vespi/core/host-resources.mjs` for local time/memory/parallelism. It is not quota or permission; if unavailable say “not measured” and sequence conservatively. No default per-turn probe or private host details in public Lore.

The unit is not the agent. The unit is the operation.

What Vespi owns

A live bounded operation: declare its effect, prove authority before the border, perform once, verify separately, return a truthful receipt, checkpoint durable state, and — when a material premise falls — revalidate before continuing. It may wait, defer, move laterally through existing routing, or stop. Waiting is a legitimate result, not a failure.

What Vespi never owns

Lore, universal routing, learning, schedulers, persistence engines, wallets, migration, or any foreign Lore. Vespi proposes with evidence and provenance; only `save-to-lore` arbitrates the path to Lore, and only the owning governance writes it. Vespi never writes Lore directly — not foreign Lore, not its own.

Invocation — who calls, and what arrives

The coordinator in role calls this protocol with a strained or continuing operation: its mandate, authority, state, and what changed. Human phrases never invoke it directly — they route through use-lore’s canonical table ("Three ordinary phrases, three owners"): no way of working yet is `use-lore`’s, and designing a Lore-owned artifact is `brainstorming-lore`’s. Under an active agreement that already covers the piece, this protocol stays quiet: the silent check runs first, silently. Under every invocation, the five R2 conditions run as the internal test — the full list lives in `use-lore`, and this skill applies the same law.

Lifecycle (pressure map, not a state machine)

Prepare → authorize → perform → verify/reconcile → receipt → checkpoint. A resumable state (waiting, deferred, unknown, needs-decision) survives the session; only a closed state ends the operation. When the world changes under a live operation: revalidate the mandate against current authority. If the mandate still applies and the transition was pre-authorized, continue. If purpose, owner, authority, or validity changed materially, stop silent continuation and ask — that is governance, not revalidation.

Sparse operation — a simple operation stays simple

Sparse opens no operation: a single step with no external effect is reported in one line (outcome plus persistence owner `none`) and skips the rest: no lateral probe, no human-context or provenance-role fields. What continues is not sparse: open a bounded operation, whose receipt carries a verifier distinct from the executor. Those appear only when ma