The paragraph — mechanics

Reading the page is the standard route; asking the line at its foot re-weights it instead of opening another page, so the mind always speaks on the wiring's site surface.

The fork in this look

The first second needs no input: the replay types a question, sweeps and lays the scrap. Its answer is precomputed per snapshot version, so arrival costs no model call, and "Someone asked" must be a real counted question.

The first interaction is a verb in the fork sentence. "Read on" is underlined at the text weight. "ask the line" wears the mind's block and focuses the rule with the replayed question selected, so the first keystroke replaces it.

Nothing navigates, so the view transition belongs to the answer: once it is final, if the reader has not scrolled, the question flies from the rule into its note's heading in 420 ms. The routes weigh differently: reading is static and changes nothing; asking costs a turn (about a cent warm) and re-weights the page until "clear".

The standard route

The nav is four anchors into one page, server-rendered from the snapshot. The agenda is four chapters, each opened by its initial; the speakers are the roster sentence; ticket phases are computed from the date, not the snapshot's flag. Three new sections give every component a home: partners as a sentence by tier, the eight FAQ, and contact in the colophon. Deep links are server-rendered states: /lineup/venkat-tirupati opens that name with its scrap and a note holding title, bio and sessions.

Asking the mind

The rule becomes a real <form> posting to /ask, working without script, instead of today's contenteditable span.

Thinking is the material letting go: on Enter every name drops to wght 400 and the blocks lift, since nobody is chosen yet. When the first component arrives, a 1 px line crosses the screen in 900 ms and the answer's names take the block as it passes. done reverts provisional names and restores full weight when the answer names nobody; a failed turn restores the old weights and writes no note.

Components render as prose; chosen records wrap in <mark>:

• Text: say (45 words at most) streams ragged into the note and is justified when final. The renderer writes the lede sentence ("twenty-eight names now stand in white…") from ids and counts, so it cannot invent. faq prints Zpryme's answer under its question in bold.
• Speakers: speaker_grid names stand in white wherever they occur, and the note lists them. speaker_card hangs a scrap only for a real portrait.
• Sessions: one sentence each in the note; their mono times take the block inside the days.
• Agenda day: the day's chapter is the answer, its names chosen (all 28 on Tuesday, or one track's).
• Venue and tickets: facts, prices, phase dates, refund policy and Eventbrite link come from data; "venue soon" and the prices take the block.
• Choices: the rule's right-hand sentence on desktop, the note's last line on phones.
• Sources: a renderer-built footnote from sources, snapshot date, counts, sample marker and a fixed clause per coverage.
• Fallbacks: not_in_snapshot and off_topic still write a note; error codes print one line on the rule. With the proxy down or the budget spent, the mockup's matcher answers from the page's index and says so.

The assistant in the chrome

The composer is the bottom edge: "ask", the line at 44 px and the block caret. There is no card to park; the scrap is the only object the mind lays down. While the mind writes, the rule's right end shows "stop" and a mono word count, then "note 02 · back to Tuesday 13:30". The colophon's state line holds snapshot version, counts, sample marker and switches for motion, counting and shortcuts. Counting stores answer signatures (component types and ids), never visitor text.

Data, performance and accessibility

The fixture drives all of this (77 people, 50 sessions, prices, FAQ, sample flags), and its gaps show: 18 people lack a portrait, Sam Chang has a Whova default avatar, and there are 36 bios, 3 session descriptions and no rooms. Beyond the brief's list, WordPress and Whova must add sort and display names, short organisation names and session titles, mirrored portraits with a crop focus, real ETS27 themes, sponsor names and one phase-2 start date (19 or 20 November).

Motion budget: one sweep per answer across the visible screen, moved with transform. The mockup's whole-page top sweep crosses a screen mid-page in 40 to 75 ms. Weights snap, names out of view change in one frame, and frames stay under 16 ms on a mid-range phone. Preload a self-hosted Mozilla Headline: a late font re-justifies everything.

Reduced motion skips replay, sweep and transition. The 187 names are 187 Tab stops today; each paragraph should be one, with arrow keys between names and Escape to stop a turn. Add an h1, running heads as headings, and one polite status region that announces the lede sentence, never tokens.

Build plan

Carries over: all of server.py (SSE events, scanner, sanitizer, sessions, guards, budget, self-test); the fixture and builder; the catalogue, grown to the brief's ten plus coverage; the renderer logic of mind.html and standard.html (stream reader, timers, reconcile-by-position, error table, offline mode) but not its cards; and the mockup's CSS, tear, scrap placement, templates and matcher.

New: a paragraph generator and sentence renderer shared by server and browser, the weight states and sweep, the transition, the keyboard model, URL states and arrival precompute. About four weeks for one front-end developer, beside the brief's shared phase-4 engine.

Risks

• Latency: first words take 1.2 to 3.1 s and answers up to 6.5 s, so the reading state must hold calmly until the 8-second watchdog.
• Reflow: wider bold names and unbreakable blocks move lines under the reader on every answer; scroll anchoring must hold.
• An ETS26-sized lineup (147) doubles the roster and these costs.