RFCs named as RFCs, nothing a customer sees is called a lab

Problem

The console's RFCs product grew out of the Lab, our own public notebook of RFCs and studies. Its code kept that name, and since 2026-10-04 its API is open to every signed-in person (RFC 0035), so the name now leaks into a public contract:

• REST paths under /v1/labs, with {lab_id} in every one of them;
• the scopes lab:read and lab:write;
• JSON fields lab_id and messages called Lab;
• operation names in the OpenAPI document and the reference (LabsService.ListLabs);
• the console's addresses (/lab/...), the command iohr lab check, and the MCP tools being built over this API (RFC 0050).

A customer reads "lab" and has to learn that it means a space of RFCs. The owner decided on 2026-10-05 that nothing a customer sees calls the product a lab, the scopes included. The site's own Lab, our public notebook at /lab/, keeps its name: it is a different thing and the place the product came from.

The surface opened one day ago and nobody outside builds on it yet, so the change will never be cheaper than now.

Proposal

The public names

Documents, versions, comments, reviews and diagrams keep their names; they never said lab.

One release of both, then one name

1. The new service and paths ship beside the old ones, served by the same code. Old paths answer exactly as before, with a Deprecation header and a Link to the new path (RFC 9745). The old scopes are accepted as aliases of the new ones; a new key or token is issued with the new names only.
2. The console moves to /rfcs/; every /lab/... address of the console redirects to its new one, so links in mail and bookmarks keep working. The command line accepts iohr lab check as an alias that prints the new name.
3. One release later the old paths, the scope aliases and the console redirects are removed. The reference never lists the old names.

A diagram is drawn here in the RFCs product; this page does not show diagrams yet.

What keeps its name, and why

The service is still deployed as labs, its crate is tbd-labs, its is labs and its ids keep their lab_ prefix. None of these reach a customer except the id prefix, an opaque string, and renaming storage and deployments is risk without a reader. They move with the platform-wide rename of internal names, which has its own plan.

Alternatives considered

Rename the words in the console and the docs only. Cheaper, but the scopes, the paths and the field names are what a developer and an assistant actually read, and the owner asked for those too.

Rename everything at once with no aliases. One day of public life is short, but the console, the CLI, the SDKs' generated clients and the MCP tools change on different days; a release of both names lets each move on its own day without breaking the others.

Rename internals too. Moving a schema, a deployment and its Secrets for a name nobody outside sees is the kind of change that fails at 2 a.m.; it waits for the platform rename.

Decision

Open. The owner set the direction on 2026-10-05; the table above is the proposal.

Publication

The reference's RFCs section, the console and the docs say spaces and RFCs from the release that adds the new names. Nothing on any surface calls the product a lab after it.

Status log

• 2026-10-05: Written at the owner's request. Implementation started in a branch; no roll while the cluster is frozen after the storage failure of the same day.
• 2026-10-05: Built, the first release of both names. iohr.rfcs.v1.RfcsService is answered by the same labs service, which rewrites a new method's path to the old one (the two protos carry the same fields under the same numbers); /v1/rfcs/spaces/..., /v1/rfcs/reviews, /v1/rfcs/assignments, /v1/rfcs/invitations/... and space_id are the public names, and the reference lists only them. The old /v1/labs routes answer as before with Deprecation and a Link to the new path; lab:read and lab:write count as rfc:read and rfc:write in and the gateway, and the accounts catalogue offers only the new ones. Each new RPC costs what the old one does. The console moved to /rfcs/ and says RFCs and spaces; every /lab/... page sends the browser to its new address, and the invitation mail links there. Not yet: the MCP tools (labs_*, moving to rfcs_*) and iohr rfc check, each in its own change; the old names go one release later.
• 2026-10-05: the MCP tools moved, built, not deployed (the cluster is frozen). They are rfcs_* under rfc:read and rfc:write (RFC 0050's status log has the list); the labs_* names answer for one release as deprecated aliases and go with the old proto service. Not yet: iohr rfc check.
• 2026-10-07: Checked: both names and the rfcs_* MCP tools (#296, #315) are live. Not yet: iohr rfc check and removing the old names. Open.