docs: correct binary-size claim to <15 MB across README, landing and docs

[jkyberneees]

Summary

The binary-size figure published across the README and landing page was wrong, and it was wrong in six different places. This corrects all of them to a single honest claim: <15 MB.

Why it was wrong

The documented ~11 MB understates the shipped binaries:

Source	Measure
v2.16.0 release assets (gh release view)	darwin-arm64 12.75 MB · linux-arm64 12.45 MB · linux-amd64 13.31 MB · darwin-amd64 13.55 MB
Local build with the release flags (CGO_ENABLED=0, -ldflags "-s -w")	12.97 MB

The claim had drifted ~2 MB (~15%) before anyone noticed.

Why <15 MB rather than ~13 MB

A ceiling does not go stale the way an approximation does. <15 MB is accurate today (largest asset is 13.55 MB) and leaves headroom, so a small future increase does not silently turn the documentation into a false statement again.

What changed

Every location the claim appeared — found by sweeping the repo, not by fixing the one in the README:

File	Occurrences
README.md	1 (feature table)
GETTING_STARTED.md	1 (intro)
AGENTS.md	1 (binary descriptor)
docs/CHEATSHEET.md	1 (quick reference)
docs/llms.txt	1 (LLM-facing summary)
docs/index.html	8 (meta description, og:title, og:image:alt, twitter:title, twitter:image:alt, both JSON-LD blocks, hero size marker)
cmd/odek/telegram.go	1 (Telegram "Quick Facts" system prompt)

The telegram.go occurrence is the one worth calling out: it is a Go file, not a doc. The Telegram prompt contains a Quick Facts block that tells the model to quote the binary size to users, so leaving it would have meant the bot contradicting our own README. No test pinned that string.

HTML escaping

< cannot be written raw in an attribute value, so the approach differs by context:

• Attributes and body text → <15 MB, which decodes to the intended visible <15 MB
• Inside <script type="application/ld+json"> → a literal <15 MB, because character references are not decoded in script content and < would be emitted literally

Verification

• grep: 14 occurrences of the new claim, 0 stale claims repo-wide
• Landing page parsed with entity decoding: all five meta/og/twitter values decode to <15 MB; visible body text decodes to <15 MB; no < leaks into visible text
• Both JSON-LD blocks still parse as valid JSON and carry the literal claim
• HTML tag balance holds; docs/ is not embedded (//go:embed ui only), so this is a docs-and-string change with no binary-surface impact
• gofmt clean · go build ./... exit 0 · go vet ./... exit 0

Reviewer notes

• Scope: the brief was "README and landing page". I extended to the other four files because they carried the identical stale claim — fixing two of six would have left llms.txt telling LLM crawlers ~11 MB while the landing page said <15 MB. Say the word if you want that split out.
• Not touched: no test asserts this figure, so there is no RED-first test to add. If you want the claim pinned against future drift, that needs a new test that builds the binary and compares its size to a documented bound — happy to add it as a follow-up rather than smuggling a new test into a docs PR.

Also in this PR: .gitignore

The branch carries a second commit adding the pending .gitignore entry that keeps the local commercial brief (PITCH.html, PITCH.pdf) out of version control. Those files are a local, client-facing document — not product documentation — and must never be committed.

Verified before committing: .gitignore was the only staged path, git check-ignore -v resolves both files to this rule, and git ls-files | grep -i pitch is empty (nothing tracked).

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	odek	f557340	Commit Preview URL Branch Preview URL	Sep 14 2026, 09:05 AM