QEP-1 v3: stamp from v0; drop the decision deadline; generate the index

AGENTS.md

@@ -39,9 +39,9 @@ table from frontmatter whatever the resolution did to it.
 
 ## Accepting a QEP
 
-When a QEP reaches a decision (see QEP-1 for the lazy-consensus rule), apply the outcome
-in a **single PR**. The status lives in **two places in the document** — keep them in
-sync:
+When a QEP reaches a decision (QEP-1: no objection outstanding, and an approving review
+from a Core Maintainer other than the author), apply the outcome in a **single PR**. The
+status lives in **two places in the document** — keep them in sync:
 
 1. the YAML frontmatter `status:` field, and
 2. the **Status** row in the in-document header table.
@@ -64,8 +64,9 @@ that state. QEP-3 did, for two months.
 
 Copy [`qeps/template.md`](qeps/template.md) to `qeps/qep-XXXX-slug.md`, fill it in with
 **Status: Draft** and a discussion link, and open a PR. **Do not add a README index
-row** — it is generated from the frontmatter when the PR merges. A new QEP is unversioned
-(implicitly v0): omit the `version` field. See QEP-1 for the full process.
+row** — it is generated from the frontmatter when the PR merges. Omit the `version`
+field: CI stamps `version: 0` and `version-hash` at the merge that records the outcome
+(QEP-1 v3; the stamp change is tracked in #22). See QEP-1 for the full process.
 
 ## Amending an accepted QEP
 
@@ -97,8 +98,11 @@ it to consumers you have never heard of.
 
 - **Substantive** (any change to normative content — a rule, a value, a table row, a
   machine-readable appendix): increment `version` by one in **both** the frontmatter and
-  the header table. The first amendment introduces `version: 1` and adds a **Version**
-  row to the header table; the README `Version` column moves from `–` to `v{N}`.
+  the header table. The first amendment moves the stamped `version: 0` to `1` and adds a
+  **Version** row to the header table — a v0 QEP has no such row, because the stamp
+  writes frontmatter only. The README `Version` column is generated. A substantive
+  amendment is accepted the same way as a new QEP (a second reader who is not the
+  author); an editorial change needs no second reader.
 - **Editorial** (no change to normative content — typo, wording, formatting, link):
   leave `version` unchanged.
 
@@ -118,13 +122,15 @@ GitHub UI choose **Squash and merge**.
 
 ## What CI does (don't do these by hand)
 
-- **Post-merge** — [`stamp-version.yml`](.github/workflows/stamp-version.yml) stamps the
-  merged short hash into the `version-hash` field and **regenerates the whole README
+- **Post-merge** — [`stamp-version.yml`](.github/workflows/stamp-version.yml) stamps
+  `version: 0` into any QEP that has left Draft and carries no `version`, stamps the
+  merged short hash into the `version-hash` field, and **regenerates the whole README
   index** from each QEP's frontmatter, ordered by number.
 - **On every PR** — [`qep-checks.yml`](.github/workflows/qep-checks.yml) checks that
-  `version` moves legally (a new QEP starts unversioned; a versioned QEP stays versioned;
-  the number stays the same or increases by exactly one), that `type` and `status` are
-  known values, that `related:` and the header table's **Related** row agree, and that
+  `version` moves legally (a new QEP arrives unversioned in its PR and is stamped `v0`
+  at merge; a versioned QEP stays versioned; the number stays the same or increases by
+  exactly one), that `type` and `status` are known values, that `related:` and the
+  header table's **Related** row agree, and that
   **ordered-list markers ascend in source** (see below). A stale README index is a
   warning, not a failure.
 

README.md

@@ -14,25 +14,27 @@ need a QEP.
 
 | QEP | Title | Type | Status | Version |
 |-----|-------|------|--------|---------|
-| [QEP-1](qeps/qep-0001-purpose-and-process.md) | QEP Purpose and Process | process | Accepted | v2 |
+| [QEP-1](qeps/qep-0001-purpose-and-process.md) | QEP Purpose and Process | process | Accepted | v3 |
 | [QEP-2](qeps/qep-0002-standard-github-labels.md) | Standard GitHub Label Set and Labelling Policy | standard | Accepted | – |
 | [QEP-3](qeps/qep-0003-repository-naming-and-types.md) | Repository Naming and Types | standard | Accepted | – |
 
 QEPs that set an ongoing rule are **maintained in place**: a substantive amendment bumps
 the QEP's `version` (shown above) under the same review process, rather than superseding
 the whole document — see **QEP-1**. The index table is **generated** from each QEP's
 frontmatter after merge — do not hand-edit it; `version-hash` is stamped at the same time.
-`Version` reads `–` until a QEP is first amended.
+`Version` shows `v{N}` from `v0` up; a `–` marks a QEP the stamp has not reached yet
+(see QEP-1's *Adoption*).
 
 ## Proposing a QEP
 
 1. **Float the idea.** Open a [QEP discussion issue](../../issues/new/choose) to
    socialise it and confirm it needs a QEP.
 2. **Draft it.** Copy [`qeps/template.md`](qeps/template.md) to
    `qeps/qep-XXXX-short-slug.md`, fill it in with **Status: Draft**, and open a PR.
-3. **Set a deadline.** Announce the PR and give a comment window (1–2 weeks).
-4. **Decide.** At the deadline the Core Maintainers decide by lazy consensus; the
-   QEP is merged recording the outcome (Accepted / Rejected / Withdrawn).
+   The index row above is generated at merge — do not add one.
+3. **Decide.** A Core Maintainer other than the author approves it once it has been
+   announced and no objection is outstanding — nobody accepts their own QEP; the QEP is
+   merged recording the outcome (Accepted / Rejected / Withdrawn).
 
 The process itself is defined in **QEP-1**.