VERSION:

v0.1

draft

Test no.

2026l

1/n

SURFACE:

hux.works

/systems/light-mode-test

SUBJECT:

TOKEN SWAP;

SURFACE COHERENCE

AUTHOR AND DATE:

HAMISH DUNCAN

09.05.26

Light mode

VERSION:

v0.1

draft

Test no.

2026l

1/n

SURFACE:

hux.works

/systems/light-mode-test

SUBJECT:

TOKEN SWAP;

SURFACE COHERENCE

AUTHOR AND DATE:

HAMISH DUNCAN

09.05.26

Thesis

Col 3 — Test no. I rhymed the format with 2026t / 4/12. The t looks like talk no. 4 of 12 from the Pentagram talk. So 2026l reads as light-mode test, 2026 series and 1/n signals an ongoing series with no fixed total — honest about the fact that mode-testing isn't a one-off. If you'd rather lock the count, 1/3 (light, dark, high-contrast) works.

Col 4 — Surface, not Client address. This is HUX's own work, not a client deliverable. "Client address" doesn't translate. "Surface" both names the URL location and echoes the test's vocabulary — the system can swap surfaces without losing itself. The actual URL becomes the address.

Col 5 — Subject, kept. Two-line subject keeps the rhythm. Token swap; surface coherence mirrors the cadence of Think as a team; Speak machine — two phrases joined by a semicolon. The semicolon is doing real work: it says these are the two halves of the test.

Col 6 — Author and date, kept. Standard.
Two alternative col 3 framings to consider

Test no. / 2026l / 1/n — open series (my pick)
Version: / v0.1 / 2026.05.09 — software-build framing, ties to the v0.1 in your eyebrow
Slug: / light-mode-test / 2026.05.09 — pure machine address

The first reads most like a talk dossier and matches the reference. The second is most honest about it being a working test. The third is the most CEL-pure but loses the editorial feel.
Layout breakdown (column grid)
Reading the screenshot's proportions:
| col 1 | col 2 |    col 3    |    col 4    |    col 5    |    col 6    | bleed |
|  ~5%  |  ~13% |    ~14%     |    ~20%     |    ~16%     |    ~18%     |  ~14% |
Roughly. The right-hand bleed (the plant photo) suggests the metadata grid actually runs 6 columns within a 7-column overall layout, with the seventh reserved for a hero image / bleed area. On the test page the bleed could be left as negative space or carry a token-swap chip (a small visual that flips on mode change).
If you're working in Lumos or Webflow's grid: a 12-col container with 1-1-2-3-2-2-1 spans matches it cleanly, or 6 equal cols if you drop the bleed.
Recommended next move

Confirm Read 1 vs Read 2 (page-level vs component-level dossier).
Confirm col 3 framing — Test no., Version, or Slug.
I draft this as a CEL-named component spec (page-header__col, page-header__rule, page-header__label, page-header__value) ready for you to build in Webflow.

Once those two judgements are made, the rest is mechanical and I can produce the spec, the class stack, and the data attributes in one pass.

VERSION:

v0.1

draft

Test no.

2026l

1/n

SURFACE:

hux.works

/systems/light-mode-test

SUBJECT:

TOKEN SWAP;

SURFACE COHERENCE

AUTHOR AND DATE:

HAMISH DUNCAN

09.05.26

Dark mode

How the architectures move between tools

Same component. Same spec. Three operators — designer, developer, agent — all reading from the same source.

CLAUDE MCP

ACT, TASK OR SPEC prompts

FIGMA

Visual of the design system

VS CODE / CURSOR / GITHUB

Codebase edits and deployment

NOTION

Documentation, change log and version control

Webflow

Articles, portfolio, live playground and marketing

CEL is the contract layer

CEL* — Context · Element · Layer — is the naming methodology that turns a class name into a contract. It scopes the component, names the part by role rather than tag, and declares the variant as a layer. Three parts maximum. Lowercase. No nesting.

card

context only

card__title

context + element

card__title--featured

context + element + layer

card--dark

context + layer (no element)

*
CEL is a separate methodology with its own page.

Read the CEL Methodology

From spec to instance, in four steps

The mechanical part. Each step is a discrete handover, and each one fails loudly if the spec is silent.

STEP 01 - Connect

Connect Figma and Webflow to their MCP servers. The Designer tab stays foregrounded — close it and the connection drops. Test with a simple call before doing anything structural.

Step 02 — Resolve

The agent reads the brief and resolves it against the system. Featured card with dark theme should map to card cc-featured u-mode-dark without clarification. If it does not, the spec has a gap — fix the spec, not the prompt.

Step 03 — Instantiate

The agent creates the element. Batches of two or three at a time — larger batches time out. The element inherits the component's classes, attributes, and structure as defined by the spec.

Step 04 — Verify

Inspect the result in the Designer. Check the class stack, the data attributes, and the visual against the Figma source. Anything missing is a spec problem, not a generation problem.

Known limits, current as of v1.0

Six or more element creations may time out

Use batches of two or three. The connection holds; the request payload is the bottleneck. If a section needs ten elements, plan four sequential calls, not one.

The Designer tab must stay foregrounded

Switch to another tab and the WebSocket connection drops without warning. Keep the Designer visible during any agent run. Use a second screen if you need to read documentation simultaneously.

Elements cannot be moved

Restructuring requires creating a new element in the correct position and deleting the old one. Plan structure before instantiation; reordering after is twice the work.

Binary asset upload is unsupported

Images, fonts, and other binary assets cannot be uploaded through the MCP. Upload manually via the Designer asset panel, then reference the asset by its existing ID in subsequent calls.

All flow.
No friction.

hamish@hux.works
+44 (0)7832 839 543