Why this platform works the way it does
The decisions behind the price, the refusals and the database — each one already written down before it was built.
Every post here is drawn from a document in this project's own record and names which one at the foot. Nothing is claimed that was not decided first, and no number appears that was not measured.
Routing is guessed one way and always reported
When a deploy leaves routing out, juudd calls a lone root index.html an app and everything else a static site, and the reply says which it chose and why.
A function is plain JavaScript, or it is refused
A function on a juudd site must be a .js or .mjs file. A .ts file is refused outright by name, with a rename that fixes it, before anything is stored or read.
A token says who is asking, not whose site it is
Every juudd tool that takes a site checks the caller's account first. A valid sign-in proves a request is genuine; it never decides whose site it touches.
The hostname is composed, not asked for
deploy_site no longer asks for a hostname. juudd composes it from the site id, refuses a value that disagrees, and reports where the site really answers.
A site remembers what it is for
A juudd site keeps a brief of what it is for. write_site_brief stores it, read_site shows it first, and earlier writings are kept, so rewriting loses nothing.
A site error is what we saw, not what it said
juudd's site_errors tool tells your assistant which routes failed, when and how often, from what the platform saw. It never reads what your function printed.
A refusal is written down in its own words
juudd records every refusal with the exact sentence the caller was given. list_refusals reads them back, so a new assistant never guesses why a deploy failed.
A tool list may gain, never lose
juudd never removes or renames a tool, never makes an optional argument required, and never changes what an argument means. Callers hold copies we cannot see.
Your assistant should not type your build output
A Vite, Next.js or Nuxt build reaches juudd through a one-time link and a short script, not a tool call. The post stores a version; publish_deploy goes live.
Stopping a site is not deleting it
A juudd customer can take a site off the air with one tool call. Visitors get a 404, nothing is deleted, and publish_deploy brings it back on the same version.
Your assistant never gets to see your API key
juudd has no tool that takes an API key. The assistant names the secret, you paste the value into the panel, and the platform keeps the name, never the value.
A table cannot go live without a row policy
juudd reads a site's schema at every deploy and refuses a table any visitor could read whole. Why the check is at the door, and the one thing it will not judge.
A bound is a refusal, not a 429
juudd limits how fast and how much one account can send, and says so in a sentence the assistant reads and the account's history keeps, never a bare 429.
What an MCP server should say about itself
An MCP server's annotations, descriptions and results are three separate promises. How juudd sets each one, and why two hints contradict their tool's name.
The exit is a tool, not a support ticket
Your code, your database and your domains each leave juudd by a call your assistant makes — with no deadline, and with six calls that keep working even on a suspended account.
Why we do not count requests
Neither plan meters requests or bandwidth, because a bot flood is traffic you did not cause — and we measured what absorbing one costs us: $3 per ten million.