Existing code-based-animation research isn't wired into the video workflow pipeline

Projects/tech-explainer-video-workflow.md (§1–2) locks the diagram pipeline to Eraser → Figma (SVG) → Canva/Smart Animate as the only animation path, and its "Current Focus"/toolchain section makes no mention of a code-based alternative. But three fully-worked setup docs already sit in TechResearch/TechConcepts_Explanatory_Animations/, written 2026-07-03 — three weeks before the workflow doc itself (2026-07-28) — and neither file links to the other.

• Code-Based Animation — Setup Reference gives a concrete three-tier escalation path (plain HTML/CSS/SVG/vanilla JS → React Flow + Framer Motion → Tailwind only once styling repeats) with exact npm install commands, explicitly aimed at "anything with real state — a value lagging then catching up, a node highlighting because of data" — i.e. precisely the kind of system-design/tracing/data-flow explainer content the workflow doc's Step 1 beat-list ("hook → problem → concept → diagram walkthrough") is built to narrate over.
• Excalidraw + excalidraw-animate — Setup Reference documents a zero-cost "watch it get drawn" reveal style (stroke-by-stroke SVG animation, ~500ms/stroke) that's a direct, cheaper alternative to the Eraser→Figma→Smart-Animate chain for any segment that's a one-shot static diagram reveal rather than something needing state changes or highlighting — exactly the case the 2026-07-28 opportunity note flagged as a workflow gap, but that note only pointed at the thin Tools/Excalidraw stub, not this working setup guide with the actual escalation criteria and gotchas (negative-width elements, WebM export flakiness, npm API not being documented).
• What I Can Achieve is a brainstorm of concrete animation concepts (packet-flow visualizations, load-balancer routing, algorithm traversal, event-loop walkthroughs) mapped directly onto the same React Flow/Framer Motion/Tailwind stack — useful as a beat-list source for future explainer topics beyond whatever Eraser/Figma can produce as static architecture diagrams.

None of this contradicts the current Eraser→Figma default — for polished, branded architecture diagrams it's still the right call — but the workflow doc's Step 2 currently reads as though Eraser→Figma is the only option, when a fully-scoped, already-tested code-based escalation path (with a documented "when to escalate" criterion: # of repeated components, whether values are data-driven vs. eyeballed) already exists in the vault and was written before the workflow doc itself.

Next step: add a short "when to reach for code instead of Eraser/Figma" cross-reference in tech-explainer-video-workflow.md §2 (Diagram pipeline), pointing to the three-tier escalation rule in code_based_animation_setup.md and the stroke-reveal option in excalidraw.md — this is a doc cross-link, not new research; the material to cite is already complete.