Skip to content

docs(entitlements): document the digest the billing service actually computes - #100

Open
pythonlearner1025 wants to merge 1 commit into
mainfrom
fix/corpus-digest-recipe
Open

docs(entitlements): document the digest the billing service actually computes#100
pythonlearner1025 wants to merge 1 commit into
mainfrom
fix/corpus-digest-recipe

Conversation

@pythonlearner1025

Copy link
Copy Markdown
Member

The README recipe and the only code that verifies corpus.sha256 were two different algorithms over two different file sets. Each was self-consistent, so neither looked wrong.

README recipe (before) blitzos-billing test/billing.test.ts
Files *.json only every file except corpus.sha256, so README.md too
Separator none \0 between every part
Shape name₁‖bytes₁‖name₂‖… name₁‖NUL‖bytes₁‖NUL‖name₂‖…

Both reproduced their own repository's checked-in value, which is exactly why the drift was invisible.

Which one is right

The billing test is the only thing that reads this file — nothing in this repository verifies it. So its algorithm is the definition, and the recipe was the part that was wrong. The README now carries a transcription of that test and says outright that it is one, so the next person knows which side to fix if they disagree.

Why README.md belongs in the digest

Because it makes the check mean what it claims. The billing test is titled "keeps the copied entitlement fixtures byte-identical to core", and the copy includes the README. With every file in the digest, two byte-identical directories hold the same value — so the digest is now a cross-repository identity, not a per-repository self-check.

corpus.sha256 is regenerated under the documented algorithm:

ca619ff2ba7597717cfb235effa5014e280e96f020c2bec064eb5a5a1b8fdca6

blitzdotdev/blitzos-billing#4 syncs the copies so its digest lands on the same value.

Verification

The recipe in the README reproduces the checked-in file. test/entitlements-fixtures.test.ts passes (16), and the .json fixtures themselves are untouched here — only README.md and corpus.sha256 change.

Still open: nothing in this repository verifies corpus.sha256, which is why it drifted in the first place. That gap is unchanged by this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01J6fUBY1B27EzvDwbhfBf52

…computes

The README recipe and the only code that verifies corpus.sha256 were two
different algorithms over two different file sets, and each was self-
consistent, so neither looked wrong.

The recipe hashed the .json fixtures with no separator between the parts.
The billing service's test/billing.test.ts hashes EVERY file in the
directory except corpus.sha256 -- README.md included -- as name\0bytes,
joined by \0. The billing test is the only reader, so its algorithm is the
definition and the recipe was the thing that was wrong.

The recipe is now a transcription of that test, and says so, including that
nothing in this repository verifies the file. Including README.md is what
lets both copies hold the same digest when they are byte-identical, which is
what the billing test claims to check.

corpus.sha256 is regenerated under the documented algorithm:
ca619ff2ba7597717cfb235effa5014e280e96f020c2bec064eb5a5a1b8fdca6

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J6fUBY1B27EzvDwbhfBf52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant