Epic: Beta Launch (deploy current main, verify it holds in prod, invite the first users)#

BLUE-TEAMED 2026-06-07 (drafted, fresh-agent ultracode red-team, then scope-cut with Dan). This is P0 on the roadmap (Horizon 1). It is not a build — the web app is already deployed and feature-complete at app.autri.ai. P0 is deploy current main → verify the trust-critical things hold in prod → invite the first individual users → measure. Mostly ops/verification, sequential. Ladders to North Star B4 (tiered security), B7 (dependable), B2 (know-cost-cold), B1 (trustable retrieval).

Verification stance (the spine of this epic). Every acceptance criterion names a deterministic check and an owner: 🤖 AI-mechanized (I close the loop myself before review) or 🧑 human-judgment (Dan's smoke test / qualitative call). The rule: the mechanized loop closes first; the human smoke-test is the backstop, not the primary. A criterion with no checking mechanism is itself a red-team finding.

Beta shape (locked 2026-06-07). The beta is individual users, not organizations — a couple of people from STEM Racing plus family/friends. Each signup auto-provisions its own org (the Cognito post-confirm Lambda inserts org + user + Personal library; users.organization_id = users.id = Cognito sub, a strict 1:1 self-org). So "an individual user" is a tenant — we build zero org infrastructure for the beta. The Team-tier multi-user-shared-org path (D21: library_access grants, invites, admin roles) exists in schema but the beta does not exercise it (see Non-Goals).

Features & Stories#

Each feature carries a Verification mechanism line (🤖 AI / 🧑 human).

Design#

Data Model Changes#

None. Deploys migrations 013/014 (additive, already written). The /api/cache fix is authorization logic + presigned-URL issuance, no schema change.

Context#

Overview#

Goals & Non-Goals#

Goals:

• Deploy current main to prod (web + migrations), shipping cost-observability (D66) + UI fixes. (Not a security ship — see correction below.)
• Prove the trust-critical invariants hold in prod with ≥2 real individual users: cross-user data isolation across every surface, and no silent data loss.
• Confirm cost observability works on the real deployed worker (the "measure first" premise).
• Seed a behavioral regression harness (F6) with the launch-critical checks — non-blocking, future-proofs the work.
• Invite the first individual users and start collecting cost + quality + behavior data.

Non-Goals:

• Not a feature build. No new product capability beyond what's on main (the cohort-gated source view F5 is the one conditional exception).
• Not the Team-tier multi-user-org path (D21) — invites, library_access grants between users, admin roles. Beta = individual self-orgs; F2 tests cross-individual isolation only. Don't over-build org infra.
• Not per-org / per-user rate or cost caps. Account-level AWS Budgets ($50/$100/$200, email-notified) are the spend brake; per-tenant metering is H2 (D18). Accepted risk for a ~10-user friendly beta: a looping user is alerted-on, not throttled.
• Not commerce (Stripe/tiers/metering — H2), not MCP (cut, D56), not the Horizon-0 quality cluster, not enterprise (H3).

Problem Statement#

The platform is built and deployed, but the beta is not launched because the trust-critical things have never been exercised under real conditions:

1. Prod is behind main — missing cost-observability. (It is not missing a tenancy fix — see the correction below; that framing was wrong.) Deploying is small but the auth stack is in a failed-deploy state that must be understood first (F1).
2. Cross-user isolation is enforced in code but never tested with ≥2 real users in prod. A leak between users in a trust-first beta is catastrophic — the single highest real risk. Enforced-in-code ≠ verified.
3. Failures may not surface. Monitoring exists, but 10 jobs sit in dead-letter queues (3 ingest + 7 extract, in ALARM since 2026-05-31, ~1 week un-actioned) — and we don't know whether those failures surfaced to the uploaders or vanished. The alarm channel is a single un-escalated email, which is why they sat unnoticed.
4. Cost columns are worker-written — a local CLI ingest doesn't populate them, so D66 is verified only by seed, never by a real deployed run.

What Is This Epic?#

The deploy-verify-invite effort that turns a live-but-unlaunched platform into a running beta. Ship current main, run a fixed verification battery against prod (cross-user probe matrix, induced-failure surfacing, real-ingest cost), then invite the first individual users. Output = evidence the beta is safe for real user data, plus a seeded regression harness — not new product code.

Dependents#

• Everything in Horizon 2+ unblocks on real beta usage data this epic produces (pricing B5, API+dogfood B3/B6, enterprise B4).
• Every future epic extends F6's harness with its own cases.

Dependencies#

• The deployed platform (EPIC-5, 2026-06-01): Cognito + Google auth, email allowlist, per-user self-orgs, multi-tenancy in code, upload→inspect→chat→cost UI. Verified, not built.
• AWS self-verification access (autri-prod CLI profile, read across all 5 stacks/RDS/CloudWatch/SQS/Budgets — documented in CLAUDE.md). Makes F1/F3/F4 self-checkable. Gap: RDS is private and no SSM/bastion exists — DB-level checks need a new in-VPC read Lambda or the app's query path (F4).
• deploy.sh / deploy-web.sh — deploy.sh all runs migrate→web→ingestion→monitoring and explicitly excludes the auth stack (it's drift-blocked). Migrations auto-apply via the autri-db-migrate Lambda.
• CDK stacks — autri-auth-and-compute is in UPDATE_ROLLBACK_COMPLETE (failed 2026-06-01 deploy); the beta payload doesn't touch it (F1.b).
• Real Cognito signups — the F2 two-user provisioning path (replaces the prod-forbidden AUTRI_DEV_AUTH).
• Crucible + the existing vitest runner (incl. app/__tests__/scope.test.ts) — the F6 harness substrate.
• The shipped in-app feedback→GitHub-issues button (D55) — the named beta support channel.

Current State#

• Prod: app.autri.ai, live. Deployed web image 0d22bbb (2026-06-02). Delta to main = 59 commits, but only 5 touch app/ (the deploy-web.sh surface); the other 54 are eval/ingestion/docs that don't deploy here. Migrations 013/014 ship via deploy.sh migrate.
• Tenancy fix already live (CORRECTION). The query-playground org-scope fix (5371370, D13's "last read-leak surface") is an ancestor of the deployed image — it shipped 2026-05-29. The deploy does not ship it. (decisions.md self-contradicted on this — L184 fixed 2026-06-07. Same stale-doc trap as last session, inverted; caught by a fresh agent checking git against the live Lambda.)
• Multi-tenancy (D13): read / mutation / query-playground enforcement shipped (org-scoped lookups, not-found on cross-org). 8 of 9 mutations use requireKbAccess; addDocumentsToKb uses an inline org-WHERE + worker-mode early-return (two mechanisms). Never validated by real multi-user traffic — the graduation gate.
• Auth stack wedged: autri-auth-and-compute = UPDATE_ROLLBACK_COMPLETE, rollback blocked 3× by the cert export. The drift is MCP/AgentCore infra — which D56 cut from beta. CloudFormation StackDriftStatus = NOT_CHECKED (drift is asserted from memory, never measured).
• Monitoring (autri-monitoring): alarms for DLQ depth, ingestion-degraded, postgres-connections, web/chat error-rate; all route to one SNS topic with a single email subscriber. RDS: single-AZ db.t4g.small (MultiAZ=false), 7-day backups + PITR, deletion-protection on. Restore (RTO) never tested.
• Cost brakes exist: 3 monthly AWS Budgets ($50/$100/$200, ACTUAL+FORECASTED email alerts). No per-org/rate cap.
• Cost observability (D66): rate table + per-doc stage-breakdown columns (013) + per-query Sonnet cost (014). Not deployed — rides this deploy; worker-written, so only a real deployed ingest exercises it.

Affected Systems#

Approach#

Sequential, gated on the deploy. The isolation gate (F2) is decoupled from the harness build (F6) so net-new harness work never blocks launch.

1. Deploy current main (F1.a) — Docker prune, deploy.sh all (web + migrations), smoke. Separately, health-check the wedged auth stack (F1.b) and decide if beta needs it touched (likely not — MCP is cut).
2. Verify isolation (F2) — sign up 2 real individual users (real Cognito/Google, real cookies), run the cross-user probe matrix as a minimal scripted check on the real auth path. Hard launch gate — must pass before any real user data goes in. Folding it into F6 is a fast-follow, not a prerequisite.
3. Verify reliability (F3) — investigate the DLQ backlog, prove failures surface, confirm monitoring is enough.
4. Verify cost (F4) — one real ingest through the deployed worker; confirm columns populate.
5. (Conditional) source view (F5) — only if the cohort brings non-PDF docs.
6. Seed the regression harness (F6) — non-blocking; turns F2/F3/F4 checks into permanent cases.

→ Beta is "launched" when: F1–F4 green, the first users are invited (Dan), AND ≥1 real user has uploaded + chatted. Green infra alone is not "launched."

Onboarding/support (folded in, not a feature): Dan owns invitations. Support = the shipped in-app feedback→GitHub-issues button (D55) — named here, not built; someone watches the issues. First-run sanity is covered by F2.S2.1 (signing up the 2 real users is the first-run check).

Poor /hl:ship parallel-wave fit (sequential, ops, prod-facing). Execute human-led.

Key methodology — the cross-user isolation probe matrix (F2)#

The invariant (D13): for every guarded surface, a request from user A for user B's resource returns "not found" — same shape as a genuinely missing resource — no existence leak, no data. Run as user A against user B's real resources, on the real authenticated path (real Cognito cookies, never mocked — AUTRI_DEV_AUTH is statically compiled out in prod and is a synthetic bypass anyway):

Also confirm the positive case — user A fully accesses its own resources — so we're testing isolation, not a blanket 404.

F1 — Deploy current main (+ assess the wedged auth stack) → B2 · S–M · 🧱#

F1.a — Routine deploy (ships the beta payload; never touches auth):

Verification mechanism: 🤖 cdk diff + prod-SHA check + Crucible render smoke + a rollback dry-run. 🧑 Dan approves the actual deploy.sh run (outward-facing).

F1.b — Auth-stack health (investigate, then decide):

Verification mechanism: 🤖 describe-stacks state + an end-to-end login check. 🧑 Dan's call on whether to do the manual cert-re-pin surgery now or defer (non-launch-gating).

F2 — Verify cross-user isolation in prod with ≥2 real users → B4 · S–M · 🧱 · HIGHEST RISK / LAUNCH GATE#

Verification mechanism: 🤖 the probe matrix (deterministic per cell) + the white-box grep + the /api/cache probe — re-runnable forever. 🧑 the 2-account setup is an honest human task; a one-time review that the suite hits the real path.

F3 — Verify failures surface + monitoring is sufficient → B7 · S · 🧱#

Verification mechanism: 🤖 induced-failure harness case, sqs get-queue-attributes, describe-alarms AlarmActions + sns list-subscriptions-by-topic, describe-db-instances backup config. 🧑 someone confirms the alarm channel is watched (consider a higher-signal route for DLQ/error-rate); the restore drill.

F4 — Real worker cost verification → B2 · S · 🔀#

Verification mechanism: 🤖 read the cost columns via the app's in-VPC query path (primary — no SSM/bastion exists) or a tiny read-only in-VPC Lambda (if a DB-level assert is wanted, its own approved story); Crucible asserts the inspector cost line renders. 🧑 sanity-check the dollar figures.

F5 — (Cohort-gated) Source view for all doc types → B1 · S · 🔀#

Verification mechanism: 🤖 headless Preview snapshot of a non-PDF source pane, assert non-empty. 🧑 visual judgment it's usable.

F6 — Verification & Regression Harness (cross-cutting; non-blocking; seeded) → B7, B1 · M · 🔀#

Verification mechanism: 🤖 harness self-reports green; deterministic cases. 🧑 one-time faithfulness check (real path, not mocks) + Dan's standing smoke-test as the backstop layer.

Stories#

S2.4 realization (session 3): instead of presigning at the inspector + chat server seams (would inject ~500-char signed URLs into the model's chat context every query + cause TTL staleness), the existing /api/cache/[...path] route became the single authz chokepoint — session + doc→org check, then in prod a 307-redirect to a short-lived presigned S3 GET; CloudFront behavior 5 + the cache-bucket OAC grant removed so there is no unauthenticated edge path. Org-authz is prod-only (CACHE_BUCKET-gated); dev still serves local files (CLI keys by filename slug, not UUID). Adversarial security review found no constructable cross-org read; cdk diff confirmed the Web + NetworkAndData changeset with autri-auth-and-compute untouched (decoupled from F1.b). The api-cache app + infra halves must deploy together (Wave 1) — see autri-infra/docs/rollback.md.

Execution Plan (waves + sequencing)#

Locked with Dan 2026-06-07. The organizing principle: separate code-work (parallelizable, pre-deploy) from verification-work (post-deploy, the gate). That split is what makes Wave 0 a /hl:ship candidate while the deploy + verification waves stay human-led and sequential.

Critical-path spine: decide /api/cache fix-shape → code /api/cache + welcome fixes → merge → clean deploy → F2 (S2.1→S2.2) → invite first users. Everything else hangs off this in parallel.

Wave 0 — Pre-deploy prep (parallel; zero prod risk; the /hl:ship-able subset)#

Two micro-stages because two tasks need a decision before coding:

0a — Decide, before coding (small, fast):

• /api/cache fix-shape (resolves OQ#3). In prod, page images/figures are served S3→CloudFront with no Lambda in the read path, so editing route.ts only fixes the dev path. Real org-auth needs a design call: an authenticated endpoint issuing org-scoped presigned URLs vs. a CloudFront function / Lambda@Edge doing the check. This may touch CDK, not just the web image — so the "clean deploy" could carry an infra change. Decide the shape first.
• F1.b S1.5 — auth-stack health + welcome-fix deploy path (elevated to Wave 0 because it gates the welcome fix). The welcome notification lives in the post-confirm Lambda, which is part of the wedged auth-and-compute stack. Determine whether it can be updated via a targeted aws lambda update-function-code (sidestepping the wedged CloudFormation update) or must wait on auth reconciliation. Also confirm logins work post-rollback.

0b — Code (parallel, fan-out-ready):

• F2 S2.4 (code) — /api/cache org-authz fix per the 0a shape. The trust-critical one; must land in main to ride the deploy.
• Welcome-message fix — repoint the notification body + link off the dead /help/claude-desktop (cut MCP feature) to a real first-run action (e.g. upload page). Deploy path per 0a.
• (Optional polish, non-gating) Mascot 404 page — not-found.tsx using the WIP golden-retriever SVGs in dogs/, with the in-app feedback→GitHub button (D55) that auto-captures the attempted URL + referrer so a 404 report reads "user hit /help/claude-desktop", not a generic "broken". Closes the feedback loop on whatever lands users there. Slate if Wave 0 has room; otherwise fast-follow.
• F6 S6.1 (scaffold) — stand up the harness (non-visual cases in the existing vitest runner; visual in Crucible). Non-blocking.
• F1.a S1.4 — document the rollback procedure.

→ Merge Wave-0 code to main. cdk diff (F1.a S1.1) runs after this merge — the deploy now ships more than current main, so the diff must reflect what actually goes out.

Wave 1 — Deploy (sequential, human-led; the gate to prod state)#

F1.a S1.2 (deploy.sh all — main + Wave-0 code + migrations 013/014; Docker prune first) → S1.3 (post-deploy Crucible render smoke). Dan approves the actual deploy. The welcome-fix and any /api/cache infra change ride here (or via the targeted Lambda update from 0a).

Wave 2 — Post-deploy verification (3 parallel tracks)#

F5 S5.0 (determine cohort doc types) runs anytime here; gates the conditional S5.1.

Wave 3 — Harness consolidation (non-blocking fast-follow)#

F6 S6.2 (seed the verified F2/F3/F4 checks as permanent cases) → S6.3 (wire into the loop). Depends on Wave-2 checks existing; does not gate launch.

Wave 4 — Launch#

Dan invites the first individual users (a couple from STEM Racing + friends/family) → confirm ≥1 real user has uploaded + chatted = "launched." F5 S5.1 only if the cohort brought non-PDF docs.

Parallelism summary#

• Fan-out-ready (Wave 0b code): /api/cache fix · welcome fix · 404 page · harness scaffold · rollback doc — independent; a /hl:ship wave candidate.
• Sequential / human-led: the deploy (single prod action, Dan-approved); F2 S2.1→S2.2 (need users before probing); launch after F2 is green.
• Parallel post-deploy: F2 / F3 / F4 tracks run concurrently; only F2 gates the invite.

Decisions Log#

Risks#

Known Issues / Tech Debt#

Open Questions (genuinely still open)#

Most prior open questions were resolved in the blue-team pass (commit scope, rollback, support, success metric, cohort shape, cost brake). Two more resolved in session 3 (2026-06-07) — see Decisions Log. Remaining:

1. Auth-stack reconciliation — leave wedged or fix? RESOLVED (S3): reconcile to clean state + full clean deploy (root cause = cert export-in-use deadlock; F1.b diagnostic = cdk diff autri-auth-and-compute). No tail tech debt.
2. Higher-signal alarm route — is email + a watched-inbox enough for beta, or wire Slack/SMS for DLQ/error-rate now? (F3.S3.3.) — still open.
3. /api/cache fix shape RESOLVED (S3): authenticated org-scoped presigned-URL endpoint (unifies with existing presigned GET/PUT; touches web + network-and-data CDK only).

BLUE-TEAMED 2026-06-07. Wave-0a decisions locked session 3 (2026-06-07). Ready for Wave-0b code + human-led execution. F2 is the launch gate.