vm-code-review-standards

# VM Code Review Standards

## Overview

This skill defines **code-level implementation standards** derived from systematic analysis of 106+ Copilot PR review comments across multiple repositories. These are generic patterns that apply to any application development, regardless of tech stack.

## Brownfield Context

In brownfield code review, these standards serve two purposes:
1. **Detect new anti-patterns** introduced by the change set being reviewed
2. **Check consistency** — do the changes follow the patterns already established in the existing codebase (not just abstract best practice, but actual team convention)?

The Code Review Agent MUST note when a finding is:
- A new violation introduced by the change (action required from developer)
- A pre-existing violation that the change touches but did not introduce (flag for awareness, not blocking)
- A consistency deviation from the existing codebase pattern (discuss with team)

## When to Use

- When reviewing code changes in a pull request or change set for brownfield systems
- When checking changed files against the patterns established in the rest of the codebase
- When performing a targeted security-plus-quality review on a specific module

## When NOT to Use

- For infrastructure/architecture decisions (use `tech-policy-matrix.yaml`)
- For framework/language selection (use `TECH_STACK_STANDARDS.md`)
- For injection scanning (use `vm-input-validation-checker`)
- For full-codebase optimization sweeps (use Code Optimization Agent)

## Unitary Function

**ONE RESPONSIBILITY:** Provide actionable code-level implementation standards that prevent recurring PR review findings, applied to a specific change set with brownfield awareness.

---

## Standards Categories

### 1. Authentication & Authorization

**Recurring finding:** Endpoints trusting client-supplied identity headers, missing ownership checks, insecure identity defaults.

**Rules:**

1. **NEVER trust client-supplied identity headers** for authorization decisions. Identity MUST be derived from server-validated tokens (JWT, session cookies, or trusted proxy headers).
2. **Every data-access endpoint MUST enforce ownership checks.** Before returning or modifying a resource, verify the authenticated user owns or has permission to access it. Missing ownership checks create IDOR vulnerabilities (CWE-639).
3. **Dev-mode identity fallbacks MUST be disabled in non-dev environments.**
4. **Use cryptographically secure randomness for security contexts.** Use `crypto.randomUUID()` / `secrets` module, not `Math.random()` / `random` module.

---

### 2. Input Validation and Schema Strictness

**Recurring finding:** Loose types in request/response models bypass validation and allow malformed data.

**Rules:**

1. **Use concrete types, not generic containers.** Avoid `list`, `dict`, `any`, `object` in API schemas.
2. **Constrain string fields with enums/Literals where values are known.** For `role`, `status`, `type` fields — use `Literal["user", "adm