ATLAS · Operator Briefing

The site becomes the body.
ATLAS becomes the spine.

What the Worker Bee estate was, what it is as of July 5 2026, and a plain-English walkthrough of how to use what shipped. Written for Toby. Not indexed.

01What was → What is

The one-sentence diagnosis: ATLAS kept its truth in files, the site kept its truth in a database, and the public site kept its truth in a single HTML file — three stores, zero sync. The site could only go stale. The fix is an inversion: ATLAS is the single source of truth, and every web surface becomes a window into it.

What was — before the July 5 audit

  • manage.worker-bee.app wide open. The auth function existed but was never called — all ~60 admin pages and ~120 API routes were publicly reachable. Your client list was one curl away.
  • The domain was frozen in June. A manual alias pinned manage.worker-bee.app to a June 20 deployment. Every deploy since silently missed the domain — the invoice engine "shipped" July 2 was never actually live.
  • Invoice engine uncommitted. Live in prod, but the code sat 3 days in the working tree — one wrong git command from gone.
  • andertongroup.com: a 62 KB static file. Not a git repo. No analytics, no sitemap. Selling $750 brochure sites while the business runs an agent operation with 50+ properties.
  • ATLAS invisible. NEED queue, missions, QA board, workforce receipts — all machine-readable, none on any screen.
  • Five disagreeing site lists. Supabase, seed data, a hardcoded 54-site array, the QA registry (12), and ~120 project folders on disk.

What is — as of tonight

  • Locked down and verified live. Default-deny middleware: every admin page and API returns 401/redirect without your session. Public funnels, client portals, and machine endpoints still work — each one traced and tested by curl.
  • Domain follows production again. Stale alias removed; every future deploy reaches the domain automatically. Invoicing is now genuinely live.
  • Everything committed and pushed. Invoice engine, auth work, verify receipts — all on GitHub main.
  • Adversarially reviewed. An independent Opus review tried to break the new wall — found one real bypass (invoice PDF via empty token). Fixed both layers the same hour, re-verified live.
  • A signed PRD exists. The full plan for making the site an extension of ATLAS: ~/.atlas/docs/PRD-atlas-platform-2026-07-05.md.
  • Login upgrade in flight. Password reveal, email self-reset, and a Google sign-in that lights up the moment you create the one credential only you can create.

02What shipped today — the receipts

ItemDetailProof
Security middlewareDefault-deny across the dashboard and APIs. Explicit allowlist for the four public funnels, token portals, key-checked machine endpoints, webhooks, and crons (now bearer-guarded).Anon /sites → 307 login · anon /api/clients → 401 — live
IDOR closedEmpty ?token= let anonymous requests fetch any invoice PDF. Found by outside review; fixed in middleware and route.Probe went 404-reached-route → 401-at-edge
Domain unpinnedRemoved the June 20 explicit alias that beat the wildcard on every deploy.Deploys now land on the domain within seconds
Invoice engine protected3 days of live-but-uncommitted code (PDF generator, public portal, billing UI) committed retroactively.GitHub main, two commits
Env hygieneCRON_SECRET created; the empty preview environment populated (previews had never once built); Vercel CLI upgraded off a buggy version.Preview deploys now build green
Migration hygieneDuplicate migration deleted, timestamp collision fixed, stray analytics SQL foldered.Repo, commit 60b7031
The PRDFull audit of manage, andertongroup.com, ATLAS, and the Obsidian brain → 5-phase plan.Delivered + saved in ~/.atlas/docs

03The plan — five phases

PhaseWhat it deliversStatus
0 · Lock the doorsAuth wall, key rotation, QA stamps deployed to the 12 sitesIN PROGRESS — wall done, keys next
1 · Bridge + TodayA daemon on the Mac Studio pushes ATLAS state (NEEDs, missions, QA, agent health) to the console. One morning screen replaces archaeology.NEXT
2 · RegistryOne row per property — all ~120 builds. Register once; QA, monitoring, and portfolio follow automatically.QUEUED
3 · Command pathConsole buttons that queue real ATLAS missions — including the acquisition tap as a single button.QUEUED
4 · Public entryandertongroup.com rebuilt: real git repo, real story, portfolio that renders from the registry and can never go stale.QUEUED
5 · Consolidatemanage pruned from ~60 pages to six sections. Money view: MRR + outstanding, one screen.QUEUED

The two rules that keep it from going stale again: the platform never duplicates ATLAS state (it reads it), and the platform never executes work (it queues missions; ATLAS executes under its own laws — EYES, DEPLOY, BLAST-RADIUS). ATLAS 2.0 inherits everything by writing the same file schemas.

04Operator walkthrough — how to use what exists today

1

Log in — this is new behavior

Go to manage.worker-bee.app/login and enter the admin password. Until today, bookmarked pages like /sites just opened; now everything redirects to login first. Your session is a signed cookie — one login per browser, it persists. The Vault still asks for its own master password on top; that's intentional (second lock on the credential safe).

2

Daily driving — the six places that matter

/sites — every registered site, with detail pages and the blueprint canvas. /clients — CRM: status pipeline from new → quoted → in progress → complete. /billing — invoices (see step 3). /leads — the sales pipeline with Gmail drafting. /monitor — uptime pings across the estate. /vault — credentials, AES-encrypted. Everything else in the sidebar still works, but these six are the daily loop — and Phase 5 will prune the rest around them.

3

Invoicing — now actually live on the domain

Create at /billing/new: pick client, add line items (quick-add buttons for AI build cost, hosting, maintenance), watch the live preview, save. On the invoice page: Download PDF gives the branded A4; Copy Client Link copies a public URL with a secret token — send that to the client, they see the invoice and PDF with no login. That link is what the empty-token exploit targeted; it now rejects anything but the exact token.

4

The public funnels — your inbound machine

Four pages work without login, on purpose: /evaluate (paste any URL → scored audit → fix board — your best lead magnet), /plan (blueprint wizard for prospects), /request (work requests), /pipeline (client-facing build progress). Submissions land in /submissions and /requests inside the dashboard.

5

Client-facing links — what you can hand out

Three kinds of URL are safe to give clients: the invoice link (step 3), the client portal /client/<token> (milestones + their blueprint cork board, read-only), and the pipeline view. Everything else now demands your cookie.

05The new login — reveal, reset, Google

Building right now on a branch. Here's how each piece works when it lands:

Password reveal

An eye toggle inside the password field on the login screen (and on the reset form). Tap to show, tap to hide. Small thing; ends the retype-it-blind ritual.

Reset password — self-serve, 15-minute link

/login → "Forgot password?" → email lands at the operator address (recipient is hardcoded — only you) → link opens /reset-password (valid 15 minutes) → new password twice, 12+ characters → saved, auto-logged-in, done.

The new password is stored as a salted hash — the old env-var password stops mattering the first time you reset. Anyone else clicking "Forgot password?" achieves nothing: the email only ever goes to you, and the endpoint won't send more than once a minute.

Sign in with Google — needs one thing only you can do

The button verifies your Google identity server-side and only accepts allow-listed emails (yours). It stays hidden until a Google OAuth client ID exists — that's a credential I can't create for you (Google requires the account owner in their console). The 3-minute recipe, also saved as docs/GOOGLE-LOGIN-SETUP.md in the repo:

a

console.cloud.google.com → APIs & Services → OAuth consent screen → External → app name "Worker Bee", your email, save through the steps.

b

Credentials → Create credentials → OAuth client ID → Web application. Authorized JavaScript origins: https://manage.worker-bee.app and http://localhost:3000. Create → copy the client ID.

c

Tell ATLAS "here's the Google client ID: …" — the env vars get set, the app redeploys, and the button appears on the next load.

06What's next, in order

Up nextWhy
Key rotationTwo API keys are sitting in committed docs/source. Rotation plus the four hardening items the security review flagged (one endpoint has no key check at all).
QA stampsThe stamps are built but never deployed — the QA board reads all-red for 12 sites. Deploying turns it into real signal, and gives the future Today screen its first live data.
The BridgePhase 1. A small daemon (same pattern as your 06:00 daily brief) that pushes ATLAS state up to the console. This is the moment the site stops being a separate thing and starts being ATLAS's body.
Your four decisionsFrom the PRD, none blocking: keep worker-bee.app as the platform brand vs fold into andertongroup.com · name ATLAS publicly or keep it as "our agent system" · console naming · hosting posture (verdict today: the M1 Ultra is nowhere near maxed — it's the brain, not the server; demos stay on it, revenue stays on cloud).