Skip to content

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
  • 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 messages badge and the cockpit grows a Thread tab.
    • A few are pre-submitted so the routing-landing beat (“→ GP-x”) shows.

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).

  1. Open /inbox as Aurora. Point out the lived-in queues across sites.
  2. 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.
  3. Email order — open one, show the body, hit Show email / attachment to toggle. This is the “the PO is buried in an email” pain.
  4. 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.
  5. 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 98a9d319d before you present.)

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.

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:

Terminal window
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:

Terminal window
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.

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):

Terminal window
cd /Users/mc-boone/Dv/erp-unlocked
set -a; source .env; set +a
infisical 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.py

Note: 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.