All three clients and the desktop app now have CI, and each one builds the server from
main and runs against a real daemon. That is the right shape, and it only fires
when that repository is pushed. A push to the server changes what every one of them
talks to and starts nothing.
This is not hypothetical; it happened today and the timing is on the record. The PHP client's suite
was re-run at 17:32 and went green. It was re-run deliberately, to
check the client against the server as it then stood — and it cloned main from before
ISS-21 landed. The client was correct, the server had not changed yet, and
the green was accurate.
ISS-21 then landed. The PHP repository carried a deliberate tripwire for exactly that change, written months apart from the identical one in the desktop app and without knowing about it. It did not fire until the next time somebody pushed to the PHP repository, which happened to be an unrelated piece of work. Had nobody touched that repository, the client would have been quietly wrong against every server built after that commit, and its CI would have kept saying so in green.
Re-running a CI job and running CI on a new commit are different measurements, and the first one is the one that looks like the second.
Does it lose data, break a promise on a public surface, or stop somebody installing and running? No. Nothing is wrong today; every repository is green against the server as it now stands, checked by hand.
The fix — a server push fanning out to the dependents, by scheduled run or repository dispatch — is cross-repository automation with a standing cost: four repositories whose CI can now go red for something that happened somewhere else. That is the same shape as ISS-2, and the same answer applies: it is a decision about how tightly these repositories are bound together, and it should be taken deliberately rather than added because it was cheap at the time.
Worth separating from the desktop app's case, which is not this: that repository already
declares replace github.com/sapedb/sapedb => ../sapedb in its go.mod, so
it was already bound to whatever server sits beside it. Its CI made an existing dependency
reproducible. What is proposed here would create a new one.
A scheduled run — daily, on each dependent, against the server's current main
— costs nothing anybody has to think about and turns "quietly wrong until somebody pushes"
into "wrong within a day". It does not couple a server push to four other repositories' red builds,
which is the part with the ongoing cost.