Nickipedia is the artefact. The essay is the reflection. This page is the artefact’s documentation, kept short on purpose; the essay is where the lessons live.
What it is
A Hugo static site with a custom Wikipedia Vector skin, deployed via Firebase Hosting. 242 entities (NPCs, locations, items, sessions, factions, deities, magic items, open mysteries, party members) across 17 session recaps. Per-entity portraits where the content earns one. A calendar, a search index, an open-threads tracker.
Every page is built from a markdown source in a folder structure that maps the campaign world: 04_npcs/, 05_locations/, 07_items/, 08_quests/, 09_mysteries/. Each file has YAML frontmatter (status, aliases, first_seen, last_seen, sources with line-numbered transcript citations), a wiki_summary block that renders as the page lede, and a body in Obsidian-style [[wikilink]] syntax.
Every claim in the body has to map back to a sources: entry. Every sources: entry is a line range in a normalised transcript. The validator checks both.
The pipeline
When a new session lands:
- Whisper transcribes the audio.
- The transcript is normalised into a stable line-numbered format.
- Six parallel extraction agents are dispatched against the transcript, each scoped to one extraction goal (NPCs, locations, items, combats, dialogue, world-state). Each agent grep-verifies its own citations as it writes.
- A seventh sequential pass cross-checks the merged draft.
- A synthesis pass writes the session recap from the union of the agents’ outputs, not from the transcript directly.
- A derived-page sweep updates affected entity pages, fills in any new redlinks as stubs, and runs the canonical-name register to catch Whisper-variant spellings.
- A build pass runs Hugo into a non-Drive cache directory, validates every blockquote and citation against the transcript, and fails the build if anything is out of range.
- A deploy pass pushes 2,267 files to Firebase Hosting in one shot.
Cowork makes it autonomous
The whole pipeline above runs unattended on a Cowork scheduled task, every Friday morning. The task is configured once; it reads the contract files (maintenance_contract.md, wiki_pipeline.md, scheduled_task_contract.md, the canonical-names register) on every run; the prompt is a few hundred words and the contract is a few thousand. The agent reads the contract.
That makes it a system that behaves like an institution. New conventions get added to the contract, not asserted into the prompt. The validators are the probe. The two together are what let a one-line “run the pipeline” invocation be trusted against a corpus that compounds.
The DM corrections wave
Once the wiki was live, the DM gave me a 70-item correction list across renames, identity fixes, player-safe softenings, and removals. The corrections wave was applied in four phases by parallel agents (renames sequential within itself because file moves and wikilink updates conflict; the rest in parallel). The whole correction wave took about an hour of wall time. The 60-line changelog and five new rules added to the maintenance contract are now load-bearing for the next pipeline run.
Why this is here
This is a pet project on the outside. On the inside it’s the compression gap in miniature: four hours to a working wiki, forty hours of the part that doesn’t compress (citation discipline, name canonicalisation, the multi-pass extraction so future-me doesn’t trust a single read, the scheduled task so the maintenance becomes someone else’s problem). Every component is transferable to any structured transcript corpus that needs to settle into canon.
The longer write-up is where this turns into an argument about what Cowork can do for the durable parts of vibe-coding, not just the fast parts.