The daily progress report that checks itself — derived numbers, a page for people, a record the knowledge base ingests
This recipe is sealed: these exact bytes have not changed since it was published. A SHA-256 fingerprint of the source is committed to a public registry — change one character and it no longer matches, and this badge is gone. You don't have to take our word for it.
sporo seal, not typed by hand.curl -s https://raw.githubusercontent.com/ydnikolaev/sporo/main/recipes/derived-progress-report.md | shasum -a 256The result equals the hash committed in the public registry ↗ — sha256:3e56659c0eba263efef352b71d5be9a3932655173100ec603a3cb1844667a7f5. Neither side is served by this site.
A convenience demo: your browser refetches the recipe and the registry from GitHub and recomputes the hash — it trusts nothing from this page. View source to confirm.
A recurring report is read by people who cannot verify a single figure in it, and later by machines that cannot parse the prose it is written in.
Readable before it runs — audit the prose, then let an agent build it on your stack.
What a reader receives is the exported form — this, with the adoption protocol appended. Every section below was distilled from one live implementation: its build record, its release history, its fix commits, and the scars only a real build leaves.
These two sections are the same in every recipe — `sporo export` appends them so the reader knows how to bring the capability into a repository the author never saw, and what to send back.
Adopt it here
This section is addressed to the agent that is reading this recipe inside its own repository. The recipe above knows the capability; only you know the ground. Do this before the first build step.
Probe, do not assume. For each thing the ground section says must be standing, go and look for it here. Do not reason about what a project like this "usually has" — read the repository. Then say, in one line each, what you found and what you did not.
Agree the outcome before you build. The recipe says what the capability can produce;
only your operator knows what it must produce here. Ask them, before the first build step:
which of the outputs are needed in this project, in what form, and which outside consumers
will read them. Do not assume every output transfers — a capability that emits three
artifacts at home may owe this project only one. And treat the bindings as law: a shape
marked **Binding: adapt** is yours to rename into this project's language; a shape marked
**Binding: exact** is not yours at all — something on the other side parses it, so confirm
with your operator that the consumer applies here, then copy it byte-for-byte — and check
your output against it mechanically, in this project's own CI, from this document alone (the
recipe tool's conform check does exactly that; if you cannot run it, validate against the
shape by hand and say so in your report).
Map the roles onto this repository's homes. The recipe names roles — the facts file, the collector, the optional target the project implements — because a path is the one thing that cannot travel. You own the other half: decide where each role lives here, in this project's own conventions, and write the mapping down where the next agent will find it (the project's configuration, not your context window). A mapping that exists only in the session that made it is a mapping that will be re-invented, differently, next week.
What is missing, propose — do not silently substitute. When a precondition is genuinely absent, you have exactly three honest moves, in this order:
- Create it, at the smallest size that works. The recipe's ground section says what shape it needs and why it is load-bearing; carry that reason across in the language of this project, not as an appeal to someone else's conventions. A precondition worth a ladder in the recipe is usually worth twenty lines here.
- Degrade, and label it in the output. If the recipe states a fallback, take it — and carry its label all the way into what the capability produces. A degraded source that is not labelled where the reader can see it is indistinguishable from the real thing, which is the failure the recipe was written to prevent.
- Stop and ask. If neither is available, say so before you build. A capability standing on a precondition that is not there produces confident output over rot.
There is no fourth move, and in particular: do not quietly reach for a weaker source that happens to be lying around. That substitution is how nearly every scar in every recipe began.
Do not import the author's structure. What transfers is the principles, the contracts, and the scars. The directory layout, the file names, the command names and the tool are the author's house, and copying them buys you nothing and costs you a shape that does not fit.
State the plan before you build. The mapping, what you will create, what you will degrade and how it will be labelled. That statement is the reader's only chance to correct you while it is still cheap.
Report back
A recipe improves in exactly one way: someone builds it somewhere else and says what
happened. Every scar in the document above is a debt paid by an earlier reader. When you
finish, send this back to whoever handed you the recipe. Open with the recipe's name and the
version: from its frontmatter — a report that cannot say which text it built floats free
of every fix it triggers.
- Stack — what you actually built it on, and which of the author's essential choices you kept, replaced, or could not honour.
- Degraded — every place you took a weaker path than the recipe asked for, what forced it, and the label it now carries in the output.
- New scars — the payload, and the reason this section exists. Anything that broke, that the recipe did not warn you about, as symptom → root cause → fix. A scar you hit is a scar the next reader does not have to.
- Wrong — anything the recipe asserts that turned out not to be true on your ground. Being contradicted by a build is the only way a recipe finds out it is stale.
- Arithmetic — the recipe names one live check that no gate can perform. Say whether you ran it, and what it said.
- Missing — the thing you had to invent because the recipe described it in prose and did not hand you the shape. If you had to design a contract, send it: it belongs above.
Keep it short. Five honest lines beat a report nobody writes.