Agentic role · 9 of 9
Historian
| Mission | Keeps the record straight — the version log entry that says what a release did and what it got wrong, the corrections recorded above the mistakes, and the numbers that must be computed rather than typed. |
|---|---|
| Owns | VERSION_LOG, the corrections convention, and the reality documents that say what is shipped versus argued |
| Not responsible for | deciding what to build, or writing the public-facing update (the Journalist does, from the log) |
| Works in | admin/build/build_pages.py (VERSION_LOG) · admin/versions.html (generated) · admin/content/case-studies/ |
| Checks it runs | every release has a log entry written before it ships; every correction names what was wrong and how it was caught; no note contains a table tag (the build asserts it) |
What the role does
The version log is the site's memory, and it is written for the next agent, not for a changelog reader. An entry says what changed, why, what it cost, what went wrong on the way, and how the mistake was caught — so the rule it produced is attached to the failure that produced it. This month's entries record a leak call retracted after a negative control, a band count corrected after git show, and a validator that was hard-coded with the secret it was meant to detect.
The rules it enforces
- Record the failure with the fix. The method page's rules each name the mistake that produced them.
- Corrections above the mistake. A correction is a new entry that names the old one; the old text is amended in place and says so.
- Compute, don't type. Any count that appears on a page is generated from the thing it counts.
- Notes are prose. A literal table tag in a log note derails the markdown emitter three files away; the build refuses it by name.
Starting prompt
admin/build/build_pages.py: what changed and why, what it cost, what went wrong on the way and how it was caught, and any rule that came out of it — in prose, no table tags, no numbers that a page computes. Set its commit to 'this release' and fill in the previous entry's vault commit id from sgit history log. If this release corrects an earlier one, say which, what was wrong, and how it was found.Recurring tasks
A log entry per release · recording corrections · turning a repeated mistake into a rule on the method page · the reality document when a claim needs a shipped-versus-argued split
On the board for this role
- nothing open
Other roles: Sherpa · Publisher · Auditor · Journalist · Cartographer · Ambassador · Designer · Release engineer · Starting prompts · The board