The PHP client tests against a pinned snapshot of the shared fixtures, taken from the
server's repository. That snapshot stood at a commit made before the server grew the
establish frame. Its types object therefore listed thirteen entries, and
FrameType::ESTABLISH could not be put in the hand-written comparison table without
reddening it against the fixture.
The workaround at the time was honest and inadequate in exactly the way it said it was: a test of its
own, checking the constant against a hand reading of internal/protocol/frame.go in
another repository. That proves the number is 14. It proves nothing about the contract, which is
the only thing a shared fixture is for.
Underneath it sat a second problem. The README told anyone refreshing the snapshot to run
npm install @ecosy/sapedb and copy the fixtures out of
node_modules. Measured: npm view @ecosy/sapedb answers
404 — that package is unpublished. The documented procedure would have failed
for every person who followed it.
49e6079f…); the PHP copy was a different file
(e9d9c676…).establish — nothing else in the file had drifted.signing.json was already identical across all three and was not touched.npm view @ecosy/sapedb → 404 Not Found.415c9d0 — the commit that last
changed fixtures/frames.json there, not merely the tip on the day of copying.establish moved into the hand-written table with the other thirteen; the separate
live-reading test is gone, and a note in its place says what it used to be for.cases list brought a real byte-level establish frame
— nested spec, a key, an index, an array — so the PHP encoder is now measured against
establish, not only the constant.
Verified in CI, not locally: there is no php on the machine this was
written on. That is not a footnote — it is why
ISS-25 had to be fixed first for this one to be checkable at all.