"Nobody designed the frontmatter"

I open any file in these repos in VS Code, and before the first heading the Outline panel shows a block of names: title, numero, date, sesion_fuente, fecha_creacion, description, tags, destacado, slug. This post carries those nine at the top, and will gain a tenth once it's published. Yesterday I asked myself who decided each one. Short answer: nobody, all at once.

That block is the frontmatter: a few key: value lines between two --- at the top of a Markdown file. It isn't part of the text; it's what the file says about itself — title, date, tags, where it came from — in a format a script can read without understanding the prose. Nobody writes it from scratch: every file type has a template with the block already built and the values empty, and whoever creates the file copies it and fills it in; some fields get filled in later by a script — the hook that closes a session, the step that publishes a note. It's there so the site can order the notes, so a hook can fill in dates, so a radar can cross sessions against notes already published. And it's there, above all, for as long as someone reads it.

Four cradles

Tracing the origin took an afternoon: seven families of fields, born in four places. The sessions one — alias, fecha_inicio, estado — was born on August 16 in another project, when two sessions in a row settled how to name and pick a work session. Six days later, in the template I use to spin up projects, a two-field classification was born, domain and type, with a closed vocabulary, to tag rules, agents, tickets, and decisions alike. The third cradle is this project: between September 3 and 15, across five rounds, the fields that identify a note. The fourth, on the 11th: the English version, in a separate file with its own block.

What traveled and what didn't

Each family travels by a different mechanism, and none of them is all-or-nothing: the initial scaffold copies everything; the sync only updates agents, rules, and scripts; a hook fills in a handful of fields when each session closes. The result: of the tickets in a project prior to the classification, 1 out of 84 has it; in a later one, 178 out of 178; here, where it was born, 48 out of 215. And no script reads those two fields at all: the rule that defines them calls them, literally, "metadata".

The second gap is stranger. The same hook, when registering a new session, fills in its identifier with a regular expression; since that field starts out empty, it also swallows the next line — the start-date one. 254 out of 260 sessions in one project were born without it, and nobody noticed until another script had to infer it from the file name.

What holds up

The four fields that identify a note — slug, numero, fecha_creacion, tags — have what the classification never did: a reader that fails loudly. The build breaks if one is missing. And a piece's publication status isn't stored: it's recalculated every time it's queried. Less convenient, impossible to drift out of sync. A field doesn't survive because of the intent it was created with, but because someone, or something, still reads it.

Nobody designed the block above end to end: it has the shape of its own history. Of the ones heading your files, how many do you know who wrote, and how many do you know someone still reads?