AGENT SKILL

vivi-verify-incoming

Load when reading any upstream artefact handed off to Vivi that carries a sibling .envelope.json. BLOCKING per ECL §6.2.2: the orchestrator MUST have verified the envelope's SHA-256 (eidolons verify-envelope --block / eidolons run --verify) and recorded a verify_pass before dispatch. If no verify_pass exists for the message_id, or a verify_fail is present, REFUSE to process the payload and hand back to the orchestrator. Symmetric receiver gate — every Eidolon enforces it identically.

License 许可
MIT
所属仓库
Rynaro/prisma
最近更新
2026-10-18
Stars
★ 1
Forks
0

01 前言 Front Matter

name
vivi-verify-incoming
metadata
{ "methodology": "Vivi" }
description
Load when reading any upstream artefact handed off to Vivi that carries a sibling .envelope.json. BLOCKING per ECL §6.2.2: the orchestrator MUST have verified the envelope's SHA-256 (eidolons verify-envelope --block / eidolons run --verify) and recorded a verify_pass before dispatch. If no verify_pass exists for the message_id, or a verify_fail is present, REFUSE to process the payload and hand back to the orchestrator. Symmetric receiver gate — every Eidolon enforces it identically.

03 SKILL.md 正文

Verify-Incoming Skill — Vivi (blocking, symmetric)

Receiver-side integrity gate for inbound ECL hand-offs. When an upstream artefact arrives with a sibling .envelope.json, Vivi MUST NOT process the payload unless its SHA-256 integrity has been verified and passed. This is the blocking posture mandated by ECL §6.2.2 ("a receiver SHALL NOT process a payload whose integrity tag does not match"). It is symmetric: every Eidolon in the roster ships this same gate, so no hand-off edge can silently skip it.

Posture change (vs. earlier opt-in warn-only): previous versions logged a warning and processed the payload anyway. That is now superseded. On an unverified or failed envelope this skill refuses and hands back to the orchestrator. Provenance is only a differentiator if receivers actually reject tampered payloads — end to end, not just at the orchestrator.


Where the cryptographic check runs (and why the receiver only reads)

Vivi's tool surface cannot run the SHA-256 gate itself (receiver Eidolons have restricted or no Bash). The mechanical check therefore runs at the orchestrator, once, before Vivi is dispatched:

# Orchestrator pre-step (host LLM, full Bash) — already shipped in the nexus CLI:
eidolons verify-envelope <artefact>.envelope.json --block      # exit 3 ⇒ tamper/mismatch
#   …or, when routing through the kernel:
eidolons run --verify <artefact>.envelope.json --verify-block  # gates the route

The gate writes a verify_pass (or verify_fail) trace event keyed by message_id. Vivi then enforces the result using only Read — no Bash required:

  1. Read .eidolons/.trace/<thread_id>.jsonl (the thread_id is envelope.thread_id).
  2. Find the event whose message_id matches envelope.message_id.
  3. verify_pass with integrity_method: "sha256" → integrity confirmed, proceed to contract conformance below.
  4. verify_fail, or no matching event → integrity unconfirmed → REFUSE (see Failure Mode). Do not process the payload.

Defense-in-depth (optional): if Vivi's host happens to grant Bash with eidolons on PATH, it MAY independently re-run eidolons verify-envelope <env> --block and abort on a non-zero exit. The orchestrator pre-verify is the contract; self-verification is an additional guard, never a replacement.


Memory: Recall + Ingest (CRYSTALIUM)

On an inbound hand-off, first recall related prior context (if CRYSTALIUM available):

mcp__crystalium__recall(
  scope  = { project: <cwd-project>, agent_class_visibility: "vivi" },
  query  = <artefact GOAL + from.eidolon + artifact.kind>,
  k      = 5,
  layers = ["semantic", "episodic", "procedural"]
)

Only after the integrity gate passes (verify_pass) ingest the received envelope to record the inbound edge:

mcp__crystalium__ingest(
  envelope = <received .envelope.json contents>,
  payload  = <artefact payload contents>
)

Never ingest an envelope that failed or skipped verification. Graceful skip: if mcp__crystalium__* tools are unavailable, skip both calls silently.


Trigger

Load this skill automatically when:

  • Reading an upstream artefact at path P, and
  • A sibling file ${P%.*}.envelope.json exists in the same directory.

Detection rule (POSIX sh compatible):

envelope_path="${artefact_path%.*}.envelope.json"
[ -f "$envelope_path" ] && load_skill "verify-incoming"

If no .envelope.json sibling exists, this is a non-ECL artefact — skip the gate silently and process normally.


Inbound edges Vivi accepts

to.eidolon MUST equal vivi. from.eidolon MUST be a declared upstream sender. Performative and artifact.kind are validated against the ECL inbound contract contracts/<from>-to-vivi.yaml (source of truth); the table below is the convenience summary:

from performative(s) artifact.kind
atlas PROPOSE, INFORM, REFUSE scout-report
spectra PROPOSE, INFORM, REFUSE spec
vigil PROPOSE, CRITIQUE, INFORM root-cause-report
forge PROPOSE, INFORM, CRITIQUE reasoning-report

A hand-off whose from.eidolon is not listed, or whose performative / artifact.kind is not allowed for that edge, is an UNDECLARED_EDGE / PERFORMATIVE_NOT_ALLOWED / ARTIFACT_KIND_NOT_ALLOWED violation → REFUSE.


Failure Mode (BLOCKING — refuse, do not process)

On any integrity or contract failure:

  1. Append a verify_fail event to .eidolons/.trace/<thread_id>.jsonl.
  2. Print to stderr: [vivi-verify-incoming] REFUSE: <FAILURE_CODE> from <from.eidolon>.
  3. Do not process the payload. Hand control back to the orchestrator with a refusal. The orchestrator routes the failure to VIGIL (integrity / tamper investigation) or to the human — never a silent retry, never a silent process-anyway.

Failure codes: INTEGRITY_MISMATCH, UNVERIFIED (no verify_pass on record), SCHEMA_INVALID, UNDECLARED_EDGE, PERFORMATIVE_NOT_ALLOWED, ARTIFACT_KIND_NOT_ALLOWED, CONTEXT_OVER_BUDGET, MISSING_REQUIRED_SECTION.

On success: append verify_pass, then proceed with the payload.


Trace Events

Append one JSONL line per verification to .eidolons/.trace/<thread_id>.jsonl (create if absent). The thread_id comes from envelope.thread_id; if the envelope is unparseable, use unknown.

verify_pass:

{"ts":"<RFC3339>","event":"verify_pass","message_id":"<uuid>","thread_id":"<uuid>","from":"<eidolon>@<version>","to":"vivi@<version>","performative":"<performative>","integrity_method":"sha256"}

verify_fail:

{"ts":"<RFC3339>","event":"verify_fail","message_id":"<uuid>","thread_id":"<uuid>","from":"<eidolon>@<version>","to":"vivi@<version>","integrity_method":"sha256","verify_failure_code":"<CODE>","decision":"refused"}

Notes

  • Blocking, not warn-only. Refusal is the whole point: a receiver that processes a tamper-flagged payload defeats the provenance guarantee.
  • Symmetric. All Eidolons in the roster ship this gate with identical semantics; the only per-Eidolon variation is the inbound-edge table above.
  • Mechanical gate, single source of truth. The SHA-256 comparison is the nexus eidolons verify-envelope verb (ECL §6.2.2) — never re-implemented or LLM-estimated in this skill.
  • Read-only enforcement. The receiver needs only Read to consult the trace; this is why the gate is symmetric across tool-less Eidolons.

Verify-Incoming Skill — blocking, symmetric, mechanical-gate-backed (ECL §6.2.2)

04 同仓库更多 Skills

Rynaro
Rynaro/prisma

vivi-parallel-tracks

Load ONLY under TRANCE authorization when the Plan phase yields N independent, non-overlapping implementation tracks (disjoint file sets). Operationalizes the TRANCE G4 form — parallel multi-track implementation in mandatory git-worktree isolation, max 5 clean-context tracks, a per-track verifier cascade, a non-fungible per-track ≤3 reflection budget, explicit stop conditions, and a single-threaded merge/aggregation step. Absent TRANCE gating, Vivi runs exactly as today: single-track A→P→I→V→Δ/R.

财务
★ 1
Rynaro
Rynaro/prisma

vivi-methodology

Full Vivi cycle reference — A(nalyze) → P(lan) → I(mplement) → V(erify) → Δ(Delta)/R(eflect). Use when the task is a non-trivial feature implementation in a brownfield codebase and you need the complete methodology reference: complexity routing, evidence-grounded planning rules, test-anchoring requirements, and failure-escalation thresholds.

★ 1
Rynaro
Rynaro/prisma

vivi-memory-management

Load at Vivi session start, session end, or when you notice a repeating pattern across tasks. CRYSTALIUM-primary memory protocol: when mcp__crystalium__* tools are available, route ALL memory through CRYSTALIUM (recall/commit/ingest/plan_checkpoint/session_end). The local agents/memories/*.md files are the standalone fallback for when CRYSTALIUM is absent — EIIS conformance. Never write both.

Skill与智能体开发
★ 1
Rynaro
Rynaro/prisma

vivi-loop-native

Load in Vivi's V (Verify) phase. The core capability that distinguishes Vivi from its predecessor APIVR-Δ: drive the closed, autonomous, bounded edit-run-test loop (`eidolons sandbox loop`) as its `--fix-hook`, consuming localized feedback, retrying in fresh context, refusing to game the tests, and gating on pass^k. Use whenever the task has an executable test oracle and a loop-competent host.

★ 1
Rynaro
Rynaro/prisma

vivi-failure-recovery

Load when the Vivi Verify phase produces failures — test fails, lint error, build break, or three consecutive unsuccessful attempts at the same category. Provides the failure classification taxonomy, bounded debugging protocol, and escalation thresholds. Use to avoid the 'random retries' anti-pattern.

★ 1
Rynaro
Rynaro/prisma

vivi-esl-hop

ESL lifecycle hop — when the cortex routes a non-trivial change to Vivi in an ESL-enabled project (tonberry MCP available), Vivi owns the in_progress (implement) hop as the MAKER: declare has_code, run the loop-native A→P→I→V→Δ/R cycle in an isolated worktree, hand off to the CHECKER (never self-verify). Absent tonberry → implement normally (ESL opt-in).

Skill与智能体开发
★ 1