apps.arnao.ai — one manifest, one registry, one console

One line: every app in the fleet gets a tiny manifest (design tokens, flags, auth, budget, analytics, category, expiry); one registry reads them all; machines enforce it — deploy gate, nightly grader, auto-filed fix issues, a shared spend gateway — with a governance tab in command.arnao.ai for Byron and a rebuilt public index for everyone else.

Why it isn't reinventing the wheel: this category exists — it's called an internal developer portal (Spotify's Backstage invented the shape: a service catalog fed by per-repo manifest files, plus scorecards). The wheel to steal is the manifest + catalog + scorecard pattern. The wheel not to install is Backstage itself — see prior art below.

---

The audit that makes the case (run 2026-07-16, all data in fleet-scan-20260716.csv)

The fleet-audit daemon knows 142 root sites. I scanned every one of them tonight:

Plus: 19 sites are dead or broken (404/timeout/store-brand redirects), 11 of them already flagged dead in the registry but still occupying DNS and mindshare. The registry itself says the fleet is 85 demos, 14 platforms, 11 personal, 10 research, 9 publications, 8 tools, 4 fleet consoles.

Read that table honestly: the fleet has a 97% floor on accidental consistency (viewport, because every scaffold includes it) and a 1–8% ceiling on deliberate consistency (analytics, tokens, indexing policy). The difference between those numbers is exactly what a manifest-and-scorecard system fixes: consistency has to be enforced at creation time by tooling, because 142 sites will never be hand-migrated.

The cleanup, sized: 37 active non-demo sites need the Plausible tag (scripted, one pass); ~100 demo/mockup sites need noindex (scripted); 19 dead sites need retirement (delete DNS + Vercel project, or a fleet-standard tombstone redirect); full token adoption is realistic only for the ~46 active non-demo properties — old demos get analytics + noindex and are otherwise left as historical artifacts. Policy over archaeology.

---

The manifest — arnao.app.json, one file per app

Sits in the repo root; the deploy skill refuses to ship without it (new apps) or auto-drafts it (existing apps). Everything the fleet needs to know, nothing more:

{
  "name": "City Guide",
  "domain": "city.arnao.ai",
  "category": "platform",          // platform | tool | demo | publication | personal | research | fleet
  "status": "active",              // active | parked | dead
  "owner": "gia",                  // which agent maintains it
  "repo": "arnao/city-app",        // Gitea
  "design": { "tokens": "v2", "gestures": false, "pwa": true },
  "auth": "none",                  // none | google
  "budgetMaxUSD": 5,               // per-day cap — enforced by the shared spend gateway, NOT by each app
  "analytics": true,               // Plausible tag required
  "index": { "listed": true, "noindex": false },
  "command": { "tile": true },     // appears on command.arnao.ai
  "expires": "2026-10-14"          // review date; demos default to 90 days from creation
}

expires is the field that matters most — mortality by default. The fleet's real disease isn't inconsistency, it's immortality: 85 demos and 19 corpses exist because nothing ever has to justify continued existence. Every app declares a review date (demos default 90 days). When it lapses the nightly daemon doesn't nag — it acts: auto-tombstone, noindex, DNS queued for release, one renewal issue filed. Renewal is one line in a PR; death is the zero-effort path. With a TTL in the manifest, the dead-site count can never again exceed the renewal backlog — and the 2027 edition of tonight's cleanup never needs proposing.

Six of these fields already exist informally (name/category/status live in the fleet-audit registry; repo in Gitea; thumbnails cached). The manifest just makes the informal facts declared, versioned, and enforceable.

Enforcement points — ranked by how real they are today:

• Gate (real, with one precondition): vercel-deploy validates the manifest and injects the boring parts, so a new app cannot ship non-compliant. The precondition to verify before building anything: the choke point must be total — if any agent runs vercel deploy bare or any repo auto-deploys on push, the gate is a suggestion. Step one of the roadmap is auditing how the last 20 deploys actually happened and closing the side doors. And honesty about "injects the boring parts": the noindex header is genuinely one vercel.json block; the Plausible tag is a small matrix (static HTML vs. SPA vs. Next) — a solved matrix, but a matrix, not one line.
• Grade → push, not pull (real): the nightly fleet-audit daemon (already running at 06:15) diffs reality against every manifest and scores it. But the audit's own history proves visibility without an actor is decoration — the registry flagged 11 dead sites for months and nothing happened. So the scorecard's consumer is not Byron reading a dashboard: every failing check auto-files a labeled Gitea issue assigned to the owning agent, and the agent drafts the fix PR autonomously. Byron's recurring governance workload collapses to reviewing PRs in a queue he already checks. That's the actual advantage of being one person with an agent fleet, cashed in.
• Budget (fiction until the gateway exists — so build the gateway): a JSON field caps nothing; per-app self-enforcement means every app independently implementing metering, which will never happen. The honest design: one shared spend gateway — a thin proxy the API-backed apps (dictate, city, mentor) route their LLM/API calls through — reads the manifest and enforces budgetMaxUSD centrally. This converts the manifest's weakest field into its strongest: load-bearing runtime config, which is also the only durable answer to "the manifest nobody updates."
• Auth (aspirational, labeled as such): auth.arnao.ai is today a demo of "one sign-in for every arnao property." The auth field ships as declared intent and turns real when the shared module does — same Phase as the gateway. A flag pointing at a demo is the manifest lying at birth, so until then the scorecard renders it "declared, not enforced."

Two surfaces, deliberately unequal — a tab for Byron, a gallery for everyone else

An earlier draft split "ops" (command) from "governance" (a new apps console) — enterprise wisdom that doesn't survive contact with a solo operator, for whom ops and governance are the same question asked at the same moment: what's wrong with my stuff and what do I do about it? Two panes means one becomes real and the other rots. So, merged:

1. The governance tab — inside command.arnao.ai. One nightly-generated table (v1 is literally that, nothing more): every app, its manifest facts, its scorecard dots, its open issues/PRs from Gitea, its traffic sparkline. Filterable by domain / category / status / owner / score. The fleet-level bar — "analytics coverage 8% → 74%" — is the cleanup's progress metric. No four view densities, no product spec for users who don't exist; the consumers of governance are the agents (via auto-filed issues), and this tab is Byron's spot-check of the loop, one pane he already opens.

2. The public gallery — replaces index.arnao.ai. A different audience (visitors, recruiters, LinkedIn click-throughs) deserves the pretty surface: cards with cached thumbnails (134 already exist in the audit daemon), name + one-liner + tags, views: list / small grid / big grid, filterable by category and domain, fed by the same registry — only index.listed: true apps appear, so the 85 aging demos stop being the public face of the fleet. This is where the look-and-feel views belong, because browsing is what visitors do. The analytics rollup (Plausible per-site API calls merged nightly: by referrer, by geo, by app, by category — "which properties does LinkedIn traffic actually land on" as one chart) renders private-side in the governance tab; the rollup is the reward for the tag rollout.

The index cutover, sequenced (this couples to a Windows machine, so make it boring): (1) the new gallery ships and is verified, (2) index.arnao.ai becomes a trivially reversible redirect, (3) Zia's regeneration job is retired — in that order, and the nightly audit gets a "old index resurrected" check so Zia can't silently win a race it doesn't know it's in.

Git + backlog — yes, integrate; no, don't build a tracker

Gitea is already live (git.arnao.ai, 12 repos) and has project boards built in — kanban columns over issues, at repo and org level. The backlog IS Gitea issues on arnao/fleet-infra: every piece of fleet work (this proposal included) is an issue with labels (app:city, type:cleanup, type:feature) and milestones. One API reality check from research: Gitea's REST API fully covers issues, labels, milestones, and PRs but has no endpoint for the boards themselves — so agents and the console drive the backlog through issues + labels + milestones (fully scriptable), and the kanban board stays what it's good at: a human-facing view in Gitea's own UI, one deep link away. PR → issue → app → scorecard all join on the manifest's repo field. Building a custom tracker when the git host ships one would be reinventing the wheel inside the stop-reinventing-the-wheel proposal.

Skills — build four, reuse four

Reuse (already exist):

• vercel-deploy — gains manifest validation + auto-injection (the gate).
• fleet-audit daemon — gains manifest-diff scoring (the grader). It already discovers, screenshots, and registers.
• branding-console — content pipeline, untouched; the console links to it.
• dataviz — the analytics rollup charts follow its rules.

Build (small, in order):

1. app-manifest — draft/validate arnao.app.json; bulk-draft for all 123 live sites from registry + scan data (a day of agent work, not a month).
2. fleet-cleanup — the one-pass fixers: inject Plausible into the 37 priority sites, noindex the demos, tombstone the 19 dead. Each fix is a PR in the app's repo, not a silent mutation.
3. app-scaffold — new-app bootstrap: tokens.css v2, Plausible, manifest, Gitea repo, command tile, index entry — compliance by birth, which the audit proves is the only kind that sticks.
4. fleet-analytics — Plausible stats API → the pivot views (by app / referrer / geo / category).

Prior art — the wheel exists; here's which spokes to take

The category is the internal developer portal, and it converges on exactly the shape sketched above:

• Backstage (Spotify → CNCF) invented it: a software catalog harvested from per-repo catalog-info.yaml manifests (owner, type, lifecycle — the vocabulary arnao.app.json borrows), golden-path software templates (= app-scaffold), and scorecards via Soundcheck / Tech Insights. Do not install it: it's a TypeScript monorepo you operate as a product, with realistic estimates of 2–4 dedicated engineers and analyses concluding that under ~50 engineers the overhead outweighs the benefit. For one person, the concepts are the value; the software is a liability.
• Cortex, OpsLevel, Port — enterprise SaaS portals whose defining shared feature is the scorecard: machine-checkable rules graded per service, grouped into maturity levels (comparison). Months-long implementations, enterprise pricing. Steal the scorecard model; skip the vendors.
• The thin end of the market is empty. Roundups of Backstage alternatives surface only heavier platforms — there is no maintained "tiny catalog for 15–150 static sites." That niche is, literally, a JSON file plus a static page. Which is why building thin here isn't reinventing a wheel; it's right-sizing one that only ships in monster-truck.
• Design tokens have an actual standard now: the W3C DTCG format (stable since Oct 2025), compiled by Style Dictionary into CSS custom properties. One tokens.json in a shared repo → one generated fleet.css every compliant app imports. The design.tokens: "v2" manifest field points at a version of that, not at a vibe.
• Manifest precedent: Heroku's app.json for deploy/governance spirit, catalog-info.yaml for shape, PWA manifest.json for the browser-facing identity subset. arnao.app.json is those three, minus everything a 142-site personal fleet doesn't need.

Verdict, stated plainly: adopt the manifest + scorecard + token-standard concepts; install nothing new; build the thin console. One correction from research that changes a detail below: Plausible's cross-site "consolidated views" is a paid cloud-plan feature — the self-hosted CE instance the fleet already runs exposes a per-site stats API with referrer/geo/source dimensions, so the console's fleet rollup merges N per-site calls (cached nightly), which at this scale is trivial. If that ever bites, umami is the open-API fallback — a migration decision for later, not now.

Roadmap — cleanup before console, and the order is the argument

The "console as forcing function" theory requires a mechanism that converts visibility into action — shame, a manager, social pressure. Those work on teams. Solo, the experiment already ran: the audit daemon has surfaced this drift nightly for months and coverage sat at 8%. A console over today's fleet is a wall of red dots — a monument, not a forcing function. And the dependency graph agrees: the console reads manifests (don't exist yet), renders analytics (8% coverage = an empty room), shows scorecards (nothing to score). So:

• Phase 0 — prove the choke point (an evening): audit how the last 20 deploys actually happened. Every path that isn't vercel-deploy gets closed or instrumented. No gate, no system.
• Phase 1 — facts on the ground (a weekend, scripted and bounded): manifests bulk-drafted for all 123 live sites (including expires dates); cleanup executed as PRs — Plausible into the 37 priority sites, noindex across the demos, the 19 corpses tombstoned; grader + auto-filed issues live in the nightly daemon. Analytics coverage 8% → ~74% on active sites, and the push loop (fail → issue → agent PR → Byron review) starts breathing.
• Phase 2 — the money and the door (the real engineering): the shared spend gateway enforcing budgetMaxUSD centrally for the API-backed apps; auth.arnao.ai promoted from demo to the fleet's actual Google sign-in module. These two are what make the manifest load-bearing at runtime.
• Phase 3 — the surfaces (last, small, over clean data): the governance tab in command.arnao.ai (one nightly table); the public gallery replacing index.arnao.ai with its list/grid views; the analytics rollup. Built last so they render facts, not nulls.

The honest risks

• The manifest nobody updates is the standard death of catalogs. The durable mitigation is Phase 2: once the gateway and auth read the manifest at runtime, a stale manifest breaks something visible the same day. Until then the grader + auto-issues carry the load — enforcement by machines, never by memory.
• The governance system becomes site #143. The design defends against its own author: nothing in the steady state requires visiting a dashboard — the loop is push-based (issues assigned to agents, PRs into a queue already reviewed). Anything that depends on a new human habit was cut in critique.
• Migrating 85 old demos to tokens would be archaeology. Don't. Policy applies forward; old demos get the two-line fixes (analytics, noindex), an expires date, and are otherwise historical artifacts.
• Zia coupling. The index cutover has a Windows-side dependency; it's sequenced, reversible at step 2, and watched by a resurrection check in the nightly audit.

Mockups — real data, simulated loop

Both mockups run on the real 2026-07-16 audit data (141 registry apps, live scan results, the daemon's actual screenshots) so they show facts, not lorem ipsum. Simulated fields (owner, expiry clocks, issue counts, traffic) are labeled as such on-page.

• governance.html — the tab inside command.arnao.ai: coverage bars with Phase-1 targets, the one nightly table (scorecard dots MF·AN·NX·TK·CM, expiry clocks with LAPSED states, per-app issues, traffic sparklines), filters, and the push-loop feed showing the mechanism: grader files issue → agent opens PR → Byron merges.
• gallery.html — the public face that replaces index.arnao.ai: real screenshots, list / small / big views, category chips, search, demos hidden by default (index.listed in miniature).

Self-critique — Fable adversarial pass

Ran through Fable 5 as a ruthless critic (solo-operator realism / scope integrity / enforcement design), full text in fable-critique-20260716.md. It restructured the proposal:

• "The audit indicts the author" — the registry flagged 11 dead sites for months and visibility changed nothing; pull-based dashboards die here. Fix: the whole system inverted from pull to push — scorecard failures auto-file Gitea issues assigned to owning agents who draft fix PRs; the console is a spot-check, not the mechanism.
• The two-console split was org-chart cosplay — for one operator, ops and governance are the same question. Fix: merged; governance is a tab in command.arnao.ai. The public-facing index replacement survives because that's a genuinely different audience.
• budgetMaxUSD was "a comment with delusions" — per-app self-enforcement never happens. Fix: the shared spend gateway is now Phase 2's centerpiece; the field is enforced centrally or it's nothing.
• The auth flag pointed at a demo — the manifest lying at birth. Fix: labeled "declared, not enforced" until the module is real, same phase as the gateway.
• "A weekend" phases estimated, the real engineering hand-waved. Fix: Phase 2 named as the real project; the surfaces demoted to last, built over clean data.
• Console-first was governance as vanity. Fix: cleanup-first ordering, argued in the roadmap itself.
• Its bold idea — mortality by default — is now the manifest's most important field (expires): demos die at 90 days unless renewed by a one-line PR; entropy does the janitorial work.