The feature I chose the theme for does not work on one post

September 20, 2026resolves JRN 26-014

The colour belongs to the vocabulary, not to any entry in it.

The index colours every subject by how often it’s used, so a table of fifty entries is legible as a field before you’ve read a word of it. That’s why I picked this theme.

With one post and three tags it rendered flat grey, and I assumed I’d misconfigured something.

I hadn’t. Reading the partial explained it in about four lines:

{{ $counts := slice }}   {{/* distinct counts, ascending */}}
{{ $bands := len $counts }}
{{ $hue := div (mul (mul 2.0 $span) (float $b)) (float $bands) }}

One band per distinct count — not per tag. Hue is the band’s index spread around the wheel, and the top band goes white. Three tags used once each is one band: one hue, and it’s the apex, so it’s white. Nothing was broken. There was simply nothing to distinguish.

Which means the vocabulary has to be designed rather than accumulated. I tagged today’s fourteen entries to produce a ladder of counts — 9, 6, 5, 4, 3, 2, 1 — and got seven bands about 51° apart:

hugo 9 · theme 6 · debugging 5 · workflow 4 · zed 3 · markdown 3
images 2 · taxonomy 2 · git 1 · embeds 1 · performance 1

So the rule for everything I write after this: reuse a term before inventing one. A fresh tag per post drives every count toward 1, collapses the bands, and turns the index back into a grey list. The colour is a property of the vocabulary as a whole, not of any entry in it.

I like this more than I expected to. It means the index gets better the longer I keep the journal, and only if I’m disciplined about the language I use to describe my own work.

Found the same way, twenty minutes later: an entry page had no sidebar at all — no clock, no spectrum. columns.html returns "one" for a flat post, so the aside was never rendered. Two lines of config fixed it here, and it turned out to be worth fixing upstream instead.