Tighten RFC template: add Draft/Superseded status, Consequences section, minimal index

[autholykos]

Summary

Three small improvements to the existing RFC convention at docs/rfcs/ that came up while aligning a sibling project's decision records to pituitary's template. All three extend the current convention without breaking existing RFCs.

Current convention

RFCs at docs/rfcs/NNNN-slug.md currently use:

# RFC NNNN: Title
## Status        → Accepted / Proposed
## Date          → YYYY-MM-DD
## Related       → links to issues, sibling RFCs
## Summary
## Context
## Options Considered   (with explicit Option A/B/C)
## Decision

This works well for accepted decisions with clear alternatives. The ## Options Considered section in particular is a strong element most ADR templates lack.

Proposed improvements

1. Expand the status vocabulary

Add two values:

• Draft — pre-proposal; the design is sketched but the author is not yet ready to put it up for acceptance. Useful for long-lived design conversations that need a durable home before they lock.
• Superseded by: RFC NNNN () — formal supersession marker on the Status line of a replaced RFC, so readers of the old RFC have an explicit forward pointer.

The existing Accepted and Proposed values stay unchanged.

2. Add ## Consequences to the template

A standard Michael-Nygard-style section between Decision and Related, capturing:

• follow-on work the decision implies
• commitments it creates
• risks or costs it accepts

Without an explicit Consequences section, second-order effects tend to sprawl across the Decision section or disappear entirely. Existing RFCs can gain the section lazily; the template addition is non-breaking.

3. Add a minimal docs/rfcs/README.md index

One-line blurbs per RFC, grouped by status. Cheap at current scale; prevents the orientation cost of having to open each RFC to know what it is about as the collection grows.

Hand-maintained at current scale; auto-generation from RFC headers could come later if the collection grows large enough to justify it.

Why this exists

These three gaps surfaced while studying pituitary's RFC convention for adoption in another project (a sibling CCD repository that has been aligning its spec and doc structure to pituitary's patterns). The convention was strong enough to adopt almost verbatim; these are the three points where the adopting project chose to extend rather than accept the limitation.

If pituitary adopts the same extensions, the two projects stay in sync. If pituitary prefers to stay with the current minimal template, the extensions can remain local to the adopting project without breaking cross-project consistency on the core shape.

Non-goals

• Replacing the existing template or renaming existing RFCs
• Making ## Options Considered mandatory where no alternatives existed
• Introducing numbered-status workflows (review gates, approval quorums, etc.)