Publish events
In this fleet, publishing means deploying. There is no separate release process, press page, or announcement queue — a site is published when its Cloudflare Worker serves the domain and a curl against the live URL proves it. This page documents the real pipeline every site ships through and the one expansion recorded from its own deploy ledger.
The pipeline
npx tsc --noEmit
Typecheck, from the worker's own directory. Nothing untyped ships.
wrangler deploy
Run on the real Mac, never from a cloud sandbox (a standing rule in this repo — a Linux
sandbox install poisons the shared node_modules mount). Long or uncertain-duration steps go
through plugins/cwc-deploy/skills/deploy-runner, which backgrounds the command
and reads success from an explicit log marker instead of session liveness.
curl-verify
Against the live public domain — status code and body spot-check. “Deployed” and “actually serving” are different states, and the ledger below keeps them as different enum values for exactly that reason.
bash scripts/worker-build.sh <worker> --record
Records the kit hashes this worker was built against into its
.build-lock.json. The lock is only valid immediately after a verified deploy —
scripts/worker-build.sh's own header documents “never --record to silence a
drift FAIL.” From then on, any edit to workers/_shared/kit/ makes the staleness
loud instead of silent.
The lifecycle
Deploy state lives in a durable ledger — fact_fleet_deploy in local Postgres
(migration 008_fleet_deploy_ledger.sql), one row per domain per wave, written only
through ledger.sh so agents never hand-write SQL. Its deploy_status
enum, verbatim:
| status | meaning |
|---|---|
pending | row seeded from fleet-manifest.toml; no agent has claimed the domain yet |
deploying | an agent claimed the domain and the deploy sequence is running |
deployed | wrangler deploy succeeded; live verification not yet done |
verified | curl against the live domain confirmed the deploy actually serves |
failed | a step errored; the row's notes say which one, so a retry starts informed |
skipped | deliberately not shipped (denylisted or user-directed skip), recorded rather than silently absent |
The 2026-07-09 expansion, recorded from its own ledger
Wave plan baked 2026-07-09 from fleet-manifest.toml (5 redirect entries,
8 wave-2 sites, 15 wave-3 sites — counted over the manifest, not recalled). Wave 1 was
verified at authoring time; this page was authored during wave 3, so later
statuses — including this site's own row — live in the ledger, not in this static bake.
subagentredirects-web — 5 redirect domains, verified
One shared pure-301 worker (zero kit imports, permanently exempt from the drift gate) covering 5 typo-twin/fold domains: subagentbredrock.com, subagentspython.com, subagentstypescript.com, agentiwikis.com, agentsystemdesigns.com. Deliberately first: the cheapest possible pipeline shakedown.
8 aggregator sites
No D1 of their own — each server-side-fetches live sibling APIs at request time: agentregistrations, agentsitemaps, agentsubdomains, agentsubtasks, agenttodos, agentportfolios, outcomesdk, agentdiagrams.
15 static sites (this site among them)
Real repo data baked at authoring time as TS constants, each with a provenance line: agentbloggers, agentchangelogs, agentcoauthors, agentdatamodels, agentdatawarehouses, agentloggers, agentmachinelearning, agentpublishers, agentreaders, agentsystemcards, agenttrademarks, opencoworkers, opensubagents, subagentmcp, subagentsystemdesigns.
Honest scope note
This is a static description of the pipeline and one expansion's wave record — it does not
query fact_fleet_deploy at request time (the ledger is local Postgres on the
operator's machine, deliberately not exposed to the public internet). The machine-readable
public record of what actually serves is each site itself: its /llms.txt, and the
family registry at subagentsubdomains.com/api/dns-zones.