Public Demo Surfaces

Overview

Logrite has two public, sign-in-free surfaces, both served by the Frontend container and both living inside the React router rather than beside it.

/app-recordings is a recorded library — narrated screen captures with a synchronised cue track. The guided walkthrough is a live tour that runs on the real application routes, inside the real DashboardLayout, with a fixture transport feeding demo data to the genuine product screens.

Caution

Rewritten 2026-08-15. Everything this page previously said about /experience/<problem-slug> described a separate, purpose-built demo UI — its own chooser, its own scenes, its own components. That build was deleted. It reproduced the product instead of showing it, which meant every screen a prospect saw was one nobody could sign in and find.

The walkthrough now has no screens of its own. It is an overlay on /ai-warden, /agents, /analytics/discover, /generator, /logrite-cortex and /m26-14 — the real URLs, the real sidebar, the real controls.

Setting	Value
Served by	Frontend (Deployd-io/Logrite-UI), port 3000
Recorded library	/app-recordings — static, no auth, no backend
Guided walkthrough	Six walkthroughs on the real product routes. Entry: ?tour=<id> on any route, /tour (picker), or /experience/<id> for a signed-out visitor
Auth	None on the public path. The walkthrough also runs for signed-in users, on their own account, showing the same demo data
Backend contact	POST /api/v1/demo-requests (lead form) and /api/v1/demo-events (telemetry) only — everything else is refused by the transport
Branch	feat/platform-tour in Logrite-UI

Note

The rule both surfaces share: a public page must never read auth state for its own behaviour and never call an authenticated API. The walkthrough goes further and replaces the network transport outright, because it renders the real feature components — see Default-deny transport.

Recorded walkthroughs — /app-recordings

The recordings are static files under public/app-recordings/, produced by a recording rig the component’s header comment names as new-arch_or_extend/demo-portal — which is not in this repo or on the dev VM, so treat the checked-in assets as the source of truth:

public/app-recordings/
├── manifest.json          # 8 videos: id, name, tagline, problem, solution, route, file, cues, duration
├── personas.json          # 4 role personas, each an ordered list of section ids
└── media/
    ├── <id>.mp4           # 102–177 s each, ~16 min in total
    └── <id>.cues.json     # {section, name, duration, cues:[{t, step, total, title, desc, vo}]}

Section id	Title	Mirrors route	Length
ai-warden	AI Warden	/ai-warden	118 s
generator-compliance	Generator / Compliance Flow	/generator	114 s
analytics	Analytics	/analytics	177 s
cortex-ai	Cortex AI	/logrite-cortex	108 s
collector-agents	Collector Agents	/agents	116 s
agent-flow	Automated Generator Flow	/agents-flow/onboarding	102 s
m26-14	M-26-14 Maturity	/m26-14	107 s
dashboard	Dashboard	/dashboard	106 s

The four personas in personas.json (dev, sre, sec, lead) do not change the content — each is an ordering of the same eight sections, so an SRE opens on Dashboard and a security lead opens on M-26-14. The open section lives in the URL as ?s=<id>, so a walkthrough can be linked to directly and Back leaves the player rather than the page.

serve.json redirects /demo, /demo/ and /demo/index.html here. Those redirects are load-bearing for anything already sharing a /demo link and are deliberately untouched by the /experience work.

Why it is a React route and not a static page

Read the header comment in src/components/AppRecordings/AppRecordings.jsx before “simplifying” this — it is the kind of constraint that costs an afternoon to rediscover.

The container serves the built app with serve dist -s. serve-handler applies the -s catch-all rewrite (** → /index.html) before it ever stats a directory, and re-applies the remaining rules recursively, so no extensionless URL can be made to resolve to a standalone app-recordings/index.html. /app-recordings would always land on the SPA, hit the protected-route wrapper, and bounce to /login. Owning the clean URL inside the router is what makes it both clean and sign-in free — the component then fetches the static JSON sitting next to it.

The guided walkthrough

Entry points

Four, and the branch selects the behaviour rather than the slug:

Entry	Who it is for	What happens
/experience	A stranger with no idea which walkthrough they want	The public landing page: six walkthroughs grouped by problem. Calls no API and reads no auth state
/experience/<tour-id>	A stranger who has chosen, or anyone with a shared link	Arms sandbox mode, then redirects to the walkthrough’s first real path. The visitor spends the whole tour on genuine product URLs
?tour=<tour-id> on any route	A shared link, and the picker	Consumed once, stripped from the URL, and navigates to step 1’s route
/tour	Anyone, any time	A picker listing all six walkthroughs. Permanent entry in the sidebar’s bottom nav, and the first card on the Support page
First login	A new account	Offered once, on /dashboard only, gated on the showPlatformTour user setting

Note

/experience/<id> is an entry route, not a place. It records sandbox mode in sessionStorage and hands over to the real path immediately.

Two designs were tried and abandoned, both worth recording. A nested <MemoryRouter> so the real sidebar’s absolute <Link to="/agents"> would resolve inside a sandbox: React Router 7 refuses outright — “You cannot render a <Router> inside another <Router>”. Nested <Routes> under a splat: <Routes> may nest, but child paths resolve relative to the parent, and all ~73 platform routes are absolute. Rewriting them would fork the route tree, which is the one thing this must not do.

The landing page, and why it is grouped by problem

/experience and /tour render one component, src/tour/ui/WalkthroughIndex.jsx, in two variants — public and in-app. They were two pages for about a day and the copy had already begun to diverge.

Caution

Bare /experience used to send strangers to /login. There was no such route, so it fell through to the * catch-all, which is auth-gated — and that is the URL a person guesses and a marketing site links.

The cards lead with a symptom, not a pillar name. The walkthroughs are named Governing your AI traffic, Finding the log you need — facts about our product, not about anyone’s week — and a stranger has to translate each one into a problem they recognise before they can choose. The grouping and problem copy live in src/tour/content/useCases.js, apart from the tours themselves so content and layout stay separable.

Five of the six problem statements are verbatim from src/experience/content/slugs.js as it stood before commit a9cf594d deleted it (git show a9cf594d^:src/experience/content/slugs.js). Its authoring rules came back with the copy and are restated in the file:

no question mark in a headline · no radio buttons · no “Step 1 of 3”, no progress bar · no Continue button — the cards are the action · every card leads with a symptom the visitor has experienced · no persona is named on any card

That last rule is why there is no role filter, even though public/app-recordings/personas.json would supply one: “For CISOs” on a card is the single thing that makes a chooser feel like a form.

Note

The public variant must not arm the sandbox. TourSandboxEntry owns that flag and arms it at the moment a visitor commits to a walkthrough. Arming it on the listing page would leave a live sandbox in the tab of someone who read the page, decided against it, and went to /login.

It also must not read auth state or call an API — the browser suite asserts zero requests leave the page.

The six walkthroughs

Each is one file under src/tour/content/tours/, registered in index.js. Every step names a route, an anchor selector that must already exist in src/, and optionally an act that presses a real control.

id	Name	Steps	Runs on
ai-governance	Governing your AI traffic	7	/ai-warden
search-everything	Finding the log you need	6	/analytics/discover, /analytics/semantic-search
collect-everything	Getting logs off your hosts	7	/agents
ask-your-logs	Asking your logs a question	7	/logrite-cortex
instrument-your-code	Writing the log nobody wrote	7	/generator
prove-compliance	Proving it to an auditor	4	/m26-14

Caution

A tour file that exists but is not registered in index.js fails in the most confusing way available: the ?tour= token is consumed and stripped, getTour returns null, and the visitor sits on /dashboard with no walkthrough and no error. A concurrent edit dropped one import and the symptom read as an intermittent engine bug. npm run check:tour-anchors now fails the build on that mismatch, naming the tour.

Gentle rails, not a cage

Off-script clicks are permitted. Wandering to a screen the walkthrough does not cover shows a light “this screen isn’t part of the walkthrough” card with a way back — it never blocks.

That is a design decision with a matching implementation detail: the spotlight scrim carries pointerEvents: 'none'. It was 'auto' at one point, which swallowed every click outside the cutout and turned the whole “gentle rails” design into a cage while every automated assertion stayed green.

The synthetic-data disclosure

The walkthrough shows the same demo data to everyone, including a signed-in customer looking at what is otherwise their own dashboard. Without a permanent, non-dismissible disclosure that customer is shown fabricated AI Warden traffic and a fabricated M-26-14 score with nothing on screen saying so.

TourRail carries a SYNTHETIC DATA badge that is first in the reading order, has no close button, and renders on every branch including off-script — the moment a visitor wanders is precisely when they are looking at fabricated numbers with no step explaining them.

The rail is position: sticky, not fixed: a fixed bar is the classic WCAG 2.2 §2.4.11 failure because it can cover the element someone just tabbed to.

Default-deny transport

src/tour/runtime/ patches fetch, XMLHttpRequest, WebSocket and EventSource. Axios uses the XHR adapter, so every HTTP client in the app bottoms out in one of these.

An unmatched request is refused, never forwarded. That is what makes it safe to arm around a signed-in session: no authenticated call can leave the browser whatever the caller does.

Two deliberate holes, and only two:

Path	Why
/api/v1/auth/**	A lockout fix. Default-deny used to swallow sign-in and token refresh, so a ?tour= link followed while signed out redirected to /login with a form that could never succeed
/api/v1/demo-events, /api/v1/demo-requests	Telemetry and the lead form — the only calls that are supposed to leave

Note

A <img src> is invisible to a fetch patch. One component fetched favicons from google.com through an image tag and leaked straight past the transport; the fix was to drop that block, not to widen the patch. When auditing this, remember that images, stylesheets and fonts are not HTTP clients you can intercept this way.

Routes are origin-pinned. /health is one segment with no product prefix and both the AI service and semantic search want it. Registering an origin-less pattern alongside the pinned one made the bare route match every origin, so Cortex’s /health answered semantic search’s request with the wrong body and /analytics/semantic-search sat in its service-unavailable state for the entire walkthrough — while every assertion passed, because the anchor resolved fine and the spotlight landed neatly on an error card.

Demo data for everyone

One data path, signed in or out. seedAll() seeds all six pillars at once rather than per route, because gentle rails means the visitor can click any sidebar entry at any moment and a pillar they wander into must not be empty merely because the script had not reached it.

For a signed-out visitor the shell is wrapped in a second Redux store built from rootReducer with preloadedState: { user: { isLoggedIn: true, … } }. The nested store is not a convenience: the real user slice has its own userPersistConfig writing to localStorage, so setting that field on the real store would persist it and the visitor would appear signed in across every tab and reload with a session that does not exist. The synthetic user’s token is deliberately empty — nothing is minted and nothing is signed.

The founder card — video region and narration region

One floating card, 322×360, holding two regions: a 16:9 video region and a narration region beneath it. Absent below 768px, collapses to a pill at 768–1023, pauses on step change without rewinding, picks a corner away from the coach-mark, and yields when the coach-mark reports a collision.

Caution

There is no footage. Every mp4 in public/tour/video/ is a title slate reading “Founder video — NOT YET RECORDED” over a footer counting elapsed seconds, with no audio track at all — confirmed by extracting frames, not by trusting filenames. The ten .vtt files are not captions for a video; they are the entire content, and they are real, written narration.

So the card ships with the narration playing under a designed poster, and hasFootage: false. Drop real recordings into public/tour/video/<slug>.mp4 and flip VIDEOS_ARE_PLACEHOLDERS in src/tour/content/videos.js — the region becomes a <video autoplay muted playsinline> with an unmute control and a caption track. A constant rather than an env var, because which assets are real is a fact about the repository, not about where it is deployed.

Three decisions worth keeping:

• Autoplay is muted, always. Every modern browser blocks autoplay with sound; muted autoplay plus a one-click unmute is the only thing that works without a user gesture. prefers-reduced-motion turns the automatic half off entirely and leaves the manual controls.
• The poster is drawn twice. Inline SVG inside the component, and as public/tour/video/poster.svg for the <video poster> attribute — because a poster attribute takes a URL and a detached asset cannot read the app’s theme. The theme here is a redux-persisted user choice written as inline custom properties, not prefers-color-scheme, so an <img> would show a light poster to a dark-theme user on a light OS.
• The card is a fixed height on purpose. A cue changes every few seconds; a content-sized narration region would resize the card, re-fire onRect, re-place the coach-mark and reopen the render loop this feature has already been frozen by once.

Note

The .vtt files are fetched at runtime, and default-deny refused them. The card fetched its only content, was denied, and rendered nothing — while passing 54/54 in a standalone harness, because no transport is armed there. /tour/ is now a passthrough prefix (still first-party gated). Any future runtime-fetched asset under public/ needs the same treatment.

Lead capture

POST /api/v1/demo-requests, from the permanent rail link and again at the end of a walkthrough. Reaching the last step used to unmount the whole overlay, leaving the visitor on a screen full of demo data with no disclosure and nothing to do next.

Caution

The endpoint is live on dev and returns 404 on prod (verified 2026-08-15: dev-leapfrogapi.logrite.ai → 202 {"status":"SUCCESS"}, leapfrogapi.deployd.io → 404). The backend half is on a feature branch that has not reached main. Until it does, the lead form on production will show its error state — which is the correct failure, but the wrong outcome.

The form posts cross-origin, so Chromium sends a real OPTIONS preflight first. The passthrough is matched on pathname and is method-agnostic, so admitting the path admits the preflight.

The demo data, and the four defects that lived in it

The walkthrough’s fixtures are not only what a step touches. Gentle rails means a visitor can click anything, and four defects lived in that gap while every step-level assertion stayed green. All four are fixed; they are recorded because each is a shape that will recur.

Defect	What a visitor saw	Cause
A field filter that did not filter	status_code:504 returned 53 rows, 6 of them 504s	the field:value branch ended in a bare substring test that discarded the field; _source is nested, so dotted paths always fell through to it
A fifth of every result list as raw JSON	walls of JSON beside clean cards on semantic search	446 of 2318 documents are spans and carried no message; both renderers fall back to JSON.stringify(_source)
A Trace Review of nothing, or of everything	SPANS 1000, DURATION 246972776.00ms, most rows Unknown Operation	every document minted its own trace id (446 one-span traces), and runSearch had no term handling — so a null query meant match-all
A file breakdown with counts over an empty list	“4 files” above nothing, and no Copy button	skippedFiles.files was [] while counts was populated; the modal gates Copy on list.length > 0

Note

Two lessons worth carrying. A fixture that answers a query it does not understand with the whole corpus does not look broken — it looks populated, which is why the trace modal shipped. And grouping spans into traces by document position produces a 64-minute trace, because the documents come from a diurnal arrival process over seven days; spans have to be grouped by time, which is only knowable once every document exists.

npm run check:tour-fixtures now asserts these invariants directly — every document has a message, a field query scopes to its field, no trace exceeds a minute, every document’s trace holds at least one span, a term query is not treated as match-all, and every skipped-files bucket lists exactly as many files as it counts. It also reads the tour copy and checks the hit count it quotes is the one the screen shows: compressing spans onto their trace clock moved two documents out of the default 24-hour window, and the copy silently became wrong by two. Cheap, deterministic and browser-free, so it runs alongside the fast checks rather than in the browser job.

Verification — a real browser is mandatory

Caution

jsdom cannot verify this feature. It has no layout (every element measures 0×0), no hit-testing, it stores inert without honouring it, and it has no CORS. Defects that lived in exactly that blind spot while hundreds of assertions stayed green include: an unbounded async render loop that froze the tour, a coach-mark pushed to x=1420 in a 1440px viewport, a sticky rail at y=3524, a scrim that swallowed every click, and two chunks initialising in a cycle that blanked the entire app.

npm run check:tour-anchors     # in CI — every anchor exists, every tour is registered
npm run check:tour-fixtures    # in CI — invariants of the demo data itself
npm run check:tour-browser     # in CI since 2026-08-16, as its own parallel job

Note

All three run in CI as of 2026-08-16, on pushes as well as pull requests. Two gaps closed together. checks.yml fired on pull_request only while docker-deploy.yml fires on push, so the one path that actually reaches an environment — every hotfix pushed straight to dev — was the one path with nothing in front of it. And check:tour-browser, the only check that can see layout, ran nowhere but a developer’s terminal.

The browser check is a separate job because playwright install pulls ~115MB, and charging that to the feedback loop for a lint error is how a pipeline gets ignored. It builds synchronously, polls the server to 200, then measures — npm run build && npx serve dist & backgrounds the entire && list, which once passed 62/62 against a stale bundle that did not contain the fix under test.

check:tour-browser drives all six walkthroughs end to end, the public landing page, the signed-out sandbox, the three in-product triggers, the CTA, the first-login auto-start in both directions, the two modals a visitor reaches off-script, and a responsive matrix at 390 / 768 / 1024 / 1440. 121 checks locally; on the live dev URL two groups skip rather than pass, because /tour and /support correctly bounce a synthetic session to /login.

Two of those checks exist because the defects they guard were invisible to everything else:

• every spotlight rings its own anchor reads each step’s anchor selector out of the tour files and compares the ring’s rect to the element’s. 14 of 38 steps once failed it, the worst by 1241px — a ring drawn entirely off the screen — while every other assertion passed. “An anchor resolved” and “the ring is drawn around it” are different claims and only the first was ever being made.
• the step card does not move after it appears samples the card’s rect from before the click and fails over 8px. The card used to travel up to 563px after the step’s text was on screen.

Note

One assertion is worth calling out: nothing covers the Next button, done with elementFromPoint rather than a visibility check. The founder card once sat on top of Next at a higher z-index — perfectly visible, reported visible by Playwright, and swallowing every click, so the collector walkthrough sat on step 1 of 7 forever. Visibility and clickability are different claims and only one of them matters.

Build with the full env or the app requests undefined/api/v1/..., which matches no fixture route and you will debug the wrong thing:

VITE_API_BASE_URL  VITE_WARDEN_RELAY_URL  VITE_AI_SERVICE_API  VITE_ANALYTICS_PROXY_API
VITE_DASHBOARD_PROXY_API  VITE_SEMANTIC_SEARCH_API_URL  VITE_OSD_VERSION

Caution

Build synchronously and poll the server until it answers 200 before measuring. npm run build && npx serve dist & backgrounds the whole list, so a following sleep races the build and the checks measure the previous bundle. That is how a fix which was not in the tree once “passed” 62/62, and how the negative test that should have caught it passed too.

Caution

Never waitUntil: 'networkidle' against a live origin. Something is almost always in flight — a Cloudflare beacon, an analytics ping, a retry — so it throws a 60s TimeoutError and kills the run mid-suite. Use domcontentloaded and then wait for the thing being tested.

The same class, three more times: the coach-mark is deliberately visibility: hidden while its position resolves, so any single isVisible() poll races the placement and bails out — reporting a broken walkthrough that is fine. Wait for controls; do not sample them once.

Caution

.env.tourcheck holds the env to build with, and the analytics vars carry a PATH. VITE_ANALYTICS_PROXY_API is https://dev-leapfrogapi.logrite.ai/api/v1/analytics, not a bare host — services/osAuth.js:4 says so. Building with the host alone sends every Analytics call to /_cat/indices instead of /api/v1/analytics/_cat/indices, which matches no fixture route, so default-deny refuses it and Discover renders “Cannot Reach Analytics” with 0 hits.

The walkthrough still reported PASS in that state, because its steps fell back to anchors that exist on the empty screen. The suite now asserts Discover renders rows and a non-zero hit count, which is the assertion that catches a mis-built bundle.

Still open

• Real founder recordings. Ten placeholder slates; the narration is real and already playing. Drop the mp4s in and flip one constant.
• The lead endpoint on prod. Live on dev, 404 on main.

Closed 2026-08-17 — every walkthrough has its own script

search-everything was the last tour with no honest video match: it borrowed general, a platform overview, at confidence: 'fallback'. It now has search-everything.vtt, written for its six steps rather than rehomed onto them — the 356-hit histogram, the 6 sets of logs and their origin badges, sendgrid returning 4 HTTP 429s, 34 fields nobody configured, a line opening whole, and the “slow database queries” chip returning deadlock detected, which carries none of those three words.

It keeps the tour’s own ordering of the argument: keyword search working first, the “you have to know the text” limit as the pivot, semantic search as the answer to that sentence — the same capability-then-limit shape tours/analytics.js adopted after leading with the limitation was found to cost every visitor who left at step 4.

No row in TOUR_VIDEOS is 'fallback' any more. The value stays in the type so that the next walkthrough added without a script has to declare it rather than quietly borrow someone else’s. general moved to UNUSED_VIDEOS, where it joins audit-evidence, pii-in-logs and slow-payments; nothing outside videos.js names it, because videoForTour is keyed by tour id and the chooser has no video region.

npm run check:tour-videos now guards the set: every registered slug has a readable .vtt and .mp4, every mapped slug exists in VIDEOS, seconds is within 1s of the real last-cue end, and every cue is ≤2 lines of ≤42 characters. The .mp4 assertion is the load-bearing one — a slug with no paired file is inert today and a 404 <video> the moment VIDEOS_ARE_PLACEHOLDERS goes false, which is precisely the one-line change the ship gate advertises as safe.