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 sitesDONE — wall, keys, IDOR, stamps, 3 domain traps
1 · Bridge + TodayA daemon on the Mac Studio pushes ATLAS state (NEEDs, missions, QA, agent health) to the console. One morning screen replaces archaeology.DONE — live, syncing every 5 min
2 · RegistryOne row per property — 139 registered. Register once; QA, monitoring, and portfolio follow automatically.DONE — /portfolio live
3 · Command pathConsole buttons that queue real ATLAS missions — including the acquisition tap as a single button.DONE — Queue for ATLAS · Run QA · tap queue live
4 · Public entryandertongroup.com rebuilt: real git repo, real story, registry portfolio. Staged at andertongroup-v2.vercel.app — Opus PASS 7.8.STAGED — your flip
5 · Consolidatemanage pruned to six sections (~19 page-groups retired), Money view live, CLAUDE.md rewritten from reality.DONE — Opus 7.7

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
Done: the suiteAll five phases shipped and live-verified the same day. The console at manage.worker-bee.app/today is now ATLAS's body: live NEEDs, missions, the 11/12-green QA board, agent health, and command buttons that queue real ATLAS work.
QA sweep receipts11/12 sites carry live, honest stamps. The sweep found and fixed real bugs: 17 broken images on Climb Brasil, a 36-day-stale JRS deploy, silver-creek admin 500s plus a public-data auth hole, 8 phantom sitemap pages on Climb France.
Your three calls1) Flip andertongroup.com to the staged rebuild — one command when you approve. 2) Orthobiologic cutover — live site is still the Lovable publish; the repo holds 3 weeks of undeployed work. 3) Google client ID — 3-minute recipe in §05; the sign-in button is built and waiting.
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).