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

@flashyos/delivery

The rungs between a merged commit and a thing somebody has

delivery/1 — the rungs between a merged commit and a thing somebody actually has. Published, distributed and linked are measured by fetching, never declared.

npm install @flashyos/deliverynpm ↗source ↗

Why it exists

Most organisations have a backlog and a changelog: what somebody wants, and what somebody merged. Between them is the gap everything falls into after the merge — shipped, published, distributed, linked — where finished work goes unread because nothing checks whether it actually arrived. This is the ladder across that gap, and the four rungs after the merge are settled by fetching rather than typed into a status field.

What it refuses to do
There is no verb that marks work published, distributed or linked — no function, no flag, no field. Those rungs move only when a fetch confirms them, so a green board cannot be typed in.

How it works

`delivery/1` is a seven-rung ladder from a filed intention to a thing another host points at — filed, committed, built, shipped, published, distributed, linked — with a line drawn across the middle. Everything left of the line somebody declares; everything right of it something checks.

The four measured rungs are settled by fetching, never by a status field. `shipped` is git saying the ref is reachable from the default branch; `published` is a fetch of the URL returning a body; `distributed` is the URL appearing in a machine surface the property publishes; `linked` is the URL appearing in a document served by a different host. `advance(item, { to: "published" })` throws and tells you to run `observe`.

A board is only worth reading if a green tick cannot be typed in, so moving the cheap action out of reach and the expensive one into automation is the whole design. For a repository with no package.json, a dependency-free `vendor-delivery.mjs` runs the same rules, and CI asserts the two agree.

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

Use it

File a deliverable, then let evidence move the ladder
npx delivery file the-thing --title "The thing" --url https://example.com/the-thing
npx delivery observe
npx delivery board

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.

delivery

In practice

Catch work that shipped but nobody can read
A team files each deliverable and runs observe; finished articles that git called shipped, sitting on branches no reader could open, surface as stuck at published rather than counting as done in a changelog.
Prove a page is actually linked, not just live
The linked rung only advances when the URL appears in a document served by a different host, so a page nothing else points at stays visibly one rung short instead of being marked delivered.

How it stays honest

The board cannot be faked because its four measured rungs are re-derived by fetching, not stored: observe fetches each URL, checks the machine surfaces a property publishes, and moves the ladder from what it finds. The dependency-free vendor-delivery.mjs is byte-checked against the package, so a repository with no toolchain runs the identical rules. Verify it yourself by running `npx delivery observe` and watching a rung refuse to advance until the evidence exists.

Questions

What is delivery/1?
delivery/1 is a seven-rung ladder from a merged commit to a thing somebody has — filed, committed, built, shipped, published, distributed, linked. The four rungs after the merge are measured by fetching, never set by a status field.
Why can’t I just mark work as delivered?
Because the cost of moving a card is zero and the cost of checking is not, so status fields drift. delivery has no verb that sets published, distributed or linked — those rungs move only when a fetch confirms them.
What do the four measured rungs mean?
shipped is git saying the ref is reachable from the default branch; published is a fetch of the URL returning a body; distributed is the URL in a machine surface you publish; linked is the URL in a document served by a different host.
Can I use delivery without a package.json?
Yes. Copy vendor-delivery.mjs into the repository and run it with node — the same rules in one dependency-free file, and CI asserts the vendored copy and the package agree, so the format travels where a toolchain does not.

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/frontdoor