Consolidating the project pages, and the YAML bug hiding underneath
Vault and the portfolio were never separate infrastructure, so their project pages became sections of The 5N3 Domain instead. Along the way: a project page with a blank title in the editor, traced to an unquoted colon that a hand-rolled parser never minded and a real YAML parser refused outright.
Six project pages became four. Two different decisions, and one of them exposed a bug that had been sitting in this repository since before Decap CMS existed.
Projects that were never separate infrastructure#
Vault had its own project page: its own card, its own entry in the sidebar, its own URL. So did the portfolio. Neither deserved it. Vaultwarden runs on the same VPS, the same Caddy instance and the same Postgres as every other product under this domain, and the portfolio is one more static site on that same system. A project page implies a thing with its own deployment, its own infrastructure, its own development log, and neither of these had that. They had a write-up.
So both write-ups moved. What Vault's page used to say about client-side encryption, the no-reset property, the closed signups and the tighter CSP is now a section on The 5N3 Domain's own page. Same for the portfolio: what it's built with, why it was restyled onto the shared design system, where the CV lives. The files are gone, the facts aren't. The actual services, vault.fiventhree.com and profile.fiventhree.com, are completely unaffected. Deleting a Blog write-up about a service and deleting the service are two different operations, and it is worth being precise about which one happened.
A page that kept losing its title#
Before any of that, something stranger was happening: the same three project pages kept disappearing from the Decap editor, in the same order, every time they were restored. That ruled out random misclicking fairly quickly, three accidents landing on the exact same three entries three times running is not an accident. It turned out to be deliberate: exactly the content decision above, made through the editor's own delete action before the reasoning behind it had been said out loud. Once that was clear, restoring from git history stopped being the fix, and merging the content properly was.
What was a real bug, underneath all of that: The 5N3 Domain's own project page stopped showing a title in the editor at all. Not missing, just a blank row where "The 5N3 Domain" should have been, while every other project loaded fine.
The cause was a single unquoted colon. The page's summary: field read "fiventhree.com and everything under it: home page, portfolio, this hub, the tracker and the vault", and in YAML, a colon followed by a space inside an unquoted value can open a new mapping key right there in the middle of a sentence. This repository's own build script never cared: it reads front matter with a small hand-rolled parser, written before Decap existed, that was never strict about this. Decap's editor uses a real YAML parser, and a real YAML parser is correct to refuse it.
Once that pattern was named, it was worth checking for elsewhere rather than trusting it was a one-off. Two more files had it: both older posts, both restored earlier in this same session after being deleted through the same editor, both with a bare colon in their own summary: field. All three got quoted; a sweep across every remaining post and project frontmatter found nothing else like it.
What actually makes a page safe to edit through a form#
The lesson is not "be careful with YAML." Front matter was always YAML; it just had exactly one reader before now, a parser lenient enough that the mistake was invisible for months. Adding a second, stricter reader is what turned a latent formatting slip into a visible failure. That is a trade worth making on purpose: a form that fails loudly on bad syntax is safer to hand to a non-technical future self than one that silently accepts whatever a lenient script was willing to forgive.