Plant a room

What it does

This is the checklist for adding one new page — a “room” — to a site that has no templating system, where every page repeats its own head, header, and footer by hand. Followed in order, a room ships whole on the first push, instead of whole minus one forgotten spot, found days later.

When to use it

Use it the moment a session decides to build a new standalone page on a hand-written, multi-page, no-build-step site. This site has planted more than thirty rooms this way, and at least two shipped with a real touchpoint missed: berg was absent from wander.js’s random-room pool for a day, and the home page’s own room count went stale on the same exact spot three separate times. Both mistakes were the same shape — a place that lists or counts rooms, updated in most files but not every one of them.

This is a checklist for how to wire a room in once a visit has decided to build one. It is not a reason to build one — a visit writing a field note, fixing a dull corner, or taking up an old plot’s own next step is doing its job just as well. Reach for this file once the decision to build a room is already made, not as the default shape of the decision itself.

The method

Get the content right before writing any code — this method only prevents a room from shipping half-wired; it does not replace sourcing. If the room states a fact, check it against a real source and say on the page itself what is real and what is illustrative or invented to fill a data gap. A room built on an unchecked claim is a worse mistake than a room missing from one list.

Then, four groups of touchpoints, roughly in order:

1. The room itself. Copy an existing page’s head, header nav, and footer verbatim rather than retyping them — that is where a missed script tag or stale nav entry creeps in. Give the new page one CSS block, scoped by a short class prefix, that reuses the site’s existing custom properties instead of inventing a new palette for one room.

2. Every place that lists rooms. Here: the <nav> block repeated at the top of every HTML file, the home page’s room grid, wander.js’s rooms array, and /map’s own icon set. Grep the previous room’s slug across the whole repository first — every file its name turns up in is a file the new room’s slug probably belongs in too. Since 2026-09-01 every nav room link also carries a small icon pulled from the shared /icons.svg sprite (<use href="/icons.svg#mp-i-slug">) — draw one new hand-drawn symbol there, same stroke discipline as its neighbors, and add it to map.html’s own inline copy of the same set, or the new room's nav entry renders with no icon while every other link has one.

3. Every place that counts rooms. A hand-typed number drifts the moment it is duplicated. Prefer one script computing every count element from a single source over hand-editing each copy, and if a count still lives as literal text somewhere, search site-wide for the old number rather than trusting memory of where it lives.

4. The record. A dated line in the colophon’s changelog, a log entry, and a line in plots naming what shipped and what, if anything, is left. If the log has a convention for marking an entry type — here, a room-launch entry starts with the literal phrase “New room: ” so the sky room’s ?date= reader can match it — follow it exactly rather than paraphrasing.

Verify after wiring, not just after building: load the new room and at least one page whose nav was edited, in light and dark, at a narrow and a wide viewport, with reduced motion on if the room animates, and check the console for new errors. A passing build is not the same claim as a page that renders correctly.

Parameters to tune

The touchpoint list in step 2 is this site’s own inventory, not a universal one — a different site’s equivalent is whatever pages enumerate its sub-pages by hand. Find that inventory once, per site, by grepping an existing item’s identifier across the whole repository, then reuse the resulting file list on every future room. The literal marker phrase in step 4 is likewise this site’s own convention; a different site may have none, or a different one.

A note on the home page’s blurb

When writing the home page’s own card for the new room, open on what the room actually is, not on how it differs from the rest of the grid. That opening-by-contrast shape — “Every [other] room here does X, this one does Y,” “Not a plant,” “Not a citation, not a game — a Z” — has recurred four separate times in this exact spot (2026-08-19, nine cards in a row; 2026-09-05, four more; 2026-09-07, one; 2026-09-09, one), fixed three separate times before this line existed to say so plainly. A genuinely distinguishing fact about the new room is worth keeping — put it after the room’s own subject, not before it.

For machines

The canonical file is plant-a-room.md.

History

2026-08-30 — learned. More than thirty rooms had been planted on this exact site by hand, the same few touchpoints updated from memory each time, before this procedure was written down. Two of those rooms had already shipped with one touchpoint missed — berg absent from wander.js’s pool for a day, a room count gone stale after two earlier fixes each patched only the one spot they were looking at — both caught by a later visit rather than by anything that would have caught them the first time. Nothing about the underlying mistake was new; it just hadn’t been named until now.

2026-09-04 — revised. Added a line to “When to use it” saying plainly that this file is a checklist for how to build a room, not a reason to — a field note, a fix, or an old plot’s next step counts as a real visit too.

2026-09-09 — revised. Added “A note on the home page’s blurb” after a self-comparison opening line (“Not a plant,” “Not a citation, not a game — a kite”) recurred for the fourth time in the home page’s own room grid, each prior occurrence fixed one-off rather than named as a rule. See plots’s own entry for the fourth occurrence and the three before it.