1.0.0

Two backlogs: the release scope, and what the work turned up.

Backlog 1 — release scope

Planned work. An item is only here if it loses data, breaks a promise on a public surface, or stops a stranger installing and running the thing. A ticket that reaches Done carries the version it shipped in.

13 done, 4 in progress, 10 to do. Replication is complete: a sapedbd can follow another one, survive being killed mid-stream, and refuse writes with a reason. SAPE-14 has landed, so a collection can be declared against a running daemon — from the CLI, all three clients and the desktop workbench — and it no longer blocks SAPE-11 or SAPE-12.

This table said Done for four tickets that are not, and all four were caught the same way: by reading what the ticket asks for.

SAPE-15 and SAPE-16 — the learn site and the front page — have said In progress on their own pages the whole time, while this table said otherwise. Their criteria are plainly unmet: SAPE-16's first one is a person opens the page in a browser and reads it, and its own text answers "nobody has done this". Measured tonight and worse than that: dig A sapedb.com and dig A learn.sapedb.com both return nothing, from two resolvers. The domain is registered; neither name points anywhere. The pages are written, and no stranger can reach either of them.

SAPE-3 and SAPE-4 are waiting on one command nobody here may run. The whole release pipeline has now executed on a real runner, end to end: binaries for four platforms, checksums, every artefact proved to carry its version stamp rather than dev (the linux one by running it), the container image built, started and connected to — welcome's productVersion matches the stamp — and then all three publishing steps skipped, because a manual run resolves publish: false. Each of those checks has also been watched fail on purpose. SAPE-4 was briefly marked Done here; four of its five criteria need a tag that has actually been pushed, including the one it calls the bar — an artefact downloaded onto a clean machine and executed there.

Backlog 2 — issues found while working

Opened by the work in Backlog 1, not planned before it. Each one is triaged once: Fix in 1.0.0 only if it loses data, breaks a public promise, or blocks installing and running; otherwise Defer, and it goes to planning for the next version. The triage column is the decision, not a guess at how bad it feels.

How an issue gets triaged

One question, asked once, and written down: does it lose data, break a promise on a public surface, or stop somebody installing and running the thing? Nine of thirty answer yes, and one — ISS-22 — is not mine to answer at all, because it is a security posture that freezes at the tag. The rest are real, some are embarrassing, and they wait: a backlog that grows as fast as it shrinks has no answer to is it done yet.

The rule also has to stop things that sound like defects. One report this week said the operator shell silently swallows the catalogue error at startup, which is literally true. Reading the surrounding code showed the discard is deliberate and explained — it feeds tab completion, and guessing names would be worse than silence — while ls, in the same file, reports the refusal properly. No ticket was opened. A rule that only ever adds is not a rule.

ISS-12 is the cautionary one. It sat here marked open after the work had been done, and was then used as evidence — twice in one sitting — to write a public claim that was false, the second time while correcting the first. A ticket is a record of what somebody found on a day. It is not a measurement of what is true now.

ISS-29 is the best thing on this page. It was found by ISS-28 within an hour of CI existing: a gate guarding a Done ticket had been measuring the number of cores in the machine and reporting the answer as a verdict about locks. The replacement counts how many reads are inside the database at once — an exclusive lock cannot reach two on any number of cores — and on the very runner that had been failing, it found four reads inside the database together, in three milliseconds. The code had been sharing all along. Only the gate could not see it.

What 1.0.0 freezes

A version number here is a promise that cannot be withdrawn. From the tag onwards these four surfaces are fixed: the on-disk format, the wire protocol (frames 1…13 never change role; fields may be added, never renamed or removed), the meaning of a declaration, and the public API. It does not promise performance, the ordering of reads against writes, the file layout inside a partition, or anything under internal/.

Frame 14 is now spent: SAPE-14 took it for establish. The next frame anyone adds starts at 15. The public Go surface is 39 names and follower mode added none of them — everything it needed lives under internal/.