[sdcarlson]

What it shows

GET /admin/board, titled Mission Control, for holders of a new key, site:board.read ("See Mission Control: the board and telemetry"). Server-rendered with no script, under the existing CSP, in the staff layout and navigation. In order:

1. Live status, computed by the Function at each page load: eight checks of the other production hosts, run in parallel with a 3 s deadline each. Each shows as Up or Down with its status code and milliseconds, never a response body. syberlabs.io is not checked: it served the page.
2. Board: the MasterMind board (board.v1), read from KV binding BOARD, key board:v1. It says when the board was computed and how long ago, and warns once it is older than 36 hours, as board.v1 requires.
3. Telemetry, when the board carries the new telemetry key. Each metric shows its status (OK, Breach or Unknown), value and unit, owner, basis, threshold and reason, followed by the open incidents. An unknown metric shows "Unknown" and its reason, never its value field, so never a 0.
4. Summary counts, then Waiting on a key (open asks, soonest first), Gates, Recent decisions (newest first) and the Portfolio. Each repository gets a small chart of eight weeks of commits; each week's count is in its tooltip and in the chart's accessible label.

Every board string is untrusted and is escaped with the site's esc(). Links go only to GitHub, built only from an owner/repo name, a hex sha, a PR number or a GitHub issue URL that passes its pattern; anything else stays text. Unknown keys are ignored, and a value of the wrong type renders as absent. Long lists are capped (decisions 20, portfolio 60, asks and gates 40, metrics and incidents 20) and say "Showing N of M".

Mission Control appears in the staff navigation (first under Team) and on the launchpad, for holders of the key only.

How it degrades

situation	what the page does
no BOARD binding (today)	200: "The board is not connected." with the reason and the three steps below; live status still shown
binding, but no board:v1 key	the same, saying the namespace holds no board:v1 key yet
value is not JSON, or not an object	the same, saying the value is not a board.v1 JSON object
the KV read throws	200: live status plus a warning that the board could not be read just now; no exception text
the KV read hangs	the page gives up at 3 s, together with the checks, and shows the same warning
every check hangs	each check reads "No answer within 3 s"; the page renders in about 3 s (3.0 s through handle() in the test)
a check fails	Down, with what came back: "200, expected 503", "200 without serverInfo", "301, expected 200" (no redirect is followed) or "Could not connect"
board older than 36 h	"This board is stale: it is N old"
no valid generatedAt	a warning that the board's age is unknown
no telemetry key (today)	"This board carries no telemetry yet."

Live verification

The checks as server/probes.js sends them: no cookie, no Origin, User-Agent: SyberLabs-Mission-Control/1, redirect: manual. The four preview routes get a POST with no body. Each takes POST (Flyspace src/app/api/*/route.ts at 42785f9), answers 503 first in the preview, then refuses a request with no Origin, so a check cannot spend. The connector gets a JSON-RPC initialize with Content-Type: application/json and Accept: application/json, text/event-stream.

These results come from the branch's own runProbes(), run on 2026-10-31 from this session's machine (through its egress proxy). It ran in Node and inside workerd (wrangler dev with wrangler 4.141.0 from deploy/):

check	request	expected	Node, 02:44:21Z	workerd, 02:44:24Z
RISE Reader	GET https://rise.syberlabs.io/	200	200, 314 ms	200, 72 ms
RISE Composer connector	POST https://rise.syberlabs.io/api/mcp, initialize	200 with result.serverInfo	200 with serverInfo, 355 ms	200 with serverInfo, 61 ms
FLYSPACE preview	GET https://omni.syberlabs.io/	200	200, 269 ms	200, 74 ms
AI answers off	POST https://omni.syberlabs.io/api/llm	503	503, 270 ms	503, 66 ms
Persona suggestions off	POST https://omni.syberlabs.io/api/jev-persona	503	503, 270 ms	503, 57 ms
Capability broker off	POST https://omni.syberlabs.io/api/capability-broker	503	503, 263 ms	503, 59 ms
Search routing off	POST https://omni.syberlabs.io/api/registry-intent	503	503, 348 ms	503, 153 ms
RISE Sketch	GET https://sketch.syberlabs.io/	200	200, 263 ms	200, 193 ms

Three earlier Node runs at 02:32Z and curl at 02:18Z gave the same eight statuses. In workerd, a ninth check pointed at a local server that accepts connections and never answers ended at 3,001 ms as a timeout, while the other eight finished normally. readBoard against a real local KV binding in workerd returned unbound, missing, ok and malformed for those four cases.

Tests

• node --test 'server/test/**/*.test.js': 208 tests, 208 pass, 0 fail (192 before: 15 new in server/test/board.test.js and 1 new in migration.test.js).
• board.test.js covers:
  • Access: signed out gets a 303 to /auth/signin?next=%2Fadmin%2Fboard with an empty body. A session without the key gets a 403 naming the key's label. Neither runs a check or reads KV.
  • 200 for admin and for a custom role holding only the key. Nav entry, header name and launchpad card appear for holders only. HEAD gets 200 with no body.
  • No board: no binding (absent, or without get), a missing key, malformed JSON, [], null and a string each render "not connected" with the three steps, and the checks still run. A KV throw (async or sync) renders the warning, with no exception text and no steps.
  • A hostile board (script tags, quotes and attribute breakouts in every writable field, plus hostile repository names) renders escaped. The page's links are exactly the five legitimate GitHub URLs.
  • Freshness: no warning at 35 h; a warning with the age at 36 h 1 min and at 3 days 2 h; "age unknown" for a missing or non-ISO generatedAt.
  • Telemetry:
    • An unknown status, a missing reason or an unrecognised status shows Unknown and the reason, never a 0 or the unit.
    • OK and Breach show value, unit, owner, basis and threshold, and a known 0 shows 0.
    • Closed and resolved incidents are hidden. Absent or drifted telemetry renders its own line.
  • Shape drift: wrong types everywhere render as absent. Caps: "Showing 20 of 25" and "Showing 60 of 70", decisions newest first.
  • Checks:
    • The eight exact requests (method and URL): no cookie, no Origin, manual redirects, the user agent, no body except initialize. No response body reaches the page.
    • Down cases: a paid route answering 200, the connector without serverInfo, a 301 and a network error.
    • The connector answering as one SSE event counts as up.
    • With every check and the KV read hanging, the page renders in 3.0 to 3.5 s, each check reads "No answer within 3 s", and each request is aborted.
  • Units: hasServerInfo and repoName.
• migration.test.js: the file list now includes 0004_board.sql. On a database shaped like production (0001 to 0003, admins, a viewer with a custom role, entries, audit rows, a saved backup), 0004 adds exactly one permission row and one admin grant and leaves every other row unchanged. A second run is refused whole.
• Pins updated for the new key: admin now holds 7 keys (migration.test.js, guards.test.js), the admin launchpad cards (app.test.js), and the staff.css link version (views.test.js; the stylesheet is unhashed, so its link moves to ?v=20261031).
• node scripts/site-chrome.mjs --check: 16 pages up to date. node --test scripts/account-nav.test.mjs: 9 pass.
• Function built as CI builds it: npm ci --prefix deploy, then deploy/node_modules/.bin/wrangler pages functions build --outdir dist/_worker.js --compatibility-date 2026-10-01. It compiled, at 267 KB.
• Mutation pass on scratch copies. Each mutation below fails at least one test:
  • an unescaped ask question
  • any repository name linked
  • staleness at 48 h
  • an unknown metric showing its value
  • loose date parsing
  • answered asks shown
  • the KV read without its deadline
  • Down shown as Up
  • closed incidents shown
  • redirects followed
  • an Origin header sent
  • no race on the deadline
  • checks run one after another
  • the connector judged by status alone
  • serverInfo matched by substring
• Rendered in Chromium at 1440 px and 390 px under the response's own CSP: no CSP violations and no horizontal scroll.
• Not run locally: pnpm build:site and the QA sweep. No public page changes; CI runs both.
• CI on 55b2b18 (Cloudflare Pages run #485, Node 24): validate passed with 208 of 208 server tests, 9 of 9 account navigation tests, the chrome check (16 pages), the Function build, and the QA sweep (24 pages, 0 errors, 0 warnings). Deploy was skipped, as for every pull request. The GitHits dependency policy run passed.

Connect the board (Seth)

1. Seth creates a Workers KV namespace and adds its id to wrangler.toml as [[kv_namespaces]] with binding = "BOARD".
2. MasterMind gets the repository secrets CLOUDFLARE_API_TOKEN (with Workers KV Storage: Edit), CLOUDFLARE_ACCOUNT_ID and BOARD_KV_NAMESPACE_ID.
3. The daily ledger run then writes the board to board:v1, and it shows here.

This PR does not add the binding: no namespace id exists yet, and a placeholder would break production deploys. Until step 3 the page shows live status and these three steps.

One more step, needed once before anyone can open the page: apply migrations/0004_board.sql to the production D1 database syberlabs-accounts, the same way 0001 to 0003 were applied. For example, wrangler d1 migrations apply syberlabs-accounts --remote applies only the files it has not recorded. Until then nobody holds site:board.read, so /admin/board answers 403 for everyone and stays out of the navigation (fail closed). The migration adds one permission row and one admin grant and touches no other row.

Merging deploys production

Merging to main runs the Pages workflow, which builds and publishes syberlabs.io. There is no separate release step.

Keys and sign-offs

• Floor: node tools/ledger/cli.mjs floor origin/main...HEAD (MasterMind, pointed at this checkout) says auto: no protected surface touched, so this needs an independent Reviewed-by. wrangler.toml is untouched.
• Independent of Probe production every ten minutes; two failures in a row open an incident #187, Privacy: the account service's request counts and the Omni preview's logs #188 and Count each staff Function response as one site.request data point #189. It shares server/routes.js and server/CONTRACT.md with Count each staff Function response as one site.request data point #189, in different hunks.

Known limits

• The checks run from the Function on the syberlabs.io zone. Cloudflare documents Workers Custom Domains, which rise.syberlabs.io and omni.syberlabs.io are, as reachable by fetch from another Worker on the same zone. sketch.syberlabs.io is served by Pages. All three were checked from this machine (Node and workerd) but not yet from Cloudflare's edge. If a check reads Down in production while the host answers from outside, the same-zone subrequest rule is the first suspect.
• Every load sends eight requests, one of them an initialize to the RISE connector. The page is staff-only, so that is a few requests a day.
• The telemetry key and its incidents shape are not specified yet (MasterMind P7). For each incident the page reads title, check or id, then openedAt or since, owner, and a GitHub issue url. It counts an incident as open unless it has closedAt, or a state or status of closed or resolved.
• The board's objective, malformed and advice keys are not shown here; the MasterMind artifact page keeps them.
• GitHits was unavailable in this session (its MCP server did not start), so the KV API was checked against a real local binding in workerd instead.

https://claude.ai/code/session_01VHrJ4hmTtR1RFNpc215EK7

---

Generated by Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-31T02:47:31.985081Z	55b2b18	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.