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