the site sections open, because there is finally something behind them

`ready` was hardcoded false for as long as the sections proxied to an address
nobody could set — the connection form was removed and nothing replaced it, so
nine doors led to the same "not connected" message.

Both halves exist now and neither is typed by a person: the development server
runs on a port this plugin chose, holding a FOFOS_API_TOKEN this plugin
generated and handed it at start. So the credentials are DERIVED rather than
stored. Asking somebody to copy a value out of one part of this plugin into
another was never a setting, it was a chore.

Development and not production, and that is not a preference. Production is a
directory of files behind nginx — no API, no database, nothing listening — so
editing against it is impossible rather than merely wrong. Sections read and
write dev; Build is what publishes. An edit is visible immediately and public
only when somebody decides it should be.

The gate asks whether the server ANSWERS, not whether pm2 says online. `bun
--hot` survives a crash at startup: the process stays up, pm2 reports online,
and nothing is listening. Opening nine sections onto that would make one failed
boot look like nine broken screens.

And when /status itself cannot be reached, `configured` stays true while `ready`
goes false. Telling somebody they have set nothing up is alarming and wrong;
opening nine sections onto a server we could not confirm is answering is nine
screens that each fail separately. Cannot-tell keeps them shut and lets the next
poll open them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

web/useReady.ts

@@ -19,11 +19,11 @@ import { useFofosChanged } from './channel';
  * nothing behind any of them; offering nine doors onto the same "not connected" message taught nobody
  * anything and made a setup step look like nine faults.
  *
- * ── Hardcoded false, deliberately, for now ──
+ ── It is answered by the server ──
  *
- * The shape is real and the plumbing is real: it asks `/status`, it re-asks whenever the connection
- * changes, and it reports while it is still asking. Only the final verdict is pinned, so turning the
- * gate on is one line rather than a feature.
+ * This was pinned to `false` for as long as nothing was behind the sections. What changed is not this
+ * hook: the site's admin API is served by the development server, which this plugin now starts on a
+ * port it chose with a token it generated. So there is something to ask about, and `/status` asks it.
  *
  * ── Both panels call this, so `/status` is fetched twice ──
  *
@@ -33,13 +33,13 @@ import { useFofosChanged } from './channel';
  * here rather than hidden in a wrapper. If the condition grows expensive, that is the moment to fix
  * it, not before.
  *
- * What it will become is roughly `configured && lastProbeOk` — the connection is stored AND the last
- * probe reached fofos — but "all the info needed in Administration" is not settled yet and will grow
- * past those two. That is why this returns a single boolean and not the parts: callers must not start
- * assembling their own version of the condition out of the pieces.
+ * It returns a single boolean and not the parts, and that still matters: callers must not start
+ * assembling their own version of the condition, because the condition has already changed shape once
+ * — from "a stored HTTP connection" to "the development server is answering" — and every caller that
+ * had built its own would have been quietly wrong on the day it did.
  */
 
-type Status = { configured: boolean; lastProbeOk: boolean | null; rootSet: boolean };
+type Status = { configured: boolean; lastProbeOk: boolean | null; rootSet: boolean; ready: boolean };
 
 export type Readiness = {
   /** The fofos connection works. Gates every section that READS the site. */
@@ -73,7 +73,15 @@ export const useReady = (): Readiness => {
         "you have not set this up", which is a far more alarming thing to be told and invites somebody
         to re-enter a connection that was never the problem.
       */
-      setStatus({ configured: true, lastProbeOk: null, rootSet: false });
+      /*
+        `ready: false` here, unlike `configured`, and the asymmetry is deliberate.
+
+        Being told "you have not set this up" when the request merely failed is alarming and wrong, so
+        configured stays true. But OPENING nine sections onto a server we could not confirm is
+        answering would show nine screens that each fail on their own — the honest read of "cannot
+        tell" is to keep them shut and let the next poll open them.
+      */
+      setStatus({ configured: true, lastProbeOk: null, rootSet: false, ready: false });
     }
   }, []);
 
@@ -81,10 +89,18 @@ export const useReady = (): Readiness => {
     void check();
   }, [check, signal]);
 
-  // ────────────────────────────────────────────────────────────────────────────────────────────────
-  // The gate. Replace `false` with the real condition — nothing else here has to change.
-  // ────────────────────────────────────────────────────────────────────────────────────────────────
-  const ready = false;
+  /*
+    The gate, and it is the server's answer rather than one assembled here.
+
+    It was `false` for as long as there was nothing behind the sections. The server now knows: the
+    development server is what serves the site's admin API, so `ready` is whether that is ANSWERING —
+    not whether pm2 says online, because `bun --hot` stays alive after a startup crash and would have
+    made one failed boot look like nine broken screens.
+
+    Computed there and not here on purpose. The note above says callers must not assemble their own
+    version out of the parts, and that applies to this hook too: one place decides, everything reads it.
+  */
+  const ready = status?.ready ?? false;
 
   return { ready, rootSet: status?.rootSet ?? false, loading: status === null };
 };