Both clients are guarded by CI. The database at the centre of them is not.

Type

Process gap — the same one as ISS-25, at the centre instead of the edge

Found while

SAPE-3 / SAPE-4

Triage

Fix in 1.0.0 — argued below, because the rule alone says otherwise

Status

Open

Severity

Nothing is broken. The point is that nothing would say so

What was measured

• git log --all -- .github in the server repository returns exactly one commit — the release workflow added today. Before that the directory never existed. The server has never had CI of any kind.
• The TypeScript client has two workflows; the PHP client has one, added earlier today (ISS-25). Both exist specifically to prove those clients still agree with this server.
• The server carries four end-to-end suites that spawn real daemons — declare_live_test.go, subscribe_live_test.go, follow_live_test.go, version_live_test.go — across 19 test packages, plus a mutation-testing discipline the README calls the standard rather than the floor.
• None of it runs on a push. It runs when a person remembers to run it.

The sharp version

The release workflow does run go vet ./... and go test ./... — but it is triggered by a tag. So as things stand, the first automated run of this project's own test suite would happen during the release itself.

That is the worst available moment, and it is worse here than in most projects, because of what this backlog already says about tags: a tag is on the irreversibility list. A red suite discovered at that point is discovered after the one step that cannot be taken back.

Triage, with the disagreement shown rather than hidden

Does it lose data, break a promise on a public surface, or stop somebody installing and running? Read literally: no. The tests pass today; nobody is blocked; nothing published is contradicted. By the letter of the rule this defers, and a reasonable reader could stop here and disagree with what follows.

It is triaged Fix in 1.0.0 anyway, on one argument: the third clause is about installing and running, and a release whose correctness is first checked while it is being cut is not a release anybody can rely on having run. Every "Done" in Backlog 1 is a measurement somebody took once. Nothing re-takes them. The backlog's central claim — done is a measurement, not a judgement — quietly weakens every day that stays true.

It is also the cheapest item on either backlog. Two working examples already exist in this project, written this week, and the second one was built from the first.

What the fix has to include, learned the expensive way

Both existing workflows were paid for in mistakes that this one should not repeat:

• Fail when anything is skipped. A skipped test and a passing test produce the same summary line. The live suites here are gated on binaries being built first, so a mis-set path silently skips exactly the tests that matter most.
• Read a count the right way under bash -e. A grep that matches nothing exits 1, and inside a variable assignment that kills the whole step — including the fallback written to handle the missing count. This cost a red build today.
• Assume nothing about workspace paths. A clone placed "beside the checkout" landed on the checkout itself, because the repository is called sapedb. Also today.
• Race detector. Follower mode added a goroutine writing to a channel that Serve also writes to. -race was clean when that landed; keeping it clean is a machine's job, not a memory's.