← All packages
The record · v0.1.0 · Apache-2.0

@flashyos/mesh

The checklist for joining, so the sequence is not in somebody’s head

One checklist for joining the mesh — what a repository has adopted, what is left, and the command for each.

npx @flashyos/mesh statusnpm ↗source ↗

Why it exists

Everything an organisation needs to join this network already exists, tested and documented, spread across eighteen entry points in nine packages. The sequence between them existed nowhere — an adopter could run every command correctly and still not know whether they were finished. This is the order, the evidence for each step, and the command that does it.

What it refuses to do
It writes nothing. Every step names the adopt command that already exists, tested and vendored where it belongs, because a second implementation in here is how two copies of one rule start disagreeing.

How it works

Ten steps in dependency order, each declaring what it produces, the paths that prove it, and the command a person runs. The charter is first because four later steps read it: capabilities come out of it, the handshake derives its advertised list from the role names, and the directory fragment declares what the rest serve. Start anywhere else and the same facts get typed twice.

A step is `done`, `outstanding` or `n/a` — three verdicts rather than two, because a library with no website cannot serve a front door and grading it for lacking one is how a published package once measured as a property with no door. Evidence counts a route handler as well as a committed file: the first run read a property at 6 of 10 when it was 8, because `route.ts` under a `.well-known` directory is a directory on disk and a path list missed it.

It reads a checkout and reports; it never writes. `status` exits non-zero when a step applies and is not done, so it is usable as a gate in a repository that has just adopted.

Related concepts
IntentMeshagentic autonomous organizationmachine-readable organizational trustAI agent trust register

Use it

Ask a checkout what it has adopted and what is left
npx @flashyos/mesh status
npx @flashyos/mesh status --json    # the same, for a gate

Installing it puts this command on your path — read from the package’s own manifest, so this list cannot drift from what you actually get.

mesh

In practice

Tell an adopter when they are finished
A new property runs one command and gets the whole ladder — what it holds, what is missing, and the exact command for each gap — instead of reading nine READMEs and hoping the order it guessed was right.
Gate a repository on its own adoption
The JSON output and the non-zero exit make the checklist runnable in CI, so a property that quietly loses a surface fails a check rather than staying green with a fragment nothing refreshes.

How it stays honest

The evidence for each step is a path in the repository, so the answer is re-derived from the checkout on every run rather than stored anywhere. Its own test suite runs the checker against fixtures shaped like the estate’s real repositories — a route handler, a monorepo whose site config is not at the root — because both of those shapes made the first version report a wrong number against a real property. Verify it yourself: run `npx @flashyos/mesh status --json` in any repository and check each path it names.

Questions

What does @flashyos/mesh do?
It reads a checkout and reports which of the ten mesh standards that repository has adopted, which are outstanding, and which do not apply — naming the command for each gap. It writes nothing itself.
Why does it not run the adopt commands for me?
Each step already has an adopt command that is tested and vendored in its own package. A second implementation here would be two copies of one rule, and copies of a rule in this estate disagree rather than break.
Why can a step be neither done nor outstanding?
Because some steps need a website. A library with no site cannot serve a front door, and grading it for lacking one produced a real false finding once — so those steps report as not applicable rather than as failures.

The licence

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.

Keep reading

The standardMachine surfaces
Also in the record
@flashyos/canon@flashyos/directory@flashyos/backlog@flashyos/shiplog@flashyos/checkpoint@flashyos/delivery@flashyos/playbook@flashyos/holding@flashyos/frontdoor