# Corrections and updates, derived rather than remembered

Status: parked
Raised: 2026-08-02

A post that has been corrected should say so. The question is who remembers.

## Why the obvious version was rejected

The cheap shape is a frontmatter list — `corrections: [{date, note}]` — lifted by the parser and rendered
by the theme. It needs no engine history at all and could ship in an afternoon.

It was dropped for an authoring reason, not a technical one: **it puts the burden on the author to
remember, and a half-remembered list of corrections is worse than none.** A page carrying two entries
implies those were the only two, which is a stronger claim than the author can honestly make months later.
An absent list claims nothing; an incomplete one misleads. That asymmetry is what kills it.

## The shape worth waiting for

Derive it. The repository already knows what changed and when — that is what a content repo is for — so the
list should come from history rather than from memory.

This wants the **Effect** primitive: work off the request path, on content change or on a schedule
(ADR-0012), writing an artifact the render then reads. An Effect walking the content repo's history for a
bundle's path can produce a real, complete list of when that file changed, with commit subjects as the
notes.

## What has to be settled first

- **The engine does not read git today, deliberately.** `harness/content-model.md`: "The engine notices
  changes. It never fetches them — pulling a git repository is the operator's business." That sentence is
  about *pulling from a remote*, which is a different act from reading local history, but the distinction
  has never been decided and should not be assumed.
- **Reading history needs a dependency or a subprocess.** Either a Go git library — an ADR and an
  allowlist entry — or shelling out to `git`, which makes the binary's behaviour depend on a tool that may
  be absent in the container (ADR-0010 ships the binary alone).
- **Not every commit is a correction.** A typo fix, a reflow and a retitle are all commit subjects, and
  publishing them as corrections recreates the noise problem from the other direction. Something has to
  filter — a commit-message convention, a trailer, or a path-scoped rule — and that choice is the actual
  design work here.
- **The Effect runner does not exist yet.** The effects counter stands at 1, due at 2
  (`harness/state.md`), so this waits on that extraction regardless.

## Trigger

The Effect runner landing, plus a decision on whether the engine may read the content repo's local
history. Until both, this stays parked — and the manual version stays rejected rather than merely
unbuilt, so it is not reintroduced as an easy win.