01
Adoption is a checklist, not a switch
You should be able to: List the independent adoptions that together make a mesh node.
Being on the mesh is the sum of several separate things, each of which a repository adopts on its own: a charter that declares what the organization is, a handshake that announces it to agents, a directory fragment that enters it into the record, a front door that says which lanes it opens, and a published record of what it has shipped.
Because they are independent, partial adoption is the normal state, not an error — and it is invisible without a tool. A repository can serve a handshake and have no front door, or hold a charter it serves nowhere. Each gap fails silently, which is exactly why a checklist that names them one by one is worth more than a single green light.
`@flashyos/mesh` is that checklist: one command, one repository, an itemised answer. The rest of this course is what each item is, how the checklist decides whether it is really done, and how to close the ones that are open.
Source: FlashyOS — @flashyos/mesh (the on-ramp checklist)
02
The things a node adopts
You should be able to: Say what each checklist item is and what it does for the node.
The charter is the governance record: the roles the organization runs, what each may do, and the accountable human. The handshake is the machine-readable announcement served at a well-known URL, so an agent can find the node without an account. The directory fragment enters the organization into the federated record other properties merge.
The front door declares which lanes the organization opens and what each costs — how a stranger engages, stated rather than guessed. The record is the published log of what the node has shipped, sealed so it can be trusted.
Each is a real, separate deliverable with its own format, taught in its own course elsewhere in the Academy. The checklist's job is not to teach them but to tell you, for your repository, which are present and which are not.
Source: Flashy Academy — Joining the Mesh
03
What the checklist measures — served, not just committed
You should be able to: Explain why the checklist checks the served surface, not the repository contents.
The sharpest thing the checklist gets right is what it measures. A file committed to a repository is not a file served at a URL, and the mesh only sees what is served. So the checklist does not mark the handshake "done" because the JSON exists in git — it marks it done when a fetch of the well-known URL returns it.
This is the estate's most-repeated lesson — committed is not served — built into the tool so you cannot fool yourself. A charter that passes locally and a domain that serves it are two different facts, and only the second one puts you on the mesh. The checklist reports the second.
The practical consequence: run it against your live domain, not just your checkout. A green item means a stranger can actually reach that surface, which is the only kind of "done" that counts for a node whose whole point is being reachable.
Source: FlashyOS — committed is not served
04
Reading "what is left" and the command for each
You should be able to: Turn an adoption report into the next concrete action.
The checklist's output is not a score, it is a worklist. For each open item it names the gap and the command that closes it — run the conformance init, serve the well-known files, emit the directory fragment, open the front door. The report is meant to be actioned top to bottom, not admired.
This turns "get on the mesh" from a vague project into a sequence of small, checkable steps, each with a done condition the tool can confirm afterwards. You close an item, re-run the checklist, and watch it flip — the same tight loop the whole estate prefers over a checklist a human ticks by eye.
And because it is measured rather than remembered, the report does not drift. A repository that regresses — a surface that stops being served — shows the item reopening, so the checklist is as useful for keeping a node healthy as for building one.
Source: Flashy Academy — Writing Your Charter
05
From nothing to a full node
You should be able to: Sequence the whole on-ramp using the checklist as the guide.
End to end, the checklist is the map for the whole on-ramp. Start with the charter and handshake — the two that make you readable at L2 — then the directory fragment to enter the record, the front door to declare your lanes, and the shipped log to publish what you do. Each closes an item; the checklist confirms each against the live domain.
The one-command on-ramp scaffolds the first files for you, and this checklist is how you verify its output and drive the rest: the scaffolder writes, the checklist checks. Together they turn membership from a consulting engagement into a loop a single person can run.
A full node is not a status you are granted; it is a checklist you complete and keep complete. When every item is green against your live domain, a stranger's agent can find you, read what you do, know what you cost, and verify what you have shipped — which is the whole of what being on the mesh means.
Source: Flashy Academy — The One-Command On-Ramp
