Direction, ruled 2026-09-14: a host for ComputeDriven loci. The customer deploys a locus — the thing that carries state, granted authority and continuity across restarts. The machine under it is a carrier: rented, replaceable, never the customer's identity. The meter counts admitted transitions; utilization is printed everywhere and billed nowhere. The record is docs/spec/90_LOCUS_HOSTING.md. Nothing in it is built.
The rename is DONE, except the directory. Ruled and executed 2026-09-14.
| thing | was | is |
|---|---|---|
| domain | webhost.systems | locu.systems |
| GitHub repo | c-u-l8er/WebHost.Systems | `c-u-l8er/locu.systems` |
| nav property key | webhost | `locu` (amp-nav v0.13.0) |
| this directory | WebHost.Systems | `WebHost.Systems` — unchanged, on purpose |
The directory keeps the old name because renaming it breaks the root CLAUDE.md, .claude/launch.json, sync-nav.sh's EXTRA_TARGETS and any parallel session holding this tree open. It is now the only place the old name survives by design — if you find the old name anywhere else, it is stale.
The nav divergence this file used to describe is retired: lane N's source was edited in the same pass, so the menu now says locu.systems, tags it "A host for ComputeDriven loci" and links the new domain. The page's divergence block is gone with it. launch-gate.mjs still refuses in the other direction — if a vendored amp-nav.js ever carries the previous URL again while nothing is declared in the record, it will not publish.
There is no placement band, and that is a declared divergence from `agents/SHELL.md` §1 (ruled 2026-09-14 — four stacked bars above the masthead). Its rung chip and the sentence bounding what that rung covers moved into the status block. Removing it un-suppressed `amp-nav`'s own placement strip: BAND_NAME() draws one whenever the host page has no .band, and that version carries the previous name and no covers span, so src/shell.css hides it through the exposed place part and the <amp-nav height> attribute reserves the bar's height instead of bar-plus-strip. shell_divergence in records/surface.json records all of it and the gate enforces every half.
docs/spec/80_SERVICE_MANAGEMENT_PILOT.md proposed a different direction earlier the same day and is banded, not rewritten — its phase two became this ruling.
What is in the tree from the abandoned agent-deployment direction: a control plane for [&] Protocol agents (Postgres schema plus edge functions in the sibling ampersand-supabase/) and a Vite/React dashboard with a passing test suite. None of it executes anything — the deploy path writes a version row and marks the provider reference simulated.
index.html./index.html, /app.js, /app.css, /boot.js and /say.js are emitted by build-site.mjs from records/surface.json, records/evidence.json and src/. An edit to the served HTML is silently reverted by the next build. Change the record or the template, then run npm run site:launch, which emits the page and then runs launch-gate.mjs against the artifact. The shell is documented in ProjectAmp2/agents/SHELL.md; this surface is built against revision shell-r16, recorded as shell_revision in records/surface.json, and launch-gate.mjs refuses when this file and the record disagree.
site:build / site:gate / site:launch are not wired into build, dev or test — those belong to apps/web, a separate artifact.
/ serves the home view; #/ops/* and #/account/* are the console and the client portal, rendered by /app.js into #app. build-site.mjs emits five artifacts — index.html, app.js, app.css, boot.js, say.js — from src/ and the records. The home view is in the served bytes and `app.js` may never author it; app.css is scoped to #app so it cannot reach it; and its palette aliases the shell's tokens so one palette paints both halves. The standing notice sits outside #app. The panel's figures are invented — do not repeat them.
docs/spec/00_MASTER_SPEC.md — master engineering spec (self-contained, implementation-ready)
docs/spec/10_API_CONTRACTS.md — API contract details
docs/spec/20_RUNTIME_PROVIDER_INTERFACE.md — runtime provider abstraction
docs/spec/30_DATA_MODEL_SUPABASE.md — Supabase/PostgreSQL data model
docs/spec/40_SECURITY_SECRETS_COMPLIANCE.md — security requirements
docs/spec/50_OBSERVABILITY_BILLING_LIMITS.md — billing and limits
docs/spec/60_TESTING_ACCEPTANCE.md — test plan
docs/spec/70_AMPERSAND_PROTOCOL_INTEGRATION.md — [&] Protocol integration (capability manifests, MCP sidecars, A2A routing, governance)
docs/spec/80_SERVICE_MANAGEMENT_PILOT.md — the current direction: the service package as the unit, the first package (weekly website health report), the pilot in order and its acceptance test. Read this first; it says which parts of v1 it keeps, and its §6a is phase two (locus hosting) with the four gates it waits on.
docs/spec/adr/ — architecture decision records
docs/spec/progress/ — implementation progress logs
WebHost.Systems is the hosting layer for [&] Protocol agents. The §70 integration spec extends the v1 platform with:
ampersand.json manifest validation and storage
MCP sidecar orchestration (Graphonomous, TickTickClock, etc.)
Agent-to-agent skill routing (A2A)
Delegatic governance enforcement
Dynamic capability provider resolution
Hash-linked provenance in telemetry
Always read the master spec and relevant section before implementing features.
npm install # install all workspaces
npm run typecheck # TypeScript check across workspaces
npm run lint # ESLint across workspaces
npm run format:check # Prettier checknpm run dev # Vite dev server (apps/web)
cd .. && supabase start # Local Supabase from repo root (all ecosystem schemas)apps/web/ — Dashboard frontend (Vite + React + Supabase Auth)
packages/ — declared by the workspace glob and absent from disk. There
is no SDK and no CLI. The page build re-checks this every run and refuses if one appears without the page being updated.
src/, records/, build-site.mjs, launch-gate.mjs — the marketing page
WebHost.Systems uses the shared ecosystem Supabase at the repo root (/supabase/), not a local supabase directory. Its tables live in the webhost.* PostgreSQL schema.
Schema: /supabase/migrations/020_webhost_schema.sql
RLS: /supabase/migrations/021_webhost_rls.sql
Cron jobs: /supabase/migrations/022_webhost_cron.sql
Architecture: /supabase/ARCHITECTURE.md
Run supabase start from the repo root to start the full ecosystem DB.
Node >= 20 required
Supabase for backend — PostgreSQL + RLS + Edge Functions in root supabase/
Supabase Auth for authentication (shared across all [&] ecosystem apps)
Zod for runtime validation
TypeScript strict mode
ESLint + Prettier enforced
v0.0.0 — early stage, greenfield