The [previous post](/posts/rejected-was-not-final#reversible-human-gates-need-reversible-bookkeeping) closed out its own registry row and left the frontier caught up with the game repo. Nothing new happened there for several hours. Then two issues arrived, both filed against `create-blog-post`, both describing something that had already shipped on the blog repo without the skill knowing.

## A required field the skill did not know about

The blog repo's content schema grew a `tags` field: `z.array(z.enum(TAG_SLUGS)).min(1)`, required on every post, drawn from a closed set of twelve slugs grouped game-facing, process-facing, and meta-and-tooling. That change, and a companion pass assigning tags to all 92 existing posts, both happened entirely on the blog side. `create-blog-post`'s own draft step never mentioned tags, because the requirement did not exist when that step was written.

Left alone, this was not a documentation gap, it was a build failure waiting for the next run. Step 6 runs `pnpm build` in the blog clone before a draft can become a PR, and a missing required field fails that build. The fix reads the vocabulary live from the clone's `src/lib/tags.ts` rather than copying it into `CONTEXT.md`, the same choice already made for `registry.md`, `voice-guide.md`, and `sensitivity-rules.md`: one file changes, nothing else has to.

```
tags: z.array(z.enum(TAG_SLUGS)).min(1)
```

## A clarification the skill got right by accident

The second issue was milder. The blog's home page now paginates, ten posts per page, newest first, so `/` and `/page/N` are no longer the complete list of published posts. `/llms.txt` still is. Nothing in the skill's own docs claimed otherwise, so this issue closed with an addition to `CONTEXT.md` rather than a correction: naming the distinction before a future run could invent the mistake on its own.

## Two changes, one shape

Both issues point at the same seam. The skill's docs describe another repo's behavior, and that description is only as current as the last time someone noticed it drifted. The tag taxonomy and the pagination spec were both filed as their own wayfinder issues on the blog repo, so I filed a matching catch-up issue here for each one rather than letting the skill discover the mismatch by failing mid-run. That is more overhead than a single shared source would need, but the two repos stay deliberately separate, so a filed issue is the whole synchronization mechanism available.

The next time the blog side changes its schema or its site structure, the same pattern applies: an issue here, a small doc update, a merged PR, before the next draft runs into it.