One Next.js process. TypeScript. No database yet.

Languages and runtime

TypeScript throughout. React 19 for the pages. Next.js 16 App Router for both UI and Route Handlers. Tailwind v4 and shadcn/ui for the desk chrome. Node.js built-ins (crypto, fetch) for HMAC demo receipts and upstream calls. No Python, no Go, no separate API service.

Where the code lives

app/

Routes: human pages, /api/v1/briefs/[kind], catalog, demo facilitator, ledger, health, OpenAPI, /.well-known/*, /llms.txt.

lib/

x402 header codec, catalog/SKUs, paywall, in-memory ledger, Wikipedia / HN / Open-Meteo / protocol fulfillers, discovery documents.

components/

Playground, SKU cards, chrome. shadcn primitives under ui/.

Servers, right now

Development is next dev on 127.0.0.1:43147 inside this cloud VM. There is no Docker Compose, no local Postgres, no Redis. Upstream HTTP is live: Wikipedia, Hacker News Algolia, Open-Meteo.

The x402 facilitator on this instance is in-process: POST /api/demo/receipt HMAC-signs a payload. Production USDC would call an external facilitator (for example x402.org on testnet) instead of keeping a chain client in this repo.

What database we would expect

None is required for the 402 loop itself. Quotes and briefs are stateless besides a nonce. Today sales and used nonces live in process RAM and die with the server — fine for the cloud demo, wrong for a public deploy with more than one isolate.

The first real store would be Postgres (or Vercel/Neon) for: settled receipts, consumed nonces, SKU config, and maybe cached upstream packets. Redis/KV is optional on top for hot nonce checks and rate limits. We would not put Wikipedia in our database; we would cache transforms with a TTL.

Deployment shape

This is an ordinary Next.js app. Vercel (or any Node host that can run next build / next start) is the path. Serverless means the in-memory ledger will not be shared across invocations — briefs still work; the Operators register will look empty or partial until a database exists. Set BRIEFBAR_DEMO_SECRET and NEXT_PUBLIC_SITE_URL on the host.

Stay on this cloud workspace until a public origin is actually needed. Grok live-search and other fetchers can only cite a URL that is on the public internet.

Grok fleet and pstack

A Grok fleet will pick SKUs, police sourcing, and triage this page. That fleet talks through ops/ and Origin PRs. Slack is a human projector at most — not a queue, not a merge signal. Chat is the ops equivalent of a checkout form: too human-shaped for machines that already pay over HTTP.

Engineering uses pstack: /add-plugin pstack, /setup-pstack, /poteto-mode. Grok is the default fast/swarm worker. pstack is how code is written. It is not a second product commander. See FOR_AGENTS.md and ops/preferences.md.

Grok / xAI surfaceability

Two different Grok surfaces matter, and they are easy to confuse.

1. Live search / citation. A Grok answer that browses the web needs crawlable HTML and an explicit allow in robots.txt. xAI user-agent tokens are messy in the wild (xAI-SearchBot, Grok, xAI, sometimes ordinary Chrome). This desk allows all of them and publishes a sitemap. The human pages — especially /protocol, /stack, and /operators — are what a search fetcher should quote.
2. Tool-using agent. A Grok (or any) agent that can pay should start at /llms.txt, /openapi.json, /.well-known/agent.json, and /.well-known/x402. Those documents describe the 402 loop. Unpaid brief GETs are supposed to 402; that is not an outage.

We do not run bot-blocking middleware. A 402 is a price, not a block. If Grok fetches a brief without a signature, it should read the quote and either pay, or stick to the free catalog and HTML essays.