Vc Risk Evidence Pack

vc-risk-evidence-pack

Output style: Follow process/development-protocols/communication-standards.md — answer-first, plain language, no unexplained jargon, TL;DR on long responses.

Generate and validate the manual-first evidence pack required before finalizing, pushing, or handing off high-risk implementation work.

When To Invoke

• VALIDATE Layer 1 security surface check — when the plan touches a high-risk class, flag the need for an evidence pack before routing to execute-agent.
• EXECUTE before marking high-risk work complete — execute-agent must produce or verify the evidence pack exists before reporting DONE on any high-risk class.
• code-reviewer as pre-PR quality gate — code-reviewer checks for the evidence pack presence before approving changes that touch a high-risk surface.

6 High-Risk Class Definitions

From process/development-protocols/orchestration.md ("High-Risk Execution Handoff") and process/development-protocols/implementation-standards.md ("Risky Work Evidence Contract") — both sources agree:

1. auth or identity — authentication flows, session tokens, user identity resolution, Clerk JWT handling, or any surface that determines who the caller is.
2. billing or credits — billing events, credit balance mutations, Stripe charge flows, OpenRouter credit accounting, credit transaction records, or subscription state changes.
3. schema/data migration or destructive data mutation — Prisma migrations, raw SQL mutations, destructive writes that delete or overwrite persistent data, or schema changes to existing models.
4. public API or external contract changes — tRPC procedure signature changes visible to the frontend, Hono route contract changes consumed by external callers, webhook shape changes, or any API surface that third parties or the client app depend on.
5. deploy/runtime/container/proxy/gateway behavior — Dockerfile changes, supervisord config, start.sh, container service ports, Bun server entry, Hono route registration, Caddy proxy config, worker-node provisioning, or any change that affects how a running service starts or routes traffic.
6. permission, secret, or trust-boundary logic — instance token gating, verifyInstanceOwnership, BYOK secret fetch paths, MITM proxy key injection, Bright Data credential handling, or any logic that controls what a caller is allowed to access.

5-Artifact Schema

Per task-folder artefact colocation, all artifacts go inside the selected plan's task folder (e.g. process/features/{feature}/active/{slug}_{date}/harness/ or process/general-plans/active/{slug}_{date}/harness/), so the whole pack moves with the plan as a unit. Legacy path reports/harness/ is deprecated for new writes; never write the pack to a sibling reports/ dir or any ad-hoc location. The validator script lives at .claude/skills/vc-risk-evidence-pack/scripts/validate-risk-artifacts.mjs.

1. risk-gate.json

Records the risk class, work description, and approver identity before work begins or is finalized.

{
  "riskClass": "<one of the 6 classes above>",
  "workDescription": "<short description of the change>",
  "approver": "<person or agent that reviewed the risk classification>",
  "mustStopBeforeFinalize": true
}

2. context-snippets.json

Relevant code snippets with exact file and line citations for every surface the change touches in the high-risk class.

{
  "snippets": [
    {
      "file": "packages/api/src/router/billing.ts",
      "lines": "120-145",
      "description": "verifyInstanceOwnership call before secret read",
      "content": "<excerpt>"
    }
  ]
}

3. verification.json

Documents every verification step taken and its result. Steps must cover both the happy path and at least one failure or boundary case.

{
  "steps": [
    {
      "step": "<what was verified>",
      "command": "<command run, if applicable>",
      "result": "PASS | FAIL | SKIP",
      "notes": "<observations>"
    }
  ]
}

4. review-decision.json

The explicit reviewer decision record. Must contain APPROVE or REJECT with a written rationale — no implicit approvals.

{
  "reviewer": "<name or agent>",
  "decision": "APPROVE | REJECT",
  "rationale": "<written reason>",
  "timestamp": "<ISO 8601 date>"
}

5. adversarial-validation.json

Required when the path is high-risk or attack-sensitive (e.g. auth bypass, privilege escalation, secret exfiltration). Documents adversarial scenarios considered and whether each was ruled out.

{
  "scenarios": [
    {
      "scenario": "<attack or misuse description>",
      "ruled_out": true,
      "rationale": "<why this path is not exploitable>"
    }
  ]
}