How this site is built

Every session reads HANDOFF.md first: what is live, what is open, how I work and the rules for publishing, kept under 12 KB. AGENTS.md holds the standing rules. One agent works on a site at a time, and every session pulls before it starts, because main is production.

47 rules in scripts/consistency/rules.mjs, each a decision of mine with its date and reason. When something shows in more than one place, a page, the CV, a demo or the store, it can’t change in one and stay in another. Ten of them, in their own words:

• 9 OcttitleOne title on the site: 3D web designer
• 13 OctwordingNone of the words dropped from his positioning
• 15 Octbodernes-placeBodernes sits near the beach, not on the sand
• 17 Octpin-soundThe pin table has no sound and no Sound switch
• 17 OctcopiesCode kept in two places changes in both
• 17 Octscan-no-nodThe scan doesn’t nod or bow when he faces you
• 18 Octmagnus-white-wallMagnus' wall is painted white
• 20 Octclient-labelsEach client site says what it is: Live site, Redesign or Proposal
• 20 Octwork-orderWork runs the Simulacra first, then the live sites, then the proposals
• 21 Octhow-i-workHow I work says who writes the code: AI agents, with him making the calls

$ node scripts/consistency/check.mjs
consistency: no out/ (run next build first); checking the sources only.
consistency (build): 281 documents, 47 rules.

✗ copies: Code kept in two places changes in both
    app/showroom/sky.ts  ↔  app/lab/pintable/engine/sky.ts
      the sun and moon: they now differ where they were the same
        only in the first:  const RAD = Math.PI / 180, E = RAD * 23.44;
        only in the second: const RAD = Math.PI / 180, E = RAD * 23.4397;
    Why: Swash’s surf runs under Bodernes, the opening’s table is Pintable’s, the WebGPU yield guard is in three places, and every Maquette page copies its repo’s src/. A fix in one copy and not the other is how the Safari band upload missed Pintable (17 October).
    Owner: the thread that changed the copy. Every copy: docs/consistency-map.md#copies

1 to fix.

Measured in Chrome on a MacBook Pro (M4 Pro) against the live site: a 390 px phone at 3×, the CPU slowed four times, scrolled to the end by a thumb’s flicks. The GPU is the Mac’s, so a real phone is the last check.

What the lag taught

1. A shader compiles in the first frame that draws it. So every piece compiles all of its shaders before its first frame, hidden and culled parts included, and shows a model only once they have settled.
2. A compile belongs to what it draws into. Warm-ups bind the frame’s own render target; on WebGPU, the frame’s call depth too, shadow maps and post passes included.
3. Safari waits for a shader still linking inside any call that touches it. Nothing draws before it is warmed, and every program a material has is waited for, not only its latest.
4. Pictures decode off the page. createImageBitmap for images, a worker for EXRs, big textures uploaded in bands of rows.
5. Long work on arrival runs in slices of a few milliseconds, each its own task, with a message between them rather than a timer.
6. A context is released when its piece leaves: dispose(), then forceContextLoss().

Sentry, in the EU, errors only: no tracing, no replay, no cookies, no IP addresses. A 1.4 KB loader; the SDK comes only with the first report, so a page that works never loads it. A piece that gives up and shows its still says so (fellBack()). The first catch, 14 October: Shrike’s WebGPU texture views failing on Chrome 141, now guarded by guardWebGPU().