Aurora Demo Runbook
Everything a presenter needs to drive the Aurora “Order Nucleus” demo on
staging (staging.ordermatic.co). All data is is_test_order=true.
-
Name: Aurora — Order Nucleus · slug
aurora-poc -
Clerk org:
org_3GtseizcaewejjZuXygIcoLWYYq -
Demo connection:
2799efc9-d180-4710-89e9-5ad529b348bf -
8 site queues (site = the assigned CSR; switch sites via the inbox assignee filter):
Site ERP label Ohio — Streetsboro GP-1 Welcome, NC GP-2 Pasadena, TX GP-3 Lunenburg MA GP-4 Evansville, IN (1) GP-5 Evansville, IN (2) GP-6 Marieville, QC IQMS-1 Louisville, KY (Lastique) IQMS-2
What’s in the inboxes (42 orders total)
Section titled “What’s in the inboxes (42 orders total)”- 10 real sample POs (Robert’s actual drop) — real Aurora item codes, the
$0.00-total extraction trap (MI Profiles), the verbal order, the email-thread
PO. On Lunenburg (8, where the item master carries their items) + Streetsboro (2: MI Profiles, the verbal order).
poc/aurora/raw/. - 32 enriched demo orders — every one of the 8 sites gets one of each so the
product’s full document range is on stage in any queue:
- PDF purchase order — branded letterhead, line-item table (
file_type=pdf) - Excel order sheet — styled workbook (
file_type=xlsx) - Scanned-image PO — looks faxed/scanned (
file_type=image) - Email order — real email body + (mostly) an attachment; the “Show email”
toggle flips between the attachment and the message (
source_type=email). Two of them are 3-message threads (RFQ → our reply → the PO): the row carries a+3 messagesbadge and the cockpit grows a Thread tab. - A few are pre-submitted so the routing-landing beat (“→ GP-x”) shows.
- PDF purchase order — branded letterhead, line-item table (
Every document renders in both the inbox preview pane and the full review page —
that was the point of this pass (the old Sim_*.pdf filler had no bytes and threw
“Unable to load PDF document”; it’s gone).
5-minute demo flow
Section titled “5-minute demo flow”- Open
/inboxas Aurora. Point out the lived-in queues across sites. - Variety in one queue — click through a PDF, an Excel, a scanned image, and an email order. Each previews inline. This is the “we read whatever your customers send” beat.
- Email order — open one, show the body, hit Show email / attachment to toggle. This is the “the PO is buried in an email” pain.
- A messy real one — the verbal order or the MI Profiles $0.00-total trap: narrate it as a review-queue win, not an extraction failure.
- The nucleus — open a multi-line order, split it, and route each split to a
different site (the “Route to” picker). This is the buy decision.
(Shipped in #2652 and deployed to staging 2026-07-27 — no local build needed.
Confirm the served revision includes
98a9d319dbefore you present.)
Feature flags (Flagsmith, staging)
Section titled “Feature flags (Flagsmith, staging)”Created 2026-07-26. Segment org_aurora_poc (id 16) matches
organizationId = org_3GtseizcaewejjZuXygIcoLWYYq; four segment overrides in
the Staging environment (id 3) turn these on for Aurora and nobody else:
| Flag | Why the demo needs it |
|---|---|
aurora_poc_routing_card_v1 |
the routing card (created here — it did not exist) |
quote_splitting_enabled |
the Split tab / split-to-site routing |
review_approval_only_mode |
CTA becomes Finished instead of a live “Submit to ERP” against a fake connection |
matching_codeless_lines_v1 |
codeless (no item number) lines |
Verified scoped: Cleveland Kitchen and the default identity read false for all
four. Note the environment naming trap — the staging webapp’s
FLAGSMITH_ENVIRONMENT_KEY is a different key string for that same
environment, so match by flag state, not by key.
Roles / permissions (Clerk)
Section titled “Roles / permissions (Clerk)”All 8 site users carry publicMetadata.roles = ["manager"] (set 2026-07-27).
manager is in INBOX_ELEVATED_METADATA_ROLES (packages/auth/src/rbac.ts).
Verify the live state rather than trusting this line:
curl -s "https://api.clerk.com/v1/organizations/org_3GtseizcaewejjZuXygIcoLWYYq/memberships?limit=20" \ -H "Authorization: Bearer $CLERK_SECRET_KEY" \ | jq -r '.data[] | "\(.public_user_data.identifier)\t\(.public_metadata.roles // "none")"'The three capabilities the demo depends on (not the full set granted — see
packages/auth/src/permissions.ts):
| Capability | What it unlocks |
|---|---|
inbox.view.team |
the /team route at all — without it you get a silent redirect to /inbox |
inbox.view.all |
every plant’s queue, not just your own |
inbox.manage.assign |
unconditional reassign (the “Take over” path) |
Re-assignment is org-scoped, not connection-scoped: bulk-actions.ts
validates the assignee with isUserInOrganization(org, assignee), and /team
builds its member list from getOrganizationMembers(org). So any plant can hand
an order to any other plant — that is the re-routing mechanic in the
site-as-assignee model this POC runs on.
To grant it to a new user:
curl -X PATCH "https://api.clerk.com/v1/users/<USER_ID>/metadata" \ -H "Authorization: Bearer $CLERK_SECRET_KEY" -H "Content-Type: application/json" \ -d '{"public_metadata":{"roles":["manager"]}}'Note supervisor is NOT enough — it grants escalate/bulk/analytics but neither
inbox.view.team nor inbox.manage.assign.
Reset / re-seed
Section titled “Reset / re-seed”The content script is idempotent — re-running restores the exact same set (it
deletes its own prior output + any legacy Sim_ filler first, leaves the 10 real
POs untouched):
cd /Users/mc-boone/Dv/erp-unlockedset -a; source .env; set +ainfisical run --projectId=ba0d4e3a-1596-4893-96b0-858d37862bca --env=staging --path=/runtime/webapp -- \ uv run --project packages/pdf-shared python scripts/poc-aurora/enrich_demo_content.pyNote: the staging .env R2 keys are read-only; the write creds come from the
webapp runtime path in Infisical (that’s what infisical run injects). DATABASE_URL
must be the staging Neon instance (ep-muddy-wind) — the script refuses otherwise.