@rsc-kit/mcp 0.29.5 → 0.29.6

package/guides/deployment.md

@@ -224,11 +224,72 @@ Three rules apply to all of them:
 - `RSC_HOST_CALL_SECRET` - the renderer and the backend must change together.
   Between the two, every `rpc()` is refused, so deploy both at once.
 - `RSC_SIGNING_SECRET` - pages already open hold names signed with the old
-  key; their watching is refused and they stop refreshing until reloaded.
-  Nothing else breaks.
+  key. Set the old value as `RSC_SIGNING_SECRET_PREVIOUS` for the deploy that
+  rotates it: it is accepted when checking a signature and never used to make
+  one, so open tabs keep refreshing while every page rendered after the
+  rotation carries the new key. Remove it a day later. Without it, those tabs
+  stop refreshing until reloaded; nothing else breaks.
 - `RSC_ACTION_ENCRYPTION_KEY` - an action called from a page loaded before the
   change fails, the same window as a deploy without the key pinned.
 
+## What the build produces
+
+A deploy that plans before building - a binary or a folder, which script to
+run - asks first:
+
+```sh
+bunx rsc-kit info --json
+```
+
+It loads the app's own Vite config the way a build does, so an `output`
+computed in the config, or `RSC_OUTPUT=export` in the environment, resolves
+exactly as the build will resolve it. Then every build writes the same
+answer to `.output/rsc-kit.json` as it finishes - the confirmation, from the
+code that decided; refuse a deploy where the two disagree:
+
+```json
+{ "version": "0.29.6", "output": "server", "compile": "compile", "binary": "dist/app" }
+```
+
+```json
+{ "version": "0.29.6", "output": "export", "dir": "dist" }
+```
+
+- **`output: "server"`** - run the server. `compile` and `binary` are there
+  when the app's `package.json` has a `compile` script: run it, and the file
+  its `--outfile` names is the single binary to ship.
+- **`output: "export"`** - `dir` is the static site; serve it as files.
+
+A build carries no backend address and no secret. `RSC_BACKEND`,
+`RSC_HOST_CALL_SECRET` and `RSC_SIGNING_SECRET` are read when the server
+runs, so one build runs against whichever backend its deployment names, and
+rotating a secret is a restart, not a rebuild.
+
+## Is it ready
+
+`GET /_rsc/health` says whether this renderer can serve, for a platform
+deciding when to route to it - which an open port alone does not say:
+
+```json
+{ "ok": true, "version": "08f805d3", "backend": "ok" }
+```
+
+- **200** - up. `backend` is `"ok"` when the backend answered, `"none"` for
+  an app without one.
+- **503** - the backend did not answer within 2 seconds: unreachable, or
+  refusing the secret.
+
+Why it is not ready names the app's insides, so the reason and `backend` go
+only to a probe that sends the host-call secret, as `x-rsc-host-secret`.
+Anyone else gets `{ "ok": true }` or `{ "ok": false }` and the status - which
+is all a router needs. Not keyed on localhost: behind a reverse proxy on the
+same machine, every visitor is localhost.
+
+The backend check asks the route guards with none to run - every adapter
+passes an empty list - so it runs no app code and reads no data, yet it
+proves the address, the network, the shared secret and the adapter. Never
+cached; `HEAD` answers with the status alone.
+
 ## Pages across a deploy
 
 A page from the previous build asks for a payload from the new one, whose

package/guides/your-own-backend.md

@@ -227,7 +227,9 @@ with the status and the `error` message. Only a deliberate refusal carries a
 `refusalStatus`: a crash leaves it out and is answered 500.
 
 Run them in order, outermost first, and stop at the first refusal: an outer
-guard saying no means the inner one should never have been asked.
+guard saying no means the inner one should never have been asked. An empty
+list passes - `{ "result": true }`: it is what the renderer's health check
+asks, to prove the backend answers without running anything.
 
 ## Saying data changed
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rsc-kit/mcp",
-  "version": "0.29.5",
+  "version": "0.29.6",
   "description": "An MCP server over what an rsc-kit build decided: the routes, why each one is static or not, and what it costs the browser.",
   "type": "module",
   "license": "MIT",
@@ -34,7 +34,7 @@
   },
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.30.0",
-    "create-rsc-kit": "^0.29.5",
+    "create-rsc-kit": "^0.29.6",
     "zod": "^3.25"
   },
   "devDependencies": {