REVIEW AND REPAIR PASS — SINGLE-FILE CANVAS VISUALIZER

You are reviewing a visualizer I already have. Do not restructure it, add
dependencies, a build step, or a second file.

REPORT FIRST. CHANGE NOTHING UNTIL I SAY GO. Work the whole pass, show me
what you found, and stop. When I say go, fix what is on that list and
nothing else.

LOOK BEFORE YOU READ. The whole pass depends on this rule.

Get images of it running before you open the source: one at rest, one
mid-motion, and one at the closest point of any camera move. If the piece is
generative — anything seeded, random or procedural — reload it five times
and keep all five. One still tells you about one seed, and the fault you are
hunting may live in the other four.

IF YOU CANNOT GET AN IMAGE, SAY SO IN ONE LINE AND CARRY ON. Do not quietly
reconstruct the picture from the geometry in the source. That substitution
is the exact thing this pass exists to prevent, and it produces confident
findings about something you have not seen. Instead: answer sections 2 and 3
from the source, which is where they live anyway, and mark every finding in
sections 1 and 4 UNRANKED — real candidates, unconfirmed by eye. A target
that is dead code, a component inside a larger build, or something behind a
login is normal, not exotic.

Then work through these in order.

1. TERMINATIONS
   Follow every drawn path to its end. Does it land on something real, or
   does it stop in empty space or run off the edge? A line that ends nowhere
   reads as unfinished even when a viewer cannot say why.
   The same question in time rather than space: if anything moves the view,
   step through its keyframes and confirm the subject is still in frame at
   every one, including the last.

2. LAYER ORDER
   List the layers in the order they are composited. Then find anything that
   emits light and check what it is being painted over. Light from behind an
   object must not appear in front of it. If a glow layer is drawn last
   across the whole scene, the fix is to punch the occluders' footprints out
   of it once at load — not to recompute it every frame.

3. WORK DONE EVERY FRAME THAT DID NOT NEED TO BE
   Two lists, in this order.
   First: everything recomputed on every frame whose output could not have
   changed since the last one — static geometry, text, gradients, lighting,
   anything derived only from values that do not move. This is where the
   cost usually is, and it is there whether or not the file contains a
   single conditional.
   Second: every conditional that switches an effect on or off by distance,
   size, state or frame budget, and for each one state out loud which branch
   is the expensive one. A gate that is backwards looks perfectly reasonable
   in the source and costs frames in exactly the moments a viewer is paying
   most attention.

4. DECORATION VERSUS DATA
   Inventory every repeated element, label and indicator, and mark each one
   CARRIES INFORMATION or TEXTURE. Delete anything that looks like it is
   reporting a value and reports nothing — that is a small lie told to every
   viewer on every frame. Check the wiring, not the intent: a status badge
   reading a flag that is written and never read, a label naming a
   capability this file does not own, an on-screen instruction for an input
   with no handler behind it.
   Keep the texture that is genuinely carrying density, and tell me which
   you are keeping and why BEFORE you delete anything. Removing all of it
   usually guts the piece.

5. LIGHTING CONSISTENCY
   Pick one light direction and apply it everywhere. Apply it only to layers
   you can compute once — per-frame lighting on a static layer is cost you
   are paying for nothing.

HOW TO REPORT BACK

- Before and after, in plain words, per fault. Not a changelog.
- TAG EVERY FINDING with how it is knowable. Exactly one of three:
    SEEN — name the observation. "The frame rate falls as the camera pushes
    in." If you can name it, you have the bug.
    SEEN WITH SETUP — visible, but only once something is arranged. Name the
    setup: the seed, the window size, the state to trigger, how many reloads.
    READ ONLY — invisible by construction. A flag written five times and
    read zero times has no visual signature and never will. This is the
    WORST kind, not the weakest: nobody will ever report it, so it survives
    forever. Say how you established it — the search, the trace, the
    handler that is missing.
  A finding that fits none of the three is not a finding. It is a plausible
  explanation, and you should say so rather than ship it as a fault.
- Say what you could not check, and what you would need in order to check it.
- If a fix is a trade rather than a win — frame rate bought with fidelity,
  say — call it a trade.