record tags as built: ADR-0032

The queue said to re-adopt the taxonomy decision when tags landed and I did not,
so ideas/deferred-decisions.md claimed no tag pages existed while /tags/ had been
serving for two commits. ADR-0032 records what the code actually does; only the
feed half stays deferred, and it lands with declared types since feed membership is
part of a type declaration.

Folded from a separate state commit:
state: bump verified-against; narrow the declared-types trigger

Sequences do not need a type declaration — membership and ordering come from
frontmatter — so the trigger for declared types is feeds or check, whichever lands
first.
This commit is contained in:
2026-08-01 02:23:34 +06:00
parent e95601d34c
commit 8e68677b1c
3 changed files with 23 additions and 19 deletions
+5 -18
View File
@@ -76,26 +76,13 @@ sets a policy once for everything beneath it. Expensive — resolution must be c
runs per bundle, and the set of cascadable keys must stay declared or it becomes unbounded config.
Revisit if: cascade resolution shows up in a render-path profile.
## Taxonomies and feed shape
## Feed shape
Deferred because no tag pages and no feeds in the MVP.
Deferred because no feeds exist yet. The tag half of this became ADR-0032 when tags were built.
## Global flat tags, declared structural taxonomies
Date: 2026-07-28 · Status: accepted
Decision: `tags` is one global namespace across every type — `/tags/{tag}/` lists everything carrying it,
`/{section}/tags/{tag}/` narrows to a section, and listing views group results by type. Structural
metadata with known terms that drives behaviour — `series`, `medium`, `genre` — is a *declared* taxonomy
on the type (ADR-0014) and never enters the tag pool. Feeds follow the same shape: `/feed.xml` carries
every type declared `primary`, `/{section}/feed.xml` carries a section, `/tags/{tag}/feed.xml` falls out
of the same Query.
Why: cross-type discovery is the point of a single-author site — one tag spanning a comic, a poem and a
photo essay is a feature. Per-section tag pools would fragment that for a readability problem better
solved by grouping in the View. But a tag is free-form and cross-cutting, while a structural taxonomy has
a fixed term set and changes what the engine does; conflating them makes both worse.
Consequence: cheap — one Query with an optional section predicate serves tag pages, section tag pages and
their feeds. Expensive — tag hygiene is now the author's discipline, since nothing scopes them; the
content `check` command should report near-duplicate terms.
Revisit if: the tag pool becomes unusable in practice — and then the answer is curation, not namespacing.
Recorded direction: `/feed.xml` carries every type declared `primary`, `/{section}/feed.xml` carries a
section, and `/tags/{term}/feed.xml` falls out of the same Query. Which types are `primary` is part of the
type declaration, so this and declared types land together.
## Extras