vigil-verify
Phase V (Verify) — establishes a reproducible failure. Deterministic-first; on two failed deterministic attempts, switches to statistical replay with confidence bands. No attribution begins without this phase passing. Use when starting any VIGIL mission, on mission intake, before any isolation or intervention work.
- License 许可
- MIT
- 所属仓库
- Rynaro/prisma
- 最近更新
- 2026-10-18
- Stars
- ★ 1
- Forks
- 0
01 前言 Front Matter
- name
- vigil-verify
- metadata
- { "phase": "V", "methodology": "VIGIL" }
- description
- Phase V (Verify) — establishes a reproducible failure. Deterministic-first; on two failed deterministic attempts, switches to statistical replay with confidence bands. No attribution begins without this phase passing. Use when starting any VIGIL mission, on mission intake, before any isolation or intervention work.
- allowed-tools
- run_test, run_command, read_env, capture_trace, set_seed
03 SKILL.md 正文
SKILL: Verify — establish reproducible failure
When to use
Load at the start of every VIGIL mission. Unload when reproduction.md is schema-valid and DETERMINISM_VERDICT ≠ intermittent.
Memory pre-flight:
recallMUST have fired in Phase V (seePERSONA.md§"Memory pre-flight") before any reproduction work begins. If it hasn't — e.g. this skill was loaded directly — call it now:mcp__crystalium__recall( scope = { project: <cwd-project>, agent_class_visibility: "vigil" }, query = <failure signature — error class, key frames, command>, k = 5, layers = ["semantic", "episodic", "procedural"] )Prioritize procedural hits (prior isolation techniques for this error class) and semantic hits (known root-cause categories matching the signature). Fold relevant results into hypothesis generation before Step 1. If
mcp__crystalium__*tools are unavailable, proceed without memory — never hard-fail.
Contract
| Field | Value |
|---|---|
| LLM calls permitted | Yes, for classifying failure signature and reading trace output |
| Tool budget | ≤15% of mission budget |
| Output | reproduction.md — schema-valid per schemas/reproduction.v1.json |
| Failure mode | DETERMINISM_VERDICT = intermittent → halt, emit [GAP], escalate |
Inbound Envelope Verification (Escalation Entry)
When VIGIL is invoked on the escalation entry mode (APIVR-Δ → VIGIL), run this verification BEFORE the deterministic-first protocol below. This implements ECL §6.2.2 and VIGIL I-11.
Trigger
If the upstream artifact path P has a sibling ${P%.*}.envelope.json, verification is mandatory. If no sidecar exists (non-ECL APIVR-Δ caller), skip this section and proceed to Step 1 below.
Step V-E1 — Schema shape
Validate the envelope JSON against schemas/ecl/envelope.v2.json (or envelope.v1.json for a v1.x sidecar received during the ECL §7.3 compatibility window — select the vendored file matching the received envelope_version).
Check that the envelope parses as valid JSON and all required fields are present: envelope_version, message_id, thread_id, parent_id, from, to, performative, objective, artifact, integrity, trace. On failure: failure code SCHEMA_INVALID.
Step V-E2 — Contract match
Cross-check fields against schemas/ecl/contracts/apivr-to-vigil.yaml:
from.eidolonMUST equal"apivr"andto.eidolonMUST equal"vigil". On failure:UNDECLARED_EDGE.performativeMUST be one ofESCALATE,REQUEST,ACKNOWLEDGE. On failure:PERFORMATIVE_NOT_ALLOWED.artifact.kindMUST equal"repair-failed-report". On failure:ARTIFACT_KIND_NOT_ALLOWED.
Step V-E3 — Integrity check
Recompute the SHA-256 digest of the payload file bytes and compare against envelope.integrity.value:
computed=$(shasum -a 256 "$payload_path" | awk '{print $1}')
declared=$(grep -o '"value":"[^"]*"' "$envelope_path" | head -1 | cut -d'"' -f4)
# [ "$computed" = "$declared" ] || failure code: INTEGRITY_MISMATCH
Step V-E4 — Trace event
Append one JSONL line to .eidolons/.trace/<thread_id>.jsonl (relative to consumer project root; create directory if absent):
On success:
{"ts":"<RFC3339>","event":"verify_pass","message_id":"<uuid>","thread_id":"<uuid>","from":"apivr@<version>","to":"vigil@<version>","performative":"<performative>","integrity_method":"sha256"}
On failure:
{"ts":"<RFC3339>","event":"verify_fail","message_id":"<uuid>","thread_id":"<uuid>","from":"apivr@<version>","to":"vigil@<version>","performative":"<performative>","integrity_method":"sha256","verify_failure_code":"<CODE>"}
If the envelope is invalid JSON, use thread_id: "unknown" and message_id: "unknown" as fallback values.
Step V-E5 — On verify_fail: halt
On any verification failure:
- Emit a
[GAP]finding:[GAP] Inbound envelope verification failed: <FAILURE_CODE>. The upstream repair-failed-report.envelope.json did not pass ECL §6.2.2 verification. Mission halted. - Halt the mission — do NOT proceed to the deterministic-first protocol.
- Route to human (or back to APIVR-Δ if the failure is
INTEGRITY_MISMATCH— the report may have been tampered or corrupted in transit).
The Deterministic-First Protocol
Step 1 — Normalize the failure signature
Extract from upstream artifact (or bug report):
- Test/command — exact invocation that exhibits the failure
- Error class — categorical (
TEST_ASSERTION,RUNTIME_ERROR,BUILD_ERROR,TYPE_ERROR,LINT_VIOLATION) - Key stack frames — top 3–5 frames, normalized (strip absolute paths, line numbers preserved)
- Observable symptom — the specific assertion/error message
If upstream provided an APIVR-Δ repair-failed-report.md, copy these fields directly. Do not re-derive.
Step 2 — First deterministic attempt
Set controlled conditions:
seed: <recorded_or_default>
env: <pinned per lockfile / container spec>
fs: <isolated working copy from commit SHA>
time: <frozen if test is time-sensitive>
Run the failing invocation. Record:
- Exit code
- stdout/stderr tail (last 200 lines)
- Comparison of observed signature to upstream signature
Result categories:
FAIL_MATCH— fails with the same signature as upstream → proceed to Step 3FAIL_DIFFERENT— fails but with different signature → record as[DISPUTED], use observed signature, proceed to Step 3PASS— did not fail → proceed to Step 3 with suspicion of flakiness
Step 3 — Second deterministic attempt
Re-run with identical conditions. Compare to Step 2.
Verdict matrix:
| Step 2 | Step 3 | Verdict | Action |
|---|---|---|---|
| FAIL_MATCH | FAIL_MATCH | stable |
Proceed to Isolate |
| FAIL_MATCH | FAIL_DIFFERENT | flaky |
Switch to statistical |
| FAIL_MATCH | PASS | flaky |
Switch to statistical |
| FAIL_DIFFERENT | FAIL_MATCH | flaky |
Switch to statistical |
| FAIL_DIFFERENT | FAIL_DIFFERENT (same sig) | stable |
Note signature drift, proceed |
| PASS | FAIL_* | flaky |
Switch to statistical |
| PASS | PASS | not_reproduced |
Halt — emit [GAP], escalate |
Statistical Mode
Triggered by flaky verdict. Protocol:
- Run the failing invocation 5 times under identical deterministic conditions.
- Record pass/fail and observed signature for each.
- Compute failure rate and 95% confidence interval (Wilson score interval for small N).
- Classify:
- Consistent flake — ≥3/5 fail with same signature →
DETERMINISM_VERDICT = flaky,[FLAKE]marker set, proceed to Isolate. Subsequent counterfactual interventions must also use 5-run statistical evaluation. - Inconsistent flake — <3/5 fail, or signatures vary widely →
DETERMINISM_VERDICT = intermittent, halt, escalate to FORGE or human. VIGIL cannot reliably attribute under this condition.
- Consistent flake — ≥3/5 fail with same signature →
Confidence band recording
For every statistical-mode decision:
statistical_evidence:
runs: 5
failures: 4
failure_rate: 0.80
ci_95: [0.37, 0.99]
signature_consistency: 1.0 # fraction of failures with matching signature
verdict: flaky
Downstream phases inherit statistical mode — every intervention in Phase I will be evaluated across 5 runs, with flip requiring ≥4/5 successes.
Writing reproduction.md
Schema-required fields:
mission_id: VIGIL-YYYYMMDD-NNN
upstream_artifact: <pointer | null>
authority: read-only | sandbox | write
failure_signature:
command: "<exact invocation>"
error_class: LOGIC_ERROR | REGRESSION | BUILD_ERROR | TYPE_ERROR | LINT_VIOLATION | RUNTIME_ERROR | INTEGRATION_ERROR | ENVIRONMENT_ERROR | HEISENBUG | COMPOUND | SPEC_DEFECT
assertion: "<observable symptom>"
stack_top: [<frame>, <frame>, <frame>]
reproduction_mode: deterministic | statistical
reproduction_evidence:
- attempt: 1
result: FAIL_MATCH
signature_match: true
stderr_tail: <200-line excerpt ref>
- attempt: 2
result: FAIL_MATCH
signature_match: true
stderr_tail: <excerpt ref>
determinism_verdict: stable | flaky | intermittent | not_reproduced
statistical_evidence: <null | object> # only populated in statistical mode
markers:
- FLAKE # only if flaky
- GAP # only if evidence missing
Common pitfalls
- Assuming the upstream signature is correct. Re-verify. APIVR-Δ's Reflect phase may have already attempted fixes that altered the failure shape.
- Running against the wrong commit. Always pin to the SHA that the upstream artifact referenced.
- Ignoring env drift. A failure that reproduces locally but not in CI (or vice versa) is itself a finding — document the env delta.
- Jumping to statistical mode too early. Two deterministic attempts minimum. One inconsistent result is not enough to declare flakiness.
- Accepting
PASS → PASSas "fixed already." If the upstream failure is real and your runs all pass, something about your reproduction setup is wrong. Escalate with[GAP].
VIGIL Phase V — the gate through which all other phases must pass
04 同仓库更多 Skills
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.
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.
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.
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.
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.
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.