# Flashy Tools — The estate’s workshop, documented.
# https://flashy.tools · a Flashy Group property on the FlashyOS mesh

> FlashyOS is the open network where organisations’ agents find each other, agree to work together with a human’s consent, do the work, and seal a record anyone can re-verify.
> This property documents the formats, packages, scaffolds, vendored checks and instruments that make that verifiable, with the edge cases written down.

Versions are from the audit of 2026-10-04 and say so; a version somebody wrote down is a snapshot, never "latest".
Open source: the door is https://flashyos.com/open; the register, as one document, is https://flashyos.com/.well-known/open.json; this site is the depth.

## Sections
- Catalog: https://flashy.tools/tools — The published @flashyos/aao validator runs in the demo before you install anything or trust anyone. Same code the estate ships.
- Standards: https://flashy.tools/standards — Every format carries /1 in its name, a refusal-first parser and a publication gate: unpublished until its first adopter.
- Get started: https://flashy.tools/start — One command writes a charter, a handshake, a directory fragment and a workflow, then verifies L2 against your own domain.
- Open source: https://flashy.tools/open — flashyos.com is the door; this page is the depth. Both render one register, and a repository is linked only when it has been read as public.
- Mesh: https://flashy.tools/mesh — FlashyOS answers that; this property documents the formats and checkers that make the answer verifiable.

## Machine doors
- handshake: https://flashy.tools/.well-known/flashyos.json
- charter: https://flashy.tools/.well-known/flashyos-charter.json
- front door: https://flashy.tools/.well-known/frontdoor.json
- shipped/1: https://flashy.tools/.well-known/shiplog.json
- backlog/1: https://flashy.tools/.well-known/backlog.json
- checkpoint/1: https://flashy.tools/.well-known/checkpoint.json
- devlog/1: https://flashy.tools/.well-known/devlog.fragment.json
- delivery/1: https://flashy.tools/.well-known/delivery.json
- llms.txt: https://flashy.tools/llms.txt
- llms-full.txt: https://flashy.tools/llms-full.txt

## The estate ring
- FlashyOS: https://flashyos.com — the mesh platform: charters, conformance, coordination — where these tools live
- Flashy Network: https://flashynetwork.com — the settlement layer and the estate’s public record
- Flashy Group: https://flashygroup.com — the parent organisation
- Magician: https://magician.network — trust routing — the human layer these formats carry
- Gord Holdings: https://gord.holdings — the register of the estate
- GDA Group: https://gda.group — capital markets advisory
- ClaimYour.Gold: https://claimyour.gold — consumer scale on the same honesty registers
- Flashy Gold: https://flashy.gold — the asset layer

## Record formats (15)

### @flashyos/aao (Record format)
URL: https://flashy.tools/tools/aao
Version: 0.4.2 (audit of 2026-10-04)
Install: npm i @flashyos/aao
Source: flashyos/packages/aao

The AAO charter standard: named roles, a human accountable by email, and approval thresholds an agent cannot cross alone. The manifest spec, its JSON Schema, and the validators every checker in the estate imports.

An Agentic Autonomous Organization publishes one charter at /.well-known/flashyos-charter.json — and the conformance suite reads it there and nowhere else. The charter names roles (governance labels), each with a family, a purpose, a measure, and the approval threshold above which a human must sign.
Two vocabularies are deliberately linked rather than merged: a role name is a governance label, a capability is a discovery tag, and every advertised capability must be answered for by some role — by name or through that role’s x-capability.

Commands:
- `npx @flashyos/conformance <domain>` — audit a live domain against the charter it serves
- `npx @flashyos/conformance init` — scaffold the charter, both well-known surfaces, and the test

Edge cases, each paid for once:
- **One unknown top-level key fails all five static questions.** The suite stops at the first invalid manifest, so a stray key that is neither a spec field nor x- prefixed makes a fully-populated roster read as an org that declared nothing. One _comment did exactly this to two rosters.
- **Role names cap at 24 characters.** A role whose function has a longer name carries x-capability rather than a truncation. The vendored pre-install checker could not see this rule until the differential test compared it to the spec.
- **An empty family beats an invented role.** The standard exists to stop roster inflation, not to reward it. Pre-revenue orgs honestly declare empty growth/revenue/support families.

### @flashyos/directory (Record format)
URL: https://flashy.tools/tools/directory
Version: 0.2.0 (audit of 2026-10-04)
Install: npm i @flashyos/directory
Source: flashyos/packages/directory

directory/1 — the estate’s record: one entity per real thing, emitted as federated fragments by each repository, merged with one authority per id. The vocabulary (KINDS, EDGE_TYPES, EDGE_REQUIRES), the merge, and the validator.

Federation’s core rule: one id, one authority. Defining an entity and asserting a fact about one are different acts — the merge permits a second property to assert an edge about an id it does not define, which is what makes cross-checking (witnessing) possible at all.
Partner organisations are borrowed, not missing: each repository’s directory.externals.json names the ids it references but cannot define. The estate cannot define BMW, and a report that lists it as a gap is asking for a fabrication.

Edge cases, each paid for once:
- **declareEmitters, or 91% of your edges cite nothing.** The first estate run found 2,478 edges signed by agent/<slug>-ci identities no fragment defined. An emitter is a machine the org operates — deliberately not a charter role, because a "ci" role would advertise continuous-integration-as-a-service to the network.
- **`declares` needs a role only when it names an agent.** Measured, not decided: all 88 published declares edges naming an agent carry a role; none of the 43 naming a machine surface do. A flat requires rule would read 43 correct facts as defects.
- **One letter of filename drift hid seventeen partners.** gda-group emitted directory.external.json (no s) and its own hand-written checker passed. Seventeen partner companies read as undefined endpoints until the reader learned the canonical name.

### @flashyos/shiplog (Record format)
URL: https://flashy.tools/tools/shiplog
Version: 0.1.0 (audit of 2026-10-04)
Install: npm i @flashyos/shiplog
Source: flashyos/packages/shiplog

shipped/1 — the past tense of a record. One sealed entry per thing that shipped, derived from first-parent commit history, emitted per repository, never edited after sealing.

The log is derived --first-parent and an emit is a union, never a replacement: a commit stops being first-parent the moment its branch is merged, so overwriting the fragment silently deletes entries for work that shipped. An id already present keeps its sealed entry; only new ids are added.
Classification reads the subject through a declared lexicon; where the subject cannot say what a commit was, a Kind: trailer beats both the prefix and the lexicon — the author saying so, not the machine inferring.

Edge cases, each paid for once:
- **--rederive is destructive and kinds.json cannot fix history.** An entry is sealed once; its digest covers its kind. Run on main, --rederive took a 293-entry log to 90, because merged branches stop being first-parent. Record classification decisions for what has not been emitted yet; for what has, the classification is final.
- **Read the emitter id from config; never derive it from the slug.** slug + "-ci" was wrong in two of ten repositories (claimyour.gold-ci vs a slug of claimyour-gold). Every structural check passed while the declared agent matched no signature anywhere.
- **Emitted commits carry [skip ci] or they eat the deploy budget.** On one day, 54% of 594 estate commits were emitters refreshing their own fragments — against a 100/day account-wide build limit. Nothing was red; every property was just always slightly stale.
- **held.json: a repository publishes; an entry can still be held.** An entry that maps an exploitation route stays in the repository’s own sealed record and out of the served projection. Holding is not remediation — only rotation fixes a leaked secret.

### @flashyos/backlog (Record format)
URL: https://flashy.tools/tools/backlog
Version: 0.1.1 (audit of 2026-10-04)
Install: npm i @flashyos/backlog
Source: flashyos/packages/backlog

backlog/1 — the future tense. One item per intention, filed where the work happens, decaying unless renewed, private until a named human promotes it.

file() always writes private, always rev 1, expiry always derived from kind — there is no visibility parameter and there will not be one. Publication is promote(), it takes a person/ id, and it is recorded on the item.
capabilitiesWanted is what makes an item matchable: normalised exactly as the matcher reads (trimmed, lowercased, de-duped, capped at 20), so a promotion never silently stops matching over whitespace.

Edge cases, each paid for once:
- **A write-once wants field made every item invisible.** For weeks nothing could add capabilitiesWanted after filing, so all 53 items across the estate were permanently unmatchable and no check could say so. revise() exists now — and changes everything about an item except its visibility.
- **Full distribution with nothing distributed is worse than no adoption.** Thirty repositories filed backlogs, twelve served one, and 0 items were public — every structural check passes on an empty projection. It teaches every reader the format is decorative, one fetch at a time.
- **The machine that filed an item is the only machine that closes it.** Agent closure is restricted to ids the closing tool itself defines — a person’s item is not an agent’s to close because no rule happens to measure it. The consent rule, run backwards.

### @flashyos/checkpoint (Record format)
URL: https://flashy.tools/tools/checkpoint
Version: 0.2.0 (audit of 2026-10-04)
Install: npm i @flashyos/checkpoint
Source: flashyos/packages/checkpoint

checkpoint/1 — an RFC 6962 Merkle tree head over the sealed claims a property publishes. A static file beside the fragments: no server, no collector, no uptime.

The format deliberately stops short of a transparency log: retained heads, served consistency proofs and witness cosigning are gated on real adoption, and the SPEC states the boundary so a reader cannot mistake a reproducible root for tamper-evidence.

Edge cases, each paid for once:
- **A head is unsigned on purpose.** A signature over a root you computed, checked with a key you published, is ceremony without a property — what makes history provably append-only is a witness who is not you. A partial signature is a validation error, because presence-checking would read it as signed.
- **Only the past tense can be a leaf source.** backlog/1 items decay and are never sealed, so they carry no digest to commit to. The first real emit produced 97 leaves, all shipped — the two-tenses rule, discovered rather than designed.

### @flashyos/countersign (Record format)
URL: https://flashy.tools/tools/countersign
Version: 0.1.0 (audit of 2026-10-04)
Install: npm i @flashyos/countersign
Source: flashyos/packages/countersign

Proof over the record: countersignature, delegation, audit, badge. The layer that lets the party a claim is about sign the claim.

The countersignature ratio is the one number the estate cannot raise alone: claims about organisations that are not the estate, over how many those organisations signed. It publishes at its true value — currently low — because a figure you can move is worth publishing only beside the ones that would expose you moving it.

Edge cases, each paid for once:
- **stated is not countersigned.** A counterparty announcing the same fact on their own site is not a counterparty signing your record. Collapsing the two lets somebody else’s press release read as a signature — one estate property had exactly this bug for a month.
- **A denominator you can pad by pushing is the one thing this figure must not have.** issued edges deliberately reused for own releases made the count rise on every ship. Only claims whose far end names an identity that could sign (org/ or person/) enter the denominator.

### @flashyos/frontdoor (Record format)
URL: https://flashy.tools/tools/frontdoor
Version: 0.1.0 (audit of 2026-10-04)
Install: npm i @flashyos/frontdoor
Source: flashyos/packages/frontdoor

frontdoor/1 — a published door: which lanes an organisation opens, what it asks at each, and what it owes back — including the honest no-SLA rung.

The machine door (a handshake field) gets adopted first because it is one line of JSON; the human door gets forgotten. The estate measured six of seven properties with a machine join and nought of eight with a human one — publish both, and measure from outside.

Edge cases, each paid for once:
- **A well-known directory is not evidence anything serves it.** A published npm package with no site held five well-known files; grading it for lacking a door it could not have was the survey’s bug, not the package’s. A site framework is the evidence a door should exist.

### @flashyos/holding (Record format)
URL: https://flashy.tools/tools/holding
Version: 0.1.0 (audit of 2026-10-04)
Install: npm i @flashyos/holding
Source: flashyos/packages/holding

holding/1 — what happened to the positions an office holds. Transitions, not states: current state is derived from an append-only log, never asserted.

impaired and written-off are two of the seven states because a register without them is a track record: the denominator is what makes the numerator credible. recovery is one object rather than five fields so a renderer cannot take the flattering one alone.

Edge cases, each paid for once:
- **Version 1 carries no currency figures at all.** Fifteen field names are refused by name. Publishing marks is a regulated communication, a distribution is harder to flatter than a multiple, and a money column would be the only column anybody read.
- **recorded may not precede at, and the gap is published.** A register that writes down good news the same week and bad news eighteen months later says so in a number no copy improves — per entry and as a median.

### @flashyos/delivery (Record format)
URL: https://flashy.tools/tools/delivery
Version: 0.1.0 (audit of 2026-10-04)
Install: npm i @flashyos/delivery
Source: flashyos/packages/delivery

delivery/1 — the rungs between a merged commit and a thing somebody actually has. Publishes where on that ladder each shipped thing stands.

The newest format in the estate; its adoption was unmeasured until estate-standards asked, and read 2 of 15 on the first reading — which is the honest starting point of every format here.

Edge cases, each paid for once:
- **Merged is the first rung, not the last.** The estate’s recurring failure — committed but not served, merged but not deployed — is exactly the distance this format measures.

### @flashyos/canon (Record format)
URL: https://flashy.tools/tools/canon
Version: 0.1.0 (audit of 2026-10-04)
Install: npm i @flashyos/canon
Source: flashyos/packages/canon

canon/1 — a lockfile for facts. One authority per fact, fetched by every property that renders it, so a number is written once and cannot drift between pages.

The estate rule behind it: a page may not show a number the record does not contain. Canon is the record for cross-property facts — the property count, the flagship figures — with one authority and many renderers.

Edge cases, each paid for once:
- **Publish order can strand consumers.** canon sat eleventh of seventeen in a publish pipeline where one 422 made every later step skip via the implicit success() condition. Every publish guard now carries !cancelled().

### @flashyos/playbook (Record format)
URL: https://flashy.tools/tools/playbook
Version: 0.2.0 (audit of 2026-10-04)
Install: npm i @flashyos/playbook
Source: flashyos/packages/playbook

playbook/1 — a way two or more organisations work together, as a published document rather than tribal memory.

A playbook names the parties, the trigger, the steps and who consents at each — coordination made legible before it is needed.

### @flashyos/bolt (Record format)
URL: https://flashy.tools/tools/bolt
Version: 0.2.2 (audit of 2026-10-04)
Install: npm i @flashyos/bolt
Source: flashyos/packages/bolt

bolt/1 — one secret split across an estate: a hunt verified by sha256 commitment, in the finder’s own browser, with no server to trust.

The verify page holds the digest and not one shard, sends nothing anywhere, and keeps no record anybody visited. A miss never says which shard was wrong: a check that narrows the answer is brute-forceable one field at a time.

Edge cases, each paid for once:
- **Growth adds a tier; it never revokes one.** One commitment over N shards breaks the day property N+1 launches. Tiers are sealed like shipped/1 entries: each contains every property of the one before, and an early finder’s proof stays good forever.
- **Server components only — a shard in a client prop is findable in devtools.** Rendering the snippet from a client component puts the shard in the RSC payload and the bundle. And the hunt page itself must never carry its own property’s shard; the test caught that on the first build.

### @flashyos/mail (Record format)
URL: https://flashy.tools/tools/mail
Version: 0.3.0 (audit of 2026-10-04)
Install: npm i @flashyos/mail
Source: flashyos/packages/mail

mail/1 and the estate’s mail control plane: a lane policy that refuses, a capture that demands a consent basis, a content-free event record, and a transport seam so the provider is a variable.

Not a mail provider; the provider is a constructor argument. The record is content-free by construction — a log that kept subjects and addresses could never be published — and every outcome writes a leaf, refusals included, because a refusal that leaves no trace is indistinguishable from a message nobody tried to send. `held` is a success: a draft waiting for its human is the product.

Edge cases, each paid for once:
- **An address is never hashed into a leaf.** An email address is drawn from a small, enumerable space, so a hash of one is a reversible identifier. The leaf carries the lane, the outcome and the time; nothing that names a person, hashed or not.
- **Ownership is measured, never asserted.** Verifying a sender proves a domain authenticates mail; it does not prove the organisation controls it. The second is a nonce this platform issues and the tenant publishes in their zone, and no argument, field or route sets it — only a resolver returning it. `unasked` is never `absent`.
- **A published projection is an aggregate, never a per-message row.** Order separates recipients inside one domain, and a rare domain at a known minute is a near-identifier. The footer receipt on every outgoing message therefore carries the organisation and the lane and nothing else, because a footer link ends up in spam corpora and forwarded threads.

### @flashyos/artifact (Record format)
URL: https://flashy.tools/tools/artifact
Version: 0.1.0 (audit of 2026-10-04)
Install: npm i @flashyos/artifact
Source: flashyos/packages/artifact

artifact/1: a dated public commitment to content nobody can read yet. Existence precedes discovery.

An artifact sealed today is provably older than the day somebody opens it, and no amount of later effort manufactures that gap. The format seals a digest and a date in public and keeps the content private until its author chooses to reveal it; the reveal is checked against the commitment, never taken on faith.

Edge cases, each paid for once:
- **A commitment is only as good as the reveal that can be checked against it.** The sealed digest and the revealed bytes must hash through the same canonicalisation, or a true reveal fails and a forged one could pass. Sealing rules are shared across the estate and never restated, and the verifier is pinned to the sealer by test — the same discipline receipts and settlements already carry.

### @flashyos/assetmesh (Record format)
URL: https://flashy.tools/tools/assetmesh
Version: 0.1.0 (audit of 2026-10-04)
Install: npx @flashyos/assetmesh check .well-known/rwa.json
Source: flashyos/packages/assetmesh

rwa/1: a machine-readable record of a real-world asset, the attestations that stand behind it, and the obligations issued against it. Dependency-free, published at your own domain, verifiable by anyone.

A file an organisation publishes at /.well-known/rwa.json describing assets it holds and obligations issued against them. No account, no server, no chain, no permission: a stranger fetches it and checks it offline. An asset does not get a market; it gets a denomination, so obligations against different assets are the same unit in a holder’s hands and there is no per-asset liquidity to bootstrap.

Edge cases, each paid for once:
- **A claim without an attestation is a description, not a record.** The format separates what an issuer says about an asset from what a third party attests, and the validator refuses an obligation issued against an asset no attestation stands behind. The point of the record is that the stranger can tell the two apart without asking the issuer.


## Packages (18)

### @flashyos/verify (Package)
URL: https://flashy.tools/tools/verify
Version: 0.5.0 (audit of 2026-10-04)
Install: npm i @flashyos/verify
Source: flashyos/packages/verify

Open, offline verification of settlements, receipts and handshakes: fetch the public feed, recompute every digest, trust nothing.

Sealing rules are shared, never restated: receipts, settlements and shipped/1 entries hash through the same canonicalisation, and this package pins the verifier against the sealer so the two cannot diverge.

Edge cases, each paid for once:
- **The verifier is pinned to the sealer by test.** Two implementations of one canonicalisation is how a valid record fails verification a year later. The pin is a test that seals with one and verifies with the other over adversarial inputs (emoji, key order, unicode lengths).

### @flashyos/llms-txt (Package)
URL: https://flashy.tools/tools/llms-txt
Version: 0.1.1 (audit of 2026-10-04)
Install: npm i @flashyos/llms-txt
Source: flashyos/packages/llms-txt

Parse, validate and build llms.txt files — the machine door every estate property serves beside its human one.

An llms.txt names every machine surface and every mesh domain; drift tests on each property assert the file covers what the site actually serves.

Edge cases, each paid for once:
- **A static public/llms.txt is served before a route, so it silently replaces one.** flashy.academy committed public/llms.txt in August and later added a route handler at the same path. The static file won on the live domain for as long as both existed: every crawler got the old eight-primitives file and was never told courses.json or graph.json existed, while every local test read the route and passed. Committed is not served, and served is decided by a precedence rule nothing had checked — a test now refuses any file under public/ that sits at a route handler’s path.

### @flashyos/conformance (Package)
URL: https://flashy.tools/tools/conformance
Version: 0.2.3 (audit of 2026-10-04)
Install: npx @flashyos/conformance <domain>
Source: flashyos/packages/conformance

Run the conformance suite against any live domain, audit a charter+handshake pair in-process (auditProperty / assertProperty), or scaffold a new property (init).

The charter is read from /.well-known/flashyos-charter.json and nowhere else. Every property’s test suite calls assertProperty so the spec’s constants live in one place — a hand-typed SPEC_KEYS list is a vendored snapshot with nothing to notice when the spec moves.
assertProperty cannot tell you the domain serves the files — that is the failure the whole estate had, twice. npx @flashyos/conformance <domain> over the network is the other half, after a deploy.
Learn the mechanics behind this and the Activation standard together: Flashy Academy’s Proving What You Ship teaches the four Activation artifacts, why a charter checker is vendored rather than reimplemented, and what the AAO launch gate actually verifies — using flashy.tools’s own suite as the worked example. https://flashy.academy/academy/curriculum/proving-what-you-ship

Commands:
- `npx @flashyos/conformance flashy.tools --level 2` — audit a live domain the way a stranger would
- `npx @flashyos/conformance init` — emit the charter, both well-known surfaces, and the test

Edge cases, each paid for once:
- **An exports map naming only `import` is an allowlist.** Vite matched import; jest resolved CJS, matched nothing, ignored main entirely, and reported Cannot find module against the test file. 0.2.3 ships a real CommonJS build, and packaging.test.ts loads both — a correct map over a half-built dist fails identically for the adopter.
- **The scaffold seeded the wrong join door into every new property.** init emitted an account-signup URL as the join pointer; two properties served it live before anyone looked upstream. Fixing a scaffold is worth more than fixing its output twice — and the URL is declared once and interpolated, because a backtick in a comment inside the template literal terminated it on the first try.

### @flashyos/agent (Package)
URL: https://flashy.tools/tools/agent
Version: 0.21.0 (audit of 2026-10-04)
Install: npm i @flashyos/agent
Source: flashyos/packages/agent

The SDK agents import to report state to the mesh: heartbeat, work claims, and the consent-gated write paths.

Every write lands PROPOSED; there is no argument, flag or caller that produces an approved fact directly. An agent that could approve its own draft would make the consent layer decorative.

Edge cases, each paid for once:
- **The work layer’s actor is a Node, never an org — and AGENT is not constructible.** An agent acts for somebody and the somebody answers. Giving an agent its own answerable identity is how work ends up held by a machine with no human behind it. This is doctrine, not a gap.

### @flashyos/mcp (Package)
URL: https://flashy.tools/tools/mcp
Version: 0.6.0 (audit of 2026-10-04)
Install: npm i @flashyos/mcp
Source: flashyos/packages/mcp

The same mesh surface as the SDK, exposed as Model Context Protocol tools — connect any MCP-speaking agent to the mesh in one config block.

Docs for the MCP tool surface are drift-tested against the real tool list: add a tool and the marketing site’s reference fails until it is documented.

Edge cases, each paid for once:
- **A new MCP tool fails the docs drift test until it is documented.** flashyos.com renders its MCP and SDK documentation from data modules, and a drift test asserts those match the real tool surface. Add a tool to the server and the marketing build goes red until the page describes it — the documentation is pinned to the code rather than written beside it, because a tool an agent can call and a reader cannot find is the exact gap this estate keeps paying for.

### @flashyos/llm-gateway (Package)
URL: https://flashy.tools/tools/llm-gateway
Version: 0.2.1 (audit of 2026-10-04)
Install: workspace package (publication pending)
Source: flashyos/packages/llm-gateway

Provider-agnostic inference seam: adapters, automatic failover, metering ceilings, and an empty-success guard.

The seam every estate product routes inference through, so a provider change is a config edit and usage is metered where it is spent.
Learn to build with it: Flashy Academy’s Inference Economy track teaches what inference and compute are, why choosing inference is an economic decision, inference as yield, and getting set up and building with Gatewayz — the unified inference gateway this seam routes to via its gatewayz provider. https://flashy.academy/academy/curriculum

Edge cases, each paid for once:
- **An empty 200 is a failure wearing a success code.** The empty-success guard exists because a provider returning a well-formed nothing passes every status check and fails the user. Guard on content, not on status.
- **An unpriced model is refused, not passed through.** Metering that silently skips a model it cannot price reports a ceiling nobody is enforcing.
- **Tool use and prompt caching are not yet verified through a gateway.** A gateway preserves the common request shape but not every advanced feature: one that silently drops a cache-control directive does not error, it multiplies the bill, and a mangled tool-use request breaks function-calling in ways that read as a model failure. Verify both behave through the gateway before depending on them in production.

### @flashylabs/ledger (Package)
URL: https://flashy.tools/tools/ledger
Version: npm (private registry visibility) (audit of 2026-10-04)
Install: npm i @flashylabs/ledger
Source: flashy-ledger

Append-only, multi-asset settlement ledger. Storage-agnostic by construction; integer amounts; hash-chain verifiable.

The ledger other estate properties post through — consumer scale at ClaimYour.Gold runs on it, with a public invariant verdict published nightly.

Edge cases, each paid for once:
- **mongodb is a peer dependency, and a symlinked checkout fakes a type error.** With a sibling checkout symlinked, two copies of mongodb’s types meet and tsc reports one impossible Db-is-not-Db error. It cannot happen in CI, where the ledger installs from the registry. Check it is the only error before concluding the tree is dirty — and read the pre-push output before reaching for --no-verify.

### @flashylabs/wdk-policy-guard (Package)
URL: https://flashy.tools/tools/wdk-policy-guard
Version: source-available on GitHub (npm publish pending) (audit of 2026-10-04)
Install: github.com/FlashyLabs/wdk-policy-guard
Source: github.com/FlashyLabs/wdk-policy-guard

A spending-policy layer for wallets built on Tether’s WDK, or any wallet SDK. Grades a proposed spend against a per-agent envelope — chain, kind, asset and destination allowlists, a per-transaction cap, a daily cap — before anything signs, and returns ALLOW, ESCALATE, or DENY, always with a reason.

WDK ships a policy engine with denial codes but nothing that grades a transfer against per-agent, per-day limits. Extracted from the policy layer built for Flashy Wallet’s own agent-facing envelope grading and open-sourced because the gap — spending limits for an automated caller holding a wallet — belongs to every team building on WDK, not just to us.
grade() is pure: it reads a DailyLedger’s reservations but never writes them, so a caller can preview a verdict without side effects. Reserving happens only after ALLOW, and is the caller’s own responsibility — which keeps the core function safe to call speculatively from a UI.

Commands:
- `npm test` — run the 43-test suite — node’s built-in runner, no external services

Edge cases, each paid for once:
- **Amounts are strings, never a Number, at every comparison.** A spending cap compared as a JS Number silently stops being a cap once the amount crosses Number.MAX_SAFE_INTEGER. The package converts to BigInt exactly once, at the comparison, and the daily-cap and per-transaction-cap tests both exercise amounts at that boundary rather than trusting the arithmetic by inspection.
- **A self-contradictory envelope is caught before it can allow more than it claims.** validateEnvelope() refuses an envelope whose autoApproveMax exceeds its perTxMax, or whose perTxMax exceeds its dailyMax — three numbers that read as independent limits on a form but are only a real limit when ordered correctly relative to one another.

### @flashylabs/wdk-staking-kit (Package)
URL: https://flashy.tools/tools/wdk-staking-kit
Version: source-available on GitHub (npm publish pending) (audit of 2026-10-04)
Install: github.com/FlashyLabs/wdk-staking-kit
Source: github.com/FlashyLabs/wdk-staking-kit

A reference staking primitive for wallets built on Tether’s WDK. Locks a balance into a fixed-term tier at a published rate, with no on-chain contract required: a lock earmarks a balance a provider already credits, and only the yield, paid on close, is a real write.

As of this package’s first release, no WDK module offers staking — every wallet, protocol and pricing module WDK publishes covers something else. Generalized from the rail-first staking design built for Flashy Staking and open-sourced because the gap is shared by the whole ecosystem building on WDK, not specific to us.
yieldForAmount() is the exact, BigInt-computed figure close() actually uses; yieldFor() is a Number-based approximation for small, display-sized amounts on a terms page. Using the display function for a real lock is the one mistake the design goes out of its way to make hard to reach for.

Commands:
- `npm test` — run the 52-test suite — node’s built-in runner, no external services

Edge cases, each paid for once:
- **A lock never moves the underlying balance.** available() is balance() minus locked(), summed across every open position — the package is bookkeeping over a BalanceProvider you already control, never a second source of truth for what a holder actually has.
- **Yield is computed once, at lock time, from the tier then in force.** A later change to a published tier list cannot reach back into an already-open position and change what it pays — checkTerms() also catches a self-contradictory terms document, such as a longer term paying less than a shorter one, before it is ever published.

### @flashyos/shipos (Package)
URL: https://flashy.tools/tools/shipos
Version: 0.1.0 (audit of 2026-10-04)
Install: in the flashyos monorepo
Source: flashyos/packages/shipos

The release function, chartered: a consequence-ranked merge queue for every repository, plus the operator lane — the ranked list of actions only the accountable human can take.

The operator lane is the estate’s answer to human-gated work getting lost in transcripts: one file per org, items ranked by consequence, budgets that turn the gate red when a critical waits past 48 hours, and closure recorded as a commit edit — the commit is the attestation.

Edge cases, each paid for once:
- **Never write a secret’s value into the queue.** Items name the secret and where it lives (Secret Manager), never the value. The queue is committed; a committed credential is burned the moment it lands and stays burned after deletion.

### @magician/core (Package)
URL: https://flashy.tools/tools/magician-core
Version: pre-publication (gated on first independent adopter) (audit of 2026-10-04)
Install: github.com/FlashyLabs/magician
Source: magician/packages/core

The trust-routing engine: trust/1 edges, the router with the veil, the consent machine, sealed introduction/1 outcomes, beacon/1 federation, grant/1, and the transport envelopes.

The parser refuses; it does not guess: unknown fields, unlabeled numbers, empty provenance, and any spelling of expiry are refused — decay is derived from renewal, never accepted as input.
Portable by rule: no node: imports anywhere in core, so the browser seals and verifies identically to the CLI. The sha256 is pure TypeScript, pinned against node:crypto by test.

Edge cases, each paid for once:
- **A declined introduction renders exactly as a path that never existed.** toRequesterView collapses the two, and a test compares the objects for deep equality. A visible refusal leaks exactly the relationship data the refusal was protecting.
- **Nothing a person does alone moves their standing.** There is a test whose whole job is proving unilateral activity moves nothing. A reward input would have to break a named test — that is the tripwire that keeps token mechanics out of trust scoring.

### @magician/concierge (Package)
URL: https://flashy.tools/tools/magician-concierge
Version: vendored to properties (canon in the magician repo) (audit of 2026-10-04)
Install: vendor concierge.js + the Activation check
Source: magician/packages/concierge

The Mesh Concierge: one dependency-free script that puts the estate’s intent door on any site, filing to a named human at that property. The Activation standard and its pre-install check travel with it.

Layer zero makes no network calls, keeps no storage and does no tracking — a test greps the served bundle for all three promises. A door with no data-contact refuses to render: nobody behind it, no door.
The Activation is four artifacts: concierge.js served, a /concierge page, a handshake join pointer, and a /demo page. One dependency-free script verifies all four before anything is installed. This property passes it in its own gates.

Edge cases, each paid for once:
- **The demo is the fourth artifact, and its honesty rules are local.** Every property launches with something a stranger can try — no account, fictional data that says so. The vendored check can only see the page exists; the fictional-and-marked rule is enforced where the data is made.

### @flashyos/wallet-wdk (Package)
URL: https://flashy.tools/tools/wallet-wdk
Version: 0.1.0 (audit of 2026-10-04)
Install: npm i @flashyos/wallet-wdk
Source: flashyos/packages/wallet-wdk

Governed economic agency for FlashyOS agents on Tether WDK: the AAO WalletCapability, an authorizer client, an MCP elicitation handler, and a WDK policy rule that defers every spend to the authorization plane.

The package an agent runtime, a signer or a stranger verifying our records installs. It carries no dependency on the FlashyOS API: an agent asks the authorization plane for a SpendAuthorization and the plane answers with a signed decision, so the thing that moves money and the thing that decides never share a process.
Tether WDK is an optional dependency, and the package must build without it. The build is the part that bit.

Edge cases, each paid for once:
- **An optional dependency must also be one the package BUILDS without.** esbuild resolves and bundles a string literal inside import() however carefully the try/catch around it is written, so a present @tetherto/wdk subtree inlined the lazy import, the try/catch went dead, and nothing was red. Externals are now derived from optionalDependencies in the tsup config and a test is the alarm for the silent half (flashyos, docs/record/one-lockfile-two-trees.md).
- **One lockfile, two Node versions, two trees.** npm drops an optional subtree whose engines the running Node cannot satisfy silently. CI ran Node 22 and the deploy ran Node 20, so the same commit built green on CI and red in production at a step named after a package neither commit had touched. The versions agree now and a test refuses the divergence.
- **Published to a registry is committing, not serving.** This package and its two siblings went live on npm on 2026-09-22 and reached no catalog, no case study and no thesis — zero references anywhere a stranger deciding to depend on it would read. The distribution floor in flashyos measures that; the coverage gate on this site refuses it.

### @flashyos/signer (Package)
URL: https://flashy.tools/tools/signer
Version: 0.1.0 (audit of 2026-10-04)
Install: npm i @flashyos/signer
Source: flashyos/packages/signer

The isolated signer for the wallet authorization plane: verifies an Ed25519-signed SpendAuthorization, re-derives the operation from the real call, refuses on any mismatch, executes through Tether WDK, and reports settlement.

The only process that holds a seed, and it never holds the plane’s private key. For every request it does five things in a fixed order — verify the signature, re-derive the operation, compare, execute, report — and a mismatch at any step is a refusal with a reason, never a best effort.

Edge cases, each paid for once:
- **Re-derive the operation from the real call; never trust the one in the envelope.** An authorization names an operation. The signer recomputes what the call would actually do and refuses when the two differ, because a signed envelope that describes a different transfer than the one about to execute is exactly the attack a signer exists to stop.
- **The deploy image needs the manifest, not just the import.** npm links a workspace into an image only when its manifest was copied before npm ci. The api imported this package and the Dockerfile’s copy list stayed at four, so Deploy prod died on Module not found one step after an earlier fix got it that far. A test now reads imports with the TypeScript scanner and refuses the omission.

### @flashyos/wdk (Package)
URL: https://flashy.tools/tools/wdk
Version: 0.1.0 (audit of 2026-10-04)
Install: npm i @flashyos/wdk
Source: flashyos/packages/wdk

The FlashyOS agent object: identity, authority, wallet, memory and partners behind one interface, with financial capabilities provisioned on Tether WDK and every transaction recorded.

Create an agent, give it an identity, provision its wallet, set its permissions, let it transact, record what it did, coordinate it with other agents — one object, one event system, any chain WDK reaches. Authority is attenuated, never inherited: a child agent holds a subset of its parent’s scopes or the constructor refuses.

Edge cases, each paid for once:
- **A workflow_dispatch has no branch restriction.** Two packages in this plane reached public npm from commits main did not reach; on one the versions matched, so every version check saw agreement. Both publish workflows now fetch full history and refuse a commit the default branch does not contain.

### @flashyos/dialects (Package)
URL: https://flashy.tools/tools/dialects
Version: 0.1.0 (audit of 2026-10-04)
Install: npm i @flashyos/dialects
Source: flashyos/packages/dialects

One charter, many dialects: renders an organisation’s AAO charter into the surfaces other standards define — agents.txt, agents.json, an A2A Agent Card — so the same facts cannot drift between them.

The organisation writes its charter once. Everything another standard wants to read is derived from it and emitted beside it, and the emitter refuses to emit a surface the organisation does not actually serve: a card describing an endpoint that answers nothing is a claim, not a dialect.

Edge cases, each paid for once:
- **We speak other standards; we have not adopted them and they have not adopted us.** A door points at somebody else’s surface as a link, never a copy — the surface declaration emits `cites`, never `publishes` — and no page says “A2A-compatible” before a fetchable card exists with a drift test behind it. The refusal stopped its own authors twice, and both times it was right.

### @flashyos/mesh (Package)
URL: https://flashy.tools/tools/mesh
Version: 0.1.0 (audit of 2026-10-04)
Install: npx @flashyos/mesh status
Source: flashyos/packages/mesh

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

Run it in any repository and it reads the tree the way the estate’s surveys do — charter, charter served, handshake, capabilities, agent token, shipped, backlog, delivery, directory, ritual, checkpoint, notary — and prints a tick, a dot, and the one command that turns the dot into a tick. It is the on-ramp as a list rather than as a document.

Edge cases, each paid for once:
- **Finishing the checklist makes you legible to an agent, not findable by a stranger.** A property that has written its charter, handshake and record fragments has made itself readable to another organisation’s agent. It has not yet earned a catalog entry, a case study or a thesis anywhere a person deciding to depend on it reads, and three packages shipped exactly that way on 2026-09-22. The scaffold now says so as an explicit next step rather than leaving it implied.

### @flashyos/page (Package)
URL: https://flashy.tools/tools/page
Version: 0.1.1 (audit of 2026-10-04)
Install: npm i @flashyos/page
Source: flashyos/packages/page

One page, one card, one claim: per-page social images, canonical metadata and structured data for a property that expects to be cited by search engines and answered from by generative ones.

Measured on 2026-08-31 across thirteen properties and 733 pages: 11% had an image of their own, 29% a canonical URL, 20% structured data. The estate was good at metadata and bad at identity. This kit composes all of it from the page’s own facts in the same call that sets its title, so a title and its card cannot disagree. SEO and GEO are the same fields read twice; there is one function, not two.
This property’s own cards are rendered by this kit, vendored byte-identical (`src/lib/page/`), and a drift test compares the copy to canon or reports unknown.

Edge cases, each paid for once:
- **A property that forgets its accent should fail to compile, not render in somebody else’s colour.** The accent is a table keyed by property, not a parameter with a default. Thirteen hand-rolled card routes would have been the same four files written thirteen times, which is how the estate once ended up with eleven identical charter checkers that all disagreed with the spec in the same four places.
- **Each property renders its own cards.** Not flashyos.com’s /og with a query parameter: that would make every property’s social links depend on another domain being up, so one deploy could turn thirteen properties’ shared links into grey rectangles at once. A card is part of what a property serves.
- **It never writes a description.** A card and a canonical are derivable from the page; a description somebody has not written is a description somebody has not written. 539 pages in the estate carried a card that repeated the homepage, and that was the defect being fixed, not a template to generate more of.


## Scaffolds (2)

### @flashyos/create-mesh-node (Scaffold)
URL: https://flashy.tools/tools/create-mesh-node
Version: 0.1.0 (audit of 2026-10-04)
Install: npm create @flashyos/mesh-node
Source: flashyos/packages/create-mesh-node

The one-command on-ramp: writes a charter, handshake, directory fragment and workflow, then verifies L2.

Scaffolds are maintained like products because their output multiplies: a defect in a scaffold ships once per adopter, forever.
Before running this against a real property, read Flashy Academy’s Reading the Estate’s Toolkit — three lessons on why this catalog documents edge cases beside the happy path, and how to use it as the first stop rather than a package’s own README. https://flashy.academy/academy/curriculum/reading-the-estates-toolkit

Edge cases, each paid for once:
- **Finishing the checklist makes a property legible to agents, not findable by strangers.** A charter, a handshake and the record fragments let another organisation’s agent read a new property. They do not put it on a catalog, a case study or a thesis — three packages went live on npm on 2026-09-22 and reached none of the three. The scaffold says so as an explicit next step rather than leaving it implied, because committed is not served and served is not found.

### @flashyos/create-mesh-agent (Scaffold)
URL: https://flashy.tools/tools/create-mesh-agent
Version: 0.2.0 (audit of 2026-10-04)
Install: npx @flashyos/create-mesh-agent
Source: flashyos/packages/create-mesh-agent

Scaffold a dependency-free mesh starter agent into your repo — heartbeat, open-job polling, consent-gated actions.

Dependency-free is the constraint: the companies most likely to adopt want a toolchain least.

Edge cases, each paid for once:
- **Agents suggest; humans consent — the scaffold ships with no auto-approval path.** An agent the scaffold produces may draft a connection, but every participating organisation’s human approves before anything becomes real, and there is no code path that approves on the agent’s behalf. AGENT is not a constructible work-layer actor in FlashyOS: an agent acts for somebody, and the somebody answers.


## Vendored checks (1)

### The vendor-* family (Vendored check)
URL: https://flashy.tools/tools/vendored-checks

Install: copied byte-identical from canon; run with bare node
Source: flashyos/scripts + per-repository copies

Eight dependency-free scripts every estate repository carries: check-charter, check-directory, check-frontdoor, vendor-shiplog, vendor-backlog, vendor-directory, vendor-checkpoint, vendor-check-activation. They run before an install, in repositories with no node_modules and sometimes no package.json.

A vendored file fails by disagreeing, not by breaking: a stale copy silently disagrees about exactly the field somebody just changed at canon. estate-hygiene compares every copy byte-for-byte against canon and reports an incomparable copy as unknown rather than stale.
Every vendored checker is differentialled against its package, never eyeballed: both run over the same documents and any disagreement about the verdict fails — comparing constants is how eleven identical copies agreed with each other and disagreed with the spec in four places.

Edge cases, each paid for once:
- **Re-vendor before you trust a vendored change.** Adding a feature to canon does nothing in the sixteen repositories that vendored an hour earlier — they mark the very field you just added with its old default, and nothing errors. This shipped a hold-flag that sixteen copies marked public.
- **Adoption gate: alone, in an empty directory, with bare node.** adoptable.test.mjs copies each vendored script into an empty directory, runs it with no node_modules, and validates its output with the package’s own validator. It found two real defects in its first hour.
- **for d in */ does not match a dotfile.** That glob has cost the estate a repository three times (.github). The byte-identity sweep now enumerates with readdir, and the third time a test caught it instead of a person.


## Estate instruments (10)

### estate-graph (Estate instrument)
URL: https://flashy.tools/tools/estate-graph

Install: node tools/estate-graph.mjs (flashyos)
Source: flashyos/tools/estate-graph.mjs

Measures what the one-graph thesis is actually about: entities, relations, provenance, freshness, and the share of edges that cross a property boundary — with a ratio floor that fails regressions.

Ratios, never counts: "at least N attributed edges" is satisfied by adding edges while provenance falls. Joins are counted per surface, because the log outnumbers the ontology ten to one and a combined ratio is dominated by a population that can only cross boundaries through authorship.

Edge cases, each paid for once:
- **A metric whose best and worst value are the same number measures nothing.** cross-referenced counted ids defined by two repositories — which federation forbids — so a perfectly compliant estate read as totally disconnected, forever. It counts mentions now, and the old question survives as contested, where non-zero is a defect.
- **A capability tag is not a node, and a repository is not an entity.** Bare matcher words and repo/ ids are excluded by name in NOT_ENTITIES; ids whose prefix has no kind are reported as vocabulary decisions, not missing declarations.

### estate-hygiene (Estate instrument)
URL: https://flashy.tools/tools/estate-hygiene

Install: node tools/estate-hygiene.mjs (flashyos)
Source: flashyos/tools/estate-hygiene.mjs

Thirteen checks across every repository, with the repositories missing each one named rather than counted, and a per-dimension ratchet floor — because a mean lets one dimension collapse behind another’s improvement.

It reads refs/remotes/origin/HEAD’s tree and says which branch it read per repository — because reading the working checkout once reported secret scanning at 35/35 when the truth was 15/35.
Where the declared default branch is an agent’s scratch branch and a conventional trunk is strictly ahead, it reads the trunk and records the discrepancy — while still failing the setting, because reading past a lie must not silence the finding that it is one.

Edge cases, each paid for once:
- **A hygiene gate that goes green because it could not look is worse than no gate.** The CI wrapper fails rather than skips when its read token is absent — it is believed either way.
- **A floor written against a partial estate is not a floor.** The first floor recorded numbers from a 21-repository read that a full read never reproduced; the gate was red from the day it was committed with nobody running it. Floors are regenerated only from full reads, and say so in the file.

### estate-deployed (Estate instrument)
URL: https://flashy.tools/tools/estate-deployed

Install: node tools/estate-deployed.mjs (flashyos)
Source: flashyos/tools/estate-deployed.mjs

Fetches a domain’s served bytes and finds the commit whose committed copy is byte-identical — pinning exactly which commit a deploy serves, without trusting a date stamp or a CDN header.

It separates two findings every earlier report collapsed into "stale": a deploy behind its own default branch has stopped; a deploy serving a commit not on that branch was pointed somewhere else. Opposite fixes.

Edge cases, each paid for once:
- **Count the commits that changed the artefact, not every commit since.** Counting all commits read "220 behind" twenty minutes after a good deploy.
- **Zero-behind is not current when the bytes already differ.** The loudest case — a deploy serving another branch — reported healthy until the head comparison outranked the count.
- **refused is its own state.** A 403 from a sandbox’s egress gateway is indistinguishable from a site refusing; reading it as the site once wrote up a healthy domain as having Deployment Protection.

### estate-join (Estate instrument)
URL: https://flashy.tools/tools/estate-join

Install: node tools/estate-join.mjs (flashyos)
Source: flashyos/tools/estate-join.mjs

Fetches every estate domain and asks both questions a stranger’s arrival poses: does the handshake carry join (the machine door), and does the page link it (the human door)?

On first measurement: six of seven machine doors, nought of eight human ones. The machine door is a line of JSON, so it gets adopted first — and nothing notices the other half was never built, because every structural check passes on a handshake.

Edge cases, each paid for once:
- **Run it somewhere with open egress before treating silence as fact.** The first run said unreachable for eleven hosts; every one was a proxy refusal. No ratio is computed over a host that did not answer.

### estate-coherence (Estate instrument)
URL: https://flashy.tools/tools/estate-coherence

Install: node tools/estate-coherence.mjs --gate (flashyos)
Source: flashyos/tools/estate-coherence.mjs

The agreement check: of everything the estate publishes, how much is asserted by two properties from their own sides, with their own bases — the record’s only way to catch its own errors.

Every other check is a check of form (valid file, present field, answering URL); this is the check of agreement. On first run: 1 witnessed of 479, because a correct federation rule had been applied one step too far — defining an entity and asserting a fact about one are different acts.

Edge cases, each paid for once:
- **A copy is not a witness.** A restatement carrying the first property’s basis is one source counted twice — the citation loop rebuilt one level down. A group whose assertions share a basis fails the gate, because it is worse than no witness: it looks like one.
- **engaged is the vocabulary’s one symmetric relation.** Keying on literal direction read a seeded pair as two facts and reported 0 witnessed with both halves present. owns reversed is a different and usually false claim — folding it would let "A owns B" and "B owns A" corroborate each other.

### estate-countersigned (Estate instrument)
URL: https://flashy.tools/tools/estate-countersigned

Install: node tools/estate-countersigned.mjs (flashyos)
Source: flashyos/tools/estate-countersigned.mjs

Counts the claims the estate makes about organisations that are not the estate, and how many those organisations have signed — the one number nobody here can raise.

It publishes at its true value with every unsigned claim named, because every other figure rises when a property talks more about itself; this one moves when somebody else acts, and not before.

Edge cases, each paid for once:
- **The write/check guard cannot live in the consuming repository.** A runner there holds one checkout and could only compare the file to itself — a stopped clock checking its own time. --check runs where every default branch is readable.

### The three registers (Estate instrument)
URL: https://flashy.tools/tools/estate-registers

Install: node tools/estate-licences.mjs · estate-authors.mjs · estate-standards.mjs (flashyos)
Source: flashyos/tools

What each repository is licensed as, who did the work, and which standards each adopts — declared once, cross-checked against each other, surveyed against reality.

The licence register holds licence and copyright holder for all repositories and refuses an open licence on client work — that grant is not ours to make. The authors register maps commit addresses to identities so the log’s attribution is honest. The standards matrix borrows its tests from the hygiene gate by key, never restating them.

Edge cases, each paid for once:
- **Registers that never check each other exempt silently.** A repository forgotten in one register is silently exempt from that one, and the exemption is indistinguishable from a decision. estate-registers.test.mjs cross-checks all three — and found the survey reading the wrong root on its first run.
- **A bare Apache text is a grant on behalf of nobody.** Eleven repositories had Apache-2.0 with no copyright line — passing every "does a LICENSE exist" check ever written. The register writes the line itself; this repository was caught by exactly this check on the day it was registered.
- **The commit log can lie while the files are right.** A sweep identified licences it had just written by reading the first line; canonical Apache text begins with a blank line, so eight commit messages named the copyleft licence over correct Apache files. Corrected by new commits, never by rewriting.

### reachability (Estate instrument)
URL: https://flashy.tools/tools/reachability

Install: imported by every network-calling estate tool
Source: flashyos/tools/reachability.mjs

One rule about silence: classifies a failed fetch as unreachable, ambiguous, or refused — and every tool that makes a network call imports it, enforced by test.

fetch returns the same nothing for a parked domain, a DNS error, a host that is down, and an egress proxy refusing the CONNECT. Four tools once each decided alone what that nothing meant; two reported it as a fact about somebody else’s property.

Edge cases, each paid for once:
- **Match ENOTFOUND on the code, never the message.** Node’s phrasing changes between versions, and a tool that greps the sentence stops working quietly at the exact moment somebody needs to know why a domain is silent.
- **refused is a fact about this runner, not that host.** No ratio is ever computed over unreachable, ambiguous or refused hosts.

### workspace-deps (Estate instrument)
URL: https://flashy.tools/tools/workspace-deps

Install: node tools/workspace-deps.mjs [--fix] (flashyos)
Source: flashyos/tools/workspace-deps.mjs

Finds internal semver ranges a version bump has silently outgrown — the failure that is green on a laptop and red only on a clean CI checkout.

Bump a workspace package across its caret boundary and every consumer still pinned at the old range names a range the workspace cannot satisfy. npm ci does not fail: it fetches the last matching version from the registry, stale and missing the new exports, and links that instead of the workspace beside it.

Edge cases, each paid for once:
- **workspace:* would fix this and cannot be used.** npm 10 ships the protocol unrewritten to the registry, breaking external installs. Published ranges must stay real semver — which is exactly what drifts, so the doctor runs offline in every test pass.

### route-liveness (Estate instrument)
URL: https://flashy.tools/tools/route-liveness

Install: runs inside graph.yml; badge read from liveness.json
Source: flashyos/tools/route-liveness.mjs

A badge is a measurement, not a decision: LIVE is granted by a URL answering over the network, the way a stranger would reach it — never typed by hand.

Each route names proves, the URL that by answering makes the page live. badge survives only for claims no URL can settle (IN DESIGN is a decision, not a state of the world), and a route carrying both is refused.

Edge cases, each paid for once:
- **Live means the thing answered, not that it liked the question.** response.ok called a POST-only endpoint dead because GET returned 400 — a service that is up rejecting a malformed request. Anything but 404, 5xx or connection failure counts; a 401/403 is a service refusing, which is a service that is there.
- **A run that reached nothing keeps the previous answer.** Publishing "the whole estate is down" from a sandbox whose egress denies CONNECT is a measurement that never left the machine.


## Shared configs (1)

### @flashyos/eslint-config (Shared config)
URL: https://flashy.tools/tools/eslint-config
Version: 0.1.0 (audit of 2026-10-04)
Install: npm i -D @flashyos/eslint-config
Source: flashyos/packages/eslint-config

The estate’s shared lint base. Extending it costs three lines, which is why it exists: nine properties never adopted a linter while adoption meant writing a flat config from scratch.

Two entry points, because eslint-config-next is a real dependency and static generators must be able to extend the base without installing Next to do it.

Edge cases, each paid for once:
- **A check written in a framework the repository does not install never runs.** Two properties had no test runner at all, so nothing could have reported their broken charters. They run node --test now — no dependency. The same rule applies to lint configs.