Cloudmaven admin
This back-end reads the same repository the website is built from. Nothing here holds content of its own, which means it can be thrown away without the website noticing — and that is what makes it safe to build one surface at a time. What each surface is actually connected to is the first thing below, before anything gets a chance to look finished.
One line each. Connected means a figure computed at build time from a file in this repository, with that file named on the screen where the figure appears. It does not mean live: the crawl behind most of this was taken on 11 August and every page that uses it says so.
Reading the 11 August crawl and the Search Console export: 3 open findings, 3 closed by the rebuild, and every duplicated title and description listed in full. Not connected: 2 figures — the query mix and field performance — which are named as gaps and never printed as numbers.
Reading the manifest and all 286 page files: every ported page with its locale, title, description, word count and gate status, 0 failing and 138 carrying a live-site defect the port reproduced faithfully. Not connected: nothing on this surface — although two GATE 39 checks need the built HTML and say so.
Reading nothing, because there is nothing to read. All 8 metrics render as NOT CONNECTED with the system that would feed each — HubSpot, NetSuite or the service desk. 5 of them are blocked on a written decision rather than on a credential. No example data anywhere on the page.
Not built. It would show the claims register as a live board, the forty-four gates and which are failing, and what is deployed. The claims and gates halves need no new access; deploy status needs a Cloudflare token scoped to Pages:Read.
Each one answers a single question. If someone opens it and cannot answer that question in ten seconds, it has failed regardless of what else it shows.
What is actually wrong with our search presence, and what do I do about it?
3 findings still open, 3 already fixed by the rebuild, 2 the admin cannot see. Every row computed from the crawl and the Search Console export in this repository, and both duplicate lists rendered in full rather than as a top ten.
Open the SEO surface →Which page is this, what is on it, and is it clean?
All 286 ported pages in one list, filterable by locale tree, each linking to the page as built. Six per-page gate rules evaluated from the page data — 0 rows fail. 138 carry a defect of the live site that the port reproduced faithfully, which is Stage 1's worklist.
Open the Content surface →Who do I call on Monday, and what do I say?
The frame, with nothing in it. 8 metrics, every one rendering NOT CONNECTED, each carrying a paragraph on which system would feed it and what would have to be joined to what. No example account and no zero — a zero is a measurement and this surface has not made one.
Open the Install base surface →Blocked on a HubSpot private app token (portal 144001096, read scopes), a NetSuite integration record, an answer to which system the service desk runs on, and written definitions of "customer" and "live". Needed before 1 September.
Is the site currently shippable?
The claims register as a live board, the forty-four gates and which are failing, and what is deployed. The claims board already exists in src/components/ContentConsole.astro and moves across largely unchanged.
Deploy status needs a Cloudflare API token scoped to Pages:Read. The claims and gates halves need no new access at all.
Three decisions carry the whole thing. The reasoning behind each, and what every surface still
needs before it can be built, is in docs/admin/PLAN.md.