--- number: 3 title: This website date: 2026-07-29 summary: The site itself, as this week's deliverable — and the principle it's built to demonstrate: the repo is the source of truth, the site is just a rendering of it. epic: public-site-and-comms status: delivered due-with: null artifacts: ["site/","epics/","deliverables/"] cta: [object Object] --- This week's deliverable is unusual: it's the thing you're reading right now. ## The principle: the repo is the source of truth Every page on this site that has real content — every project on the [board](/projects), every entry in this [deliverables log](/deliverables), the whole [codex](/codex) — is generated from plain markdown files that live in this workspace's git repository, not from anything typed into a CMS or database. `projects/naming-and-brand/overview.md` and this very file, `deliverables/003-this-website.md`, are the actual, complete source data. The site build reads them directly (via Astro's content collections, pointed straight at `../projects` and `../deliverables`) and renders them. Nothing is copy-pasted into a `site/` folder and allowed to drift out of sync with the real files — there's only one copy of any piece of content, and it lives at the repo root, not inside the site. Why this matters enough to be deliverable #3: it means anyone — a human collaborator, or an AI agent picking up work — can understand the state of the project by reading files in a folder, with no dashboard, no login, and no tool more sophisticated than a text editor. The website is a convenience layer for humans who'd rather click than `grep`. It is not where the truth lives. ## The project mechanism this site renders Alongside the site, this week's work also stood up [`projects/`](/projects) — a lightweight, filesystem-based alternative to an issue tracker. Ten epics exist right now, each as a folder with exactly two files: `overview.md` (what it is, why, scope, open questions) and `status.md` (state, and the single next action). No GitHub Issues, no ticketing tool — just files with YAML frontmatter, readable by grep and by eye. That mechanism was designed agent-first on purpose. `projects/README.md` is written as instructions *to an agent*: how to find work tagged `agent-ready`, what to read before touching anything, and — the one hard rule — never to silently act on an epic tagged `needs-human-decision` (two of the ten currently are: naming the game, and specifying how ground and traversal actually work). The site's [`/projects/index.json`](/projects/index.json) is the same information as a single machine-readable fetch, so an agent doesn't even need to walk the filesystem to find what's open. ## Built to be read by agents, not just people A few things on this site exist specifically so an AI agent — not a human with a browser — can make sense of it in one request: - [`/llms.txt`](/llms.txt) at the root, summarising the site and linking every key markdown source. - Every content page also available as raw markdown at `.md` — no HTML parsing required. - `/projects/index.json`, a flat dump of every epic's frontmatter. None of this is aimed at search engines. It's aimed at the fact that this project is, itself, substantially built and maintained *by* AI agents working from these files — so the site had better be legible to the same kind of reader that's doing the work. ## What's genuinely new here vs. what already existed The weekly-deliverable habit itself isn't new — Kris has been sharing something with a friend, Travis, most weeks already. What's new is making that habit public, and building the mechanism (the site, the project board, the brand token file that lets the game's name change without breaking anything) that makes "public" sustainable rather than a one-off blog post. The bet is the same one the game itself makes: a small, well-chosen, learnable structure, applied consistently, beats a bigger pile of ad-hoc content every time.