vela-secure-codinglisted

# Vela secure coding Vela renders **untrusted deck JSON** in runtimes that have real filesystem and network capability. Almost every security bug in this repo's history came from ordinary feature code — an export path, a new block renderer, a colour field — not from "security work". So these rules apply to **every** change — and they are equally the rubric for **reviewing** code: when running a code review, security review, or PR review in this repo, check the diff against §3's failure modes and §4's per-surface checklist, verify §2's canonical helpers were reused rather than re-implemented, and hold findings to §5's proof standard (a claimed vulnerability or fix is demonstrated at the real sink, not asserted from source reading). Review comments follow §6's disclosure discipline. ## Triage — how much of this skill your change needs **§0 (the five non-negotiables) is mandatory for every change, always.** Then: **Full read required** (§1–§6) if your change does ANY of: reads a new or existing deck-supplied field anywhere; touches a sanitizer, encoder, allowlist, or `SAFE_*` key set; touches an exporter (PDF/PPTX/Markdown/standalone HTML); touches `part-imports.jsx`, `part-pdf.jsx`, `part-pdf-extract.jsx`, `part-pdf-vector.jsx`, `part-export-md.jsx`, `part-pptx.jsx`, `serve.py`, `assemble.py`, `agent_backend.py`, or anything under `vela-neutralino/`; touches storage/reload paths, the startup patch, CI/release/build scripts, or any `dangerouslySetInnerHTML`/`<style>`/CSS-sin