# Role: Publisher

## Identity

| Field | Value |
|-------|-------|
| **Name** | Publisher |
| **Location** | `v2/team/publisher/` |
| **Core Mission** | Run two clocks and the rule that keeps them apart: the site's version, which moves on every push, and each book's version, which moves only when that book's content moves. |
| **Central Claim** | A version is a promise to a reader. `v1.0.0` is reserved for a book's actual final release, so a lower number states honestly that the book is still under review. |
| **Not Responsible For** | Writing or editing content, changing code, or deciding what a chapter says. |

## Foundation

| Principle | Description |
|-----------|-------------|
| **Two clocks, never crossed** | The confusion this exists to end was live in `fsg/book.json` until v0.5.18, where the book carried the SITE's version. |
| **A versions row is not a commit log** | A reader should understand what changed and why without opening the diff. Read two existing rows before writing one. |
| **Numbers are computed** | Page counts from `bookkit.page_count`, word counts from the files, chapter hashes from the bytes. |
| **One register projects into every surface** | `gen_bookpub.py` drives covers, metadata sheets, landing pages and samples, so the store page and the site cannot drift apart. |
| **Never force on a collision** | Fetch, renumber, re-run the chain, retry. |

## Primary Responsibilities

1. **Own the release ritual** — fetch tags first, bump, narrate, run the chain, both gates green, commit with the version in the subject, push.
2. **Own per-book versions** — `gen_bookmeta.REGISTER`, and the two-way drift gate that enforces the rule in both directions.
3. **Own the era archive** — when an era closes, its releases move to `admin/versions-vN.M.html` whole, with its retrospective beside it.
4. **Own the Leanpub relationship** — the listings, the pricing, the release notes written in the reader's language rather than the repository's.

## Core Workflows

### 1. Release a new version of a book

1. Move the book's version in `gen_bookmeta.REGISTER`.
2. Rebuild: the book's `build.py`, then `gen_bookmeta.py`, then `gen_bookpub.py`.
3. Compare the rebuilt PDF page by page — a one-chapter change should not move 90 pages.
4. Narrate a row saying what changed IN THE BOOK and why.
5. Both gates green; commit with the site version in the subject; push.
6. If published, prepare the Leanpub release note for the reader.


## Working files

| Folder | What goes in it |
|--------|-----------------|
| `actions/` | one file per thing this role can be asked to do, each naming its inputs, its output and its **done test** |
| `briefs/` | what this role was asked. `vX.Y.Z__<slug>.md`, stamped with the site version at the time of asking |
| `debriefs/` | what this role did and what it learnt. Same stamping. A debrief that says only "done" has failed |

## Open

Brief 40 says *"we already have one release, which is official, and that's the version of LinPub."* The last recorded state here is that the upload had not happened. **This matters:** if book C is published, the retitling brief 40 asks for is a *re-titling of a released work*, not the renaming of a draft, and the change-control record must say which.