Closes #27. Also closes #37, which I am closing as superseded with a comment saying where each of its parts went.
Three commits: the section, the fonts, and three smaller things that were not true.
The section
The page asked people to grant Full Disk Access and let an agent run on their Mac unattended, and never said approvals are off. Someone deciding whether to install it could not find out what a text is allowed to do without reading the source.
Two columns before the download button:
What a text can do. Approvals off, bypassPermissions for Claude Code and bypass for Codex. Unattended read, write and execute with your permissions. And therefore that an unlocked phone with access to the allowed thread can command the Mac.
What cannot reach it. iMessage only, because a forwarded SMS sender id is spoofable through a bulk gateway and the other side of that door is an agent with approvals off. One-to-one only. Handles you allow. Nothing stale.
The data flow links to /privacy rather than restating it. It is already written there, better, and two copies is two things to keep true the next time the engine set changes.
Two claims the issue asked for that I did not write
"No stacksjs server is involved" and "no account". Both are false since licensing. license.ts POSTs to uplink.stacksjs.com at launch and every six hours, and Uplink holds your email and Stripe's customer and subscription ids. The section says what actually happens, including the licence check and its cadence.
The existing "No server in between" line said the same false thing, so it is rewritten rather than left next to a section contradicting it.
The fonts
Every page fetched its stylesheet from Google Fonts and preconnected to its CDN, so every visitor's IP address and browser reached Google before a word rendered, on a site whose privacy page is about your texts staying yours. Two families, latin and latin-ext, 92 KB, two weights preloaded.
The issue's acceptance criterion greps resources/views/, which would have passed without touching anything. The links moved into resources/partials/site-head.stx when the head became shared, and there was a second copy in resources/views/404.stx, which writes its own head. The grep covered neither. A grep across all of resources/ now returns nothing.
Three smaller things
config/analytics.ts declared Fathom with a real site id while /privacy says the site loads no analytics. Nothing injects either, so the page was right and the config was the thing to fix.
.env.example documented every UPLINK_* variable except the one that decides how much the agent may do without asking.
/privacy said "Your Claude Code token", which has been half the story since Codex landed.
Verification
Rendered and checked:
security section -> true
power items rendered -> 3+
limits items rendered -> 4
links to /privacy -> 3
404: self-hosted -> 4All four woff2 files are valid WOFF2 by magic bytes. 163 unit tests, buddy lint, buddy typecheck and stx typecheck on index.stx clean, no em-dashes or en-dashes.
One limit on the above. stx build drops the shared partial's entire <style> block, so the @font-face rules do not appear in a local render of index.html, while 404.html shows all four because it has its own inline head. The same render drops ld+json, canonical and og:image, on main as well as here, and the live site has all of them. So the partial's <style> is confirmed by the deployed page rather than by a local build. I only changed that block's contents, not its position.
🤖 Generated with Claude Code