Maintainer documentation. Proposals do not enter the public website.
Start with open work to find an unfinished contract. For the self-hosting effort, read the status and evidence map before choosing another compiler slice.
Each numbered record appears once in these topic catalogs. Entries keep their original numbers and filenames. Related work belongs in references, not in several competing indexes.
| Topic | Contents |
|---|---|
| Compiler products and bootstrap | Source lowering, semantic products, linking, publication, and recovery seeds |
| Retained package-manifest products | Canonical syntax, semantic versions, selectors, and row publication |
| Native testing and compiler suites | Native discovery, execution, coverage, reports, and package gates |
| Packages and resolution | Package instances, locks, archives, repositories, and distribution |
| Runtime, I/O, and native platforms | Quantum and hybrid execution, host effects, native images, and releases |
| Language and semantics | Types, ownership, proofs, control flow, and the shared IR |
| Tools and applications | Formatting, documentation, test contracts, tutorials, and applications |
The catalog is a finding aid. A WIP owns its status and contract. Checked-in code, tests, and current reference manuals establish implemented behavior. A count of completed records is not a measure of language coverage or bootstrap completion.
- Draft, Review, Accepted, Implementing: a decision or implementation still needs work. The roadmap lists every such record.
- Implemented: the record's bounded acceptance gate completed. Its parent contract may still be open.
- Superseded: another numbered decision replaces the whole contract. Follow
Superseded byto the replacement. - Withdrawn: the proposal will not proceed. Its number remains reserved.
Follow-up names extensions, narrower replacements, ownership moves, and work
still needed. It does not mean that the entire earlier decision is obsolete.
Older records used Superseded by for both meanings. Those forward references
now use Follow-up unless the record itself is Superseded.
Artifact hashes, closure populations, transition counts, and test durations in completed records are milestone evidence. They identify the inputs measured then. Do not update old receipts to claim that every historical archive matches today's lockfiles. Put the current evidence location in the status map and keep exact pins in executable tests and locks.
Read the proposal workflow. Use the design template for a new contract and the implementation-record template only when a bounded stage needs a separate decision or acceptance boundary.
A local refactor, helper extraction, test, documentation fix, or private optimization usually needs a patch, not another WIP. Update the owning checklist instead. Split a WIP when its parts have distinct owners, failure boundaries, or acceptance gates. Do not split it merely to assign a number to each function.
Keep contracts in their WIPs, current cross-cutting status in the status map, and detailed execution history in the implementation records and Git. Parent WIPs should not grow a second copy of every child's evidence report.
The short proposal gate checks catalog coverage, titles, statuses, metadata, dependency cycles, replacement links, open-work coverage, and repository links:
./bootstrap/gradlew -p bootstrap :tools:test \
--tests '*ProposalIndexTest' \
--tests '*InternalDocumentationTest' \
--tests '*DocumentationStyleTest'
./bootstrap/gradlew -p bootstrap :tools:wheeler --args='check-docs docs'Keep every authored file below 1,000 lines. A prose paragraph must remain short enough to review as one argument. Wrapping a twenty-kilobyte progress report onto more lines does not fix it. Documentation-only organization does not require a physical compiler closure run.