VR-* Type Catalog

Verification Requirements (VR-) are checks with a specific expected output. Every claim that work is complete must be backed by a VR- check returning the expected result. Massu AI ships a catalog of built-in types plus two extension points — custom VR-* types and per-language command overrides — both declared in massu.config.yaml.

Built-in Catalog

Every built-in VR-* type, its command, and the expected output. Commands marked with <language> use the per-language override (see below) when present, falling back to the defaults listed here.

Per-Language Command Override

Override the command that VR-TEST, VR-TYPE, VR-BUILD, VR-SYNTAX, or VR-LINT run for a specific language. Any key omitted falls back to the built-in default.

Declared under verification.<language> in massu.config.yaml:

verification:
  python:
    test: cd app && python3 -m pytest -q
    type: cd app && python3 -m mypy .
    syntax: cd app && python3 -m py_compile
    lint: cd app && python3 -m ruff check .
  typescript:
    test: npm run test:unit
    type: cd packages/core && npx tsc --noEmit
    build: npm run build:prod

Multi-Runtime Projects

When framework.type: multi, VR-* lookups are per-language. The "primary" language comes from framework.primary. Commands that are language-agnostic (VR-PATTERN, VR-SECURITY, VR-GENERIC) are unaffected.

framework:
  type: multi
  primary: python
  languages:
    python:
      framework: fastapi
    typescript:
      framework: next

verification:
  python:
    test: cd api && python3 -m pytest -q
  typescript:
    test: cd web && npm test

Custom VR-* Type Registration

Projects can register domain-specific verification types via verification_types in massu.config.yaml. The key is the type name (conventionally prefixed VR-); the value is a human-readable description. These surface in commands that enumerate the catalog.

verification_types:
  "VR-IBKR-CONTRACT": "Interactive Brokers contract object resolves to a real security via the IBKR API"
  "VR-POLICY": "All enforced policies in the UI are actually checked at runtime by policy-engine.ts"
  "VR-RLS": "Every Supabase table referenced by the feature has a passing RLS policy test"

Worked Example: VR-IBKR-CONTRACT

A trading-compliance project needs to verify that every IBKR contract object used in code resolves to a real security.

Declared:

verification_types:
  "VR-IBKR-CONTRACT": "Interactive Brokers contract object resolves to a real security via the IBKR API"

Once registered, the custom type is recognized by /massu-verify enumeration and can be referenced in plan verification tables. The runner command is your responsibility — Massu does not execute custom VR-* types for you; it catalogs them so plans can cite them.

Where VR-* Runs

• Pre-commit (/massu-commit) — VR-TYPE, VR-TEST, VR-PATTERN, VR-GENERIC, VR-SECURITY
• Pre-push (/massu-push) — adds VR-BUILD, VR-HOOK-BUILD, VR-COVERAGE
• Plan loop (/massu-loop) — VR-PLAN-COVERAGE, VR-PLAN-SPEC, VR-PROTOCOL
• Verification sweep (/massu-verify) — runs all built-in types + every custom type declared in config

Canonical Rules and VR Mapping

Every Canonical Rule (CR-) maps to a VR- type. See CLAUDE.md for the full rule list.

Related

• auto-detection — how verification.<language> commands are chosen by VRCommandMap
• reference/config-reference — full YAML schema for verification and verification_types
• migration/v1-to-v2 — how verification and verification_types move from v1 to v2