Which lanes you open, what you ask, and what you owe
frontdoor/1 — a published door: which lanes an organisation opens, what it asks at each, and what it owes in return. Emitted per repository, validated across an estate, verified from the applicant's own domain.
A published door: the lanes an organisation opens to strangers, what it asks at each one, and what it commits to in return. Emitted per repository, validated across an estate, and verified from the applicant’s own domain rather than from a form they filled in.
`frontdoor/1` is a published door served at `/.well-known/frontdoor.json`: an organisation says which lanes it opens, what it asks at each, and what it owes in return. Doors are emitted by each repository and validated together with `merge()`, never rendered from one central build — an estate runs several stacks, and a design that assumes a single build stops at whichever properties share one.
Every door carries one normative paragraph verbatim in `notAuthority`: a rung buys a reply and a place in a queue, never authority, money or access. Both the library and the vendored checker reject a door that drops it. Where real authority is needed, it is delegated and its chain verified — that is what flashyID is for.
The spec is normative about how a verifier may fetch — https only, a timeout, a size cap — so a door cannot be proved by a redirect, and it is verified from the applicant’s own domain rather than from a form.
Installing it puts these commands on your path — read from the package’s own manifest, so this list cannot drift from what you actually get.
flashyos-frontdoorflashyos-frontdoor-verifyflashyos-frontdoor-auditflashyos-frontdoor-registryflashyos-frontdoor-joinflashyos-frontdoor-surfacesThe door is generated and committed, so the Front door workflow re-emits it and validates the result on every push — if emitting changes the file, the committed copy is stale and the door a machine reads is not the one the config describes. The checker and emitter are vendored byte-identical across every repository that publishes a door and are dependency-free, so the same job runs on a Next.js app and a static generator. Separately, the Registry workflow re-verifies published doors on a schedule. Verify one yourself with `npx @flashyos/frontdoor-verify <domain>`.
Apache-2.0, read from the package’s own manifest. Embed it in anything, including closed software — that is what makes a spec adoptable and a verifier worth running. FlashyOS’s server side is AGPL-3.0-only instead, and a test in the monorepo asserts the direction between them: AGPL code may consume this, this may never consume AGPL code.