The site as the build showing itself: what changes, in what order, and how each change is proven
The pages shipped this week break four of your laws, and the breaks are structural, not verbal
The outreach law forbids dollar amounts as enticement and copy that compensates for the offer; the shipped pages carried a rate card on every screen and headlines written to persuade. The writing law forbids a skeleton repeated across pages and a page that names its audience; the realtor and restaurant pages were one skeleton with the nouns swapped, and both named a buyer. The design law removes anything that does not aid clarity or give a material benefit; the floating emoji and the split-colour headlines gave neither. The writing law says the model is never the subject; on those pages the seller was the subject on every screen. Rewriting sentences will not fix this. The pages were built to sell, and your site is built to show. The fix is to change what the pages are.
What you asked for, restated so you can check I have it
The front of the site is the build itself, addressing a visitor. It shows the visitor what it already knows about their visit, from the same signals it uses to route traffic. It invites one small, reversible act, a text to a line, and shows that text landing as a receipt on the ledger within seconds, so the claim that every action is recorded is demonstrated rather than stated. It explains each thing it can do as a walked case with the record attached, not as a capability list. It explains the number options as mechanisms with their failure conditions: an existing number registered to iMessage, an assigned line, WhatsApp, Telegram. It carries no price list, because the reader should leave understanding how much can be done, not how much it costs. For a business the build has already written to, the site becomes the pitch you would make in person, end to end, with the work already done for that business on the page. The Console's Ledger, and the other internal operations, become public read-only projections and are the proposition. Everything already on the site stays and sits under this.
If any sentence in that paragraph is wrong, the plan below is wrong in the same place.
Most of the mechanism already exists; the plan is mostly projection and rewriting
| Needed | What exists | What is missing |
|---|---|---|
| What the build knows about a visit | The traffic engine normalises 128 signals per request (functions/_lib/traffic/signals.js): country, region, city, network, bot score, device class, browser, referrer, click ids, business-hour time. Profiles persist by a keyed hash; the raw IP is never stored. Owner view at GET /api/traffic/profiles/<id>. | A keyless self-view that returns only the current visitor's own signals and stored profile fields, and a front block that renders it. |
| A text that lands as a receipt | The funnel (functions/_lib/traffic/funnel.js) already takes an inbound text carrying a code, re-evaluates policy in phase post_sms, records the outcome and replies through SEND_BY_CHANNEL. Routes POST /api/traffic/sms/inbound, GET /api/traffic/sms/status exist. | A keyless status read scoped to one code, and a front block that shows the code, waits, and renders the receipt: time, channel, the reply sent, the event id and hash, with a link to /receipt/<id>. |
| The Ledger as the product | The Console read model: GET /api/console/ledger?tab=turn|session|change|event|task|asset&window= over functions/_lib/ledger_model.js, with shared counts, Cloudflare's own record (queries, edge requests, runs, storage, changes) and definition checks. Owner-authenticated. | A viewer=public parameter on the same read model, a redaction rule held in a settings cell (bodies never, phone and email masked, owner sessions by choice), and /ledger rebuilt on it. The current public /ledger is a separate page over the raw events table with zero redaction; it is retired. |
| One business end to end, on the record | Leads: discover, enrich, research and draft by a model (/api/leads/agent), approve, send tracked email with one-click unsubscribe, watch opens and replies. Ads: create paused. Site: the build ships its own pages. Every step receipts. | One run of the whole loop on a named list, and a page generated from that run's receipts: counts, timing, cost, replies, redacted. The page is the proof of work; nothing on it is typed. |
| The pitch to a business the build wrote to | Lead rows carry the observed facts, the research, the draft, the sends and their receipts. | A per-lead page at a private token: what was observed about their business, the page drafted for them, the ads that would run, the number option, the record of what was sent, and a reply that lands on the ledger. Register: the outreach law. |
| Number options as mechanisms | Native iMessage as the Mac's Apple ID (IMESSAGE_SEND), the assigned line through Blooio (SEND_BY_CHANNEL), WhatsApp through 2chat (TWOCHAT_SEND), the one intake for inbound (WEBHOOK_INTAKE). Telegram has an intake but no send row. | One page that states each mechanism, its constraint and its failure condition, with no prices. Registration of a customer's existing number needs a device that holds the number; that is a hardware decision the page must state, not hide. |
| The laws as the gate | Writing, design and outreach laws are published objects with numbered clauses; articles are checked against them. | The /compound-media pages are not under any prose gate. They must be, or this recurs. |
The front page is six blocks, each one a thing the build does in front of the reader
This page can see the following about your visit
The block renders the visitor's own normalised signals: where the request came from, the network and whether it looks like a bot, the device and browser, the referrer and any click id, the time in the business's timezone, and the visitor hash the engine would route on. Under it, one paragraph states what is stored, for how long, and that the raw address is never stored, taken from the traffic policy rather than written. A link opens the full signal catalogue at GET /api/traffic/signals. The reader learns, from their own row, that the build measures before it acts.
Send one text and watch it arrive
The block shows a short code and the line's number. The reader texts the code. The page polls the status route for that code and, when the inbound event lands, renders the receipt: the time to the second, the channel, the reply the build sent back, the event id and its hash, and the link to the same receipt on the ledger. If nothing arrives in ninety seconds the block says so and names the two reasons it can fail: the line is down, or the carrier delayed the message. This is the demonstration the whole site rests on, so it is the second thing on the page.
What the build did in the last hour
The block is the Ledger's Events tab, public projection, last hour: events by service, the newest rows with key, route, status and hash, and the definition checks the Console runs. Bodies never appear; identifiers are masked by the redaction cell. The counts are computed at render, as the existing front already does for articles and claims.
Your number, or one the build assigns
Four mechanisms, each in the same shape: what it is, what it needs from the customer, what it cannot do, what breaks and what happens then. An existing number registered to iMessage needs the carrier to pass Apple's one-time code and a device that holds the number; hosted VoIP lines usually fail the code; Apple can deregister the identity and re-verification is the repair. An assigned iMessage line is live the same day on managed infrastructure and carries no thread history. WhatsApp needs a number free of a personal account, Meta business verification, approved templates for first contact and the 24-hour window; a low quality rating throttles the number, which is why the build sends warm follow-up only. Telegram is a bot on a bot number; the build has an intake for it and no send row today, and the page says so.
One business, end to end, on the record
The block is generated from one real run: a list of businesses found, each enriched, each researched and drafted by a model, each written to on a permitted channel, the replies, the pages the build made, the ads it created paused, and the row it wrote per day. Each step links to its receipt. The numbers are the run's numbers: how many, how long, what it cost in tokens and sends, how many replied. When the run is repeated the block updates. It replaces every capability list on the site with one walked case, which is what the writing law asks for.
If the build wrote to you
A business that received a message from the build arrives at its own page. The page opens inside their business with the fact the build observed, shows the page it drafted for them and the ads it would run, states the number option and its constraint, lists exactly what was sent and when, and offers a reply that lands on the ledger. The next step is tiny and reversible: reply, or say stop. The register is the outreach law's: an operator presenting an option to a peer.
The internal operations become the same read models with a viewer parameter, never a second code path
| Console surface | Public projection | Redaction |
|---|---|---|
| Ledger: Turns, Sessions, Changes, Events, Tasks, Assets | /ledger rebuilt on /api/console/ledger?viewer=public | Bodies never; phone and email masked; coding sessions shown or hidden by a cell you set. |
| Directory | /tools already public, compiled from the rows | None needed; credentials are never in rows. |
| Leads | Funnel counts and timings only | No identities, no addresses, no bodies. |
| Traffic | The visitor's own row only | Server-side by visitor hash; no other row is reachable. |
| Tasks and runs | /api/work already public; runs with their change sets and receipts | Task rows are public by law already. |
A projection that duplicates logic drifts; the read model is one, and the viewer parameter selects what is masked. The redaction rule is a settings cell so you can change it in the app and every projection follows.
The order is set by what each step proves for the next
- The text-in receipt loop and the visitor panel, because every later block relies on the reader having seen the ledger work once.
- The public Ledger projection, because the walked case and the per-lead page link into it.
- The rewrite of every shipped page under the three laws, and the gate that keeps them there: prices removed, personas removed, decoration removed, the scenes kept as demonstrations labelled as illustrations.
- The number-options page as mechanisms.
- The end-to-end run and its generated page.
- The per-lead page.
- The front assembled from the six blocks with the existing front folded under it.
Five decisions, made
The line that answers the front page is the build's own line; the Loop team's keyword is a sub-route on it and a code is caught before any keyword. The name on the front is miscsubjects, and the pages made under the other name now carry it. First contact in the end-to-end run is email, with iMessage on reply, which is the build's existing rule. The public Ledger never shows bodies, masks phone numbers and email addresses, and hides coding sessions until the cell ledger.public_sessions is set. The leak calculator keeps its arithmetic and loses the package and the price.
What would break, and what the repair is
Apple deregisters a registered identity; the repair is re-verification with the customer and the assigned line as the fallback, and the page must say so before anyone commits. The demonstration line will receive spam once it is public; inbound is already rate-limited by the funnel and every message is a row, so the exposure is cost, not risk. The public projection of the Ledger could leak an identifier if the redaction cell is wrong; the projection is gated by a test that scans its output for phone and email shapes before the deploy is accepted. A per-lead page reachable by guessing a token would expose a business's record; tokens are 32 bytes and the page logs every open.
The work rows
Rows WT-0412 (the parent) and WT-0413 to WT-0420 were created on the work object on 21 September 2026, each with an acceptance test the infrastructure runs. A row closes only when its evidence passes; none closes on a sentence. The object is at /api/work.
Loading the rows from the work object.