Skip to main content

Product-Forward Astro Experience System

Status: expanded reference implementation slice

The Mobilis product experience should use one repeatable visual system across documentation, sales material, demos, onboarding, marketing pages, tenant previews, and Flow Studio. Astro is the preferred framework for product-forward public and self-service surfaces because those pages need fast HTML, strong SEO/AEO behavior, reusable content, and selective interactivity.

Astro is not the design system by itself. The durable standard is:

  • shared Mobilis UI primitives
  • shared scenario and test data contracts
  • public-safe content rules
  • role-aware visibility rules
  • repeatable validation and browser smoke coverage

Framework Boundary​

Use Astro for product-forward surfaces:

  • SEO/AEO generated public pages
  • self-service product demos
  • sales and onboarding pages
  • tenant preview pages
  • Flow Studio surfaces that need to feel like product experiences instead of documentation pages

Keep Docusaurus during the transition for:

  • the existing docs portal shell
  • current Flow Studio routes and release gates
  • documentation navigation already covered by Docusaurus
  • stable validation paths that should not be disrupted by a broad re-platforming

Use React islands inside Astro when a surface needs complex interaction, such as Flow Studio role play, dataset selectors, mock runs, live-readiness panels, or admin editors.

Current Scaffold Slice​

The first repo-local implementation is a parallel static Astro build inside docs-portal. It does not replace Docusaurus.

docs-portal/
  astro.config.mjs
  src-astro/
    layouts/
      GlobalScaffold.astro
      ProductScaffold.astro
      TenantScaffold.astro
      FlowStudioScaffold.astro
      PrototypeScaffold.astro
    components/
      InfoLinkRail.astro
      RoleVisibilityBanner.astro
      LiveCheckPanel.astro
      PublicSafetyBanner.astro
      TemplateFrame.astro
      DisabledActionState.astro
      OwnershipPanel.astro
      CanonicalRoutePanel.astro
    pages/
      products/[product].astro
      prototypes/[product].astro
      tenants/[tenant].astro
  src/experience-system/
    scaffoldRegistry.mjs
    templateRegistry.mjs
    designTokens.mjs
    visualBaselines.mjs

Build it with:

cd docs-portal
npm run test:experience-system
npm run test:experience-system-browser
npm run build:astro

The Astro output goes to docs-portal/astro-build/ and is intentionally ignored by git. The normal docs portal build remains:

cd docs-portal
npm run build

For deploy artifacts, the Docusaurus build remains the root site and Astro is staged under /astro/:

cd docs-portal
npm run build
npm run build:astro
npm run stage:astro-deploy
npm run test:experience-system-deploy-artifact

This keeps existing Docusaurus routes stable while still deploying the new scaffold catalog and reference surfaces.

The reference Astro-backed routes now cover all scaffold surface types and the public-safe Flow Studio scenario set:

  • product shells: products/mobilis-seo-aeo-dashboard, products/event-submission, and products/source-ingest
  • Flow Studio shells: prototypes/mobilis-seo-aeo-dashboard, prototypes/whatsapp-submission, prototypes/whatsapp-missing-info, prototypes/fiestagenius-submission, prototypes/fiestagenius-assistant-qna, prototypes/fiestagenius-support-agent, prototypes/fiestagenius-category-taxonomy, prototypes/fiestagenius-distribution-review, prototypes/fiestagenius-dashboard, prototypes/fiestagenius-billing-readiness, prototypes/gld-event-submission, prototypes/gld-ingest-aggregator, prototypes/migente-directory, and prototypes/flow-studio-access-readiness
  • tenant shell: tenants/fiestagenius
  • prototype shells: prototypes/fiestagenius-public-chatbot and prototypes/gld-flow-studio

In the combined deploy artifact, those routes are available under /astro/... so they cannot overwrite existing Docusaurus prototype paths during the transition.

Each route inherits its visual treatment from registry data. The current theme ids include product-azure-teal, flow-slate-copper, flow-teal-rose, flow-indigo-gold, flow-forest-cyan, tenant-green-blue, and prototype-orange-teal in src/experience-system/designTokens.mjs.

Route slugs come from entry.path, not from productId. This lets public routes stay stable when a Flow Studio scenario or prototype uses a canonical product id that differs from the URL slug.

Flow Studio routes wrap the existing FlowStudioApp as React islands and keep the current Docusaurus routes stable during the transition.

Registry Contract​

Each scaffold entry must provide configuration before renderer-specific code is changed:

  • surfaceType: product, tenant, flow-studio, or prototype
  • templateId: registered in src/experience-system/templateRegistry.mjs
  • themeId: registered in src/experience-system/designTokens.mjs and matched to the surface type
  • productId and optional tenantId
  • allowedViewers and allowedRoles
  • publicSafe
  • docs
  • liveChecks
  • disabledActions
  • safetyBoundaries
  • ownership: public-safe steward, lane, source-of-truth, and review cadence metadata
  • routeExposure: public /astro visibility, /astro-scaffold preservation prefix, restricted-route state, auth source, source-of-truth, access issue when relevant, and public/restricted separation notes
  • canonicalRoute: owner repo, target path, optional owner-route URL, optional evidence/report URLs, route type, graduation stage, cutover approval, redirect behavior, scaffold reference path, scaffold-reference retention policy, rollback path, graduation checks, and current blockers

Flow Studio entries may also point to a React island. The island must consume scenario data; the Astro route should not duplicate scenario copy, role rules, denied-path behavior, or live-check meaning.

Product entries describe the product-forward shell and renderer boundary. Flow Studio entries describe scenario-driven testing, role play, denied paths, and training views for that same product.

When a Flow Studio scenario omits allowedViewers, the scaffold registry treats it as available to the same unrestricted viewer set used by FlowStudioApp. Restricted scenarios still mirror their explicit allowedViewers list.

Technical-admin-only Flow Studio scenarios are not exposed through the public Astro scaffold until server-side auth and route separation exist. The technical credential dashboard remains covered by Flow Studio validation and Docusaurus smoke paths rather than the public Astro registry.

Every public Astro entry carries routeExposure metadata. Ordinary product, tenant, prototype, and public-safe Flow Studio surfaces use restrictedRouteState: not-served-from-public-astro. Flow Studio Access Readiness uses restrictedRouteState: protected-host-verified and points to issue #194. The public route remains readiness evidence only; restricted Flow Studio evidence is served from /private/flow-studio-access/ on the Cloudflare Access protected private dashboard host. The public artifact also publishes /astro/flow-studio-access-enforcement.json, which records the protected-host contract, restricted technical scenarios, viewer claim mapping, and denied-path rules without exposing private accounts or policy secrets.

New Surface Onboarding​

Future product and tenant routes should be added in this order:

  1. Add ownership metadata first: steward, lane, source of truth, and review cadence.
  2. Add public-safe docs refs. Use user-facing docs, public launch evidence, sanitized route reports, or public-safe readiness artifacts. Mark implementation/source refs as audience: technical.
  3. Add disabled action metadata for every write, publish, payment, messaging, auth, provider, or data mutation that is visible but unavailable.
  4. Add read-only live checks with method, expected result, observed/fallback state, and public-safe evidence URL when available.
  5. Add routeExposure so public /astro visibility, preserved /astro-scaffold references, restricted-route state, auth source, and source-of-truth are explicit.
  6. Add canonicalRoute metadata before changing public route links. The owner repo, target path, evidence/report URLs, cutover approval, redirect behavior, rollback path, and scaffold-reference retention policy must be recorded in registry data.
  7. Add visual baseline coverage for the staged or preserved route before asking for owner-route cutover.

Flow Studio routes must still go through scenario data first. If copy, roles, denied paths, public-safe docs refs, disabled actions, or live-check meaning change, update the scenario pack or registry metadata before changing Astro markup.

Canonical Route Graduation Plan​

The deployed Astro scaffold is a public preview namespace, not the canonical product surface. During the transition, Docusaurus remains the root docs portal and the Astro build is staged under /astro/....

Graduation happens in small route-owned slices:

  1. Registry-ready preview: the route exists under /astro/..., has ownership, canonicalRoute, public-safe docs, disabledActions, safety boundaries, and read-only liveChecks when available.
  2. Visual baseline: visualBaselines.mjs names the staged /astro/... route and test:experience-system-deploy-artifact verifies screenshots, layout regions, theme tokens, and no horizontal overflow.
  3. Owner implementation: the product, tenant, or Flow Studio repo implements the canonical target path from canonicalRoute.targetPath without copying private docs or admin-only scenario data into public route code.
  4. Owner route live: the scaffold registry adds canonicalRoute.targetUrl, evidenceUrl, and routeReportUrl after the owner repo route deploys and publishes public-safe evidence. The /astro shell shows a prominent canonical owner-route handoff while staying available as the noindexed scaffold reference.
  5. Promotion gate: the canonical route passes the same access, visual, disabled-action, public-docs, and live-check expectations as the staged /astro/... route.
  6. Cutover approved: the registry records cutoverApproval, redirect, scaffoldReferencePath, and rollback metadata. Deployment staging writes explicit _redirects entries and preserves the noindexed scaffold evidence route under /astro-scaffold/....
  7. Redirect enabled: public /astro/... product links redirect to the product/tenant-owned URL while the preserved scaffold reference remains available for evidence, visual baseline, and rollback review.
  8. Retirement hardening: redirect-enabled routes must carry scaffoldReferencePolicy metadata. The current valid mode is preserved-evidence-route with retain status. A route cannot move toward pointer-only, non-public evidence, or retirement until the owner route has longer-lived production evidence, a still-green route report, deploy-artifact visual baseline history, a recorded rollback decision, and public-safe docs/validation history that stays discoverable after retirement.
  9. Retirement: the scaffold registry entry is removed or converted to a pointer only after the canonical route has satisfied the retirement hardening gates and issue #348 records the explicit route-by-route decision.

Never graduate a route by editing only Astro page code. Route and copy changes must enter through scenario, tenant, prototype, product, or registry data first.

Scaffold-Reference Retirement Policy​

Do not remove /astro-scaffold/... routes as part of ordinary route graduation. Redirect-enabled routes must preserve a noindexed evidence route until a separate retirement decision proves all of the following:

  • The owner route has at least one later production deployment after the first redirect cutover.
  • Owner deployment evidence and route reports remain HTTP 200, public-safe, and read-only.
  • The preserved /astro-scaffold/... route remains covered by deploy-artifact browser validation and visual baselines.
  • A rollback owner records whether the reference can become pointer-only, move behind a non-public evidence surface, or remain public noindex.
  • Public-safe docs refs and validation history remain discoverable after any retirement action.

The staging manifest now carries each redirect's scaffoldReferencePolicy, every route's routeExposure, the Flow Studio access-enforcement artifact, the SEO/AEO scaffold readiness artifact at /astro/seo-aeo-scaffold-readiness.json, and a generated scaffold-reference retirement audit at /astro/scaffold-reference-retirement-audit.json. Deploy-artifact validation checks that preserved references stay noindexed, display the retirement gate, keep visual baseline coverage, and remain marked retain until issue #348 records an explicit route-by-route decision. The retirement audit now records option three as future development with retain as the current decision, keeping option-two redirects and option-three retirement from blurring together.

The retirement audit is also the route-level control plane for future pointer-only or non-public evidence decisions. Each redirect-enabled route records:

  • owner-route URL, deployment evidence, route report, scaffold visual baseline, rollback path, and public-safe docs/validation history gates
  • a minimum 14-day owner-route evidence-age gate measured from cutover approval
  • pending gates for a later owner-route production deployment and explicit rollback-owner decision
  • allowed decisions for the current state; routes stay retain only until every gate passes
  • per-route blockers that can be posted publicly because they contain counts, routes, and evidence labels, not private provider data or secret values

Template And Theme Customization​

Templates choose the scaffold layout and reusable primitives. Themes choose public-safe visual tokens: page background, muted surface, primary action color, accent color, soft accent background, and strong border color.

New products, tenants, Flow Studio entries, and prototypes should customize the scaffold in this order:

  1. Add or select a templateId in templateRegistry.mjs.
  2. Add or select a themeId in designTokens.mjs.
  3. Add the surface entry in scaffoldRegistry.mjs.
  4. Add renderer markup only for content that cannot be expressed as registry, scenario, tenant, or prototype data.

The global Astro layout applies data-surface-tone, data-theme-id, and CSS variables to the route. The catalog applies those same variables to each card so product, tenant, Flow Studio, and prototype entries visibly use their own template color system before any custom page code is added.

Shared UI Primitives​

The shared visual system must define these primitives before individual teams redesign them:

  • page shell and navigation
  • role and viewer banners
  • dataset/test-case selectors
  • tabs and segmented controls
  • checklists and evidence rails
  • disabled live/write action states
  • ownership and review metadata
  • canonical route graduation metadata
  • info links and public how-to links
  • review queues and blocker panels
  • primary and secondary CTA patterns
  • technical-only evidence panels

Cards should be used for repeated items and tool panels, not nested page sections. Operational interfaces should stay dense, scannable, and action-oriented. Marketing and onboarding pages may be more expressive, but should still reuse the same primitives.

Flow Studio Rules​

Flow Studio remains scenario-driven. Scenario data describes the workflow, role visibility, information links, test datasets, live checks, and public-safety boundaries. UI code renders that model.

Flow Studio Astro work must preserve these rules:

  • Lower-permission viewers cannot access higher-permission views.
  • Non-technical viewers see platform behavior and how-to guidance, not API payloads, state changes, audit trails, source links, or implementation details.
  • Technical admin and developer viewers may see implementation evidence when it is useful.
  • Public Flow Studio content must not expose secrets, real phone numbers, production IDs, private messages, confidential partner details, private repositories, or non-public source URLs.
  • Live mode must be read-only unless a separate issue explicitly implements protected write behavior and validation.

Visual Baselines​

src/experience-system/visualBaselines.mjs records the required deploy-artifact baselines. The current set covers:

  • /astro/experience-system/
  • /astro-scaffold/products/mobilis-seo-aeo-dashboard/
  • /astro-scaffold/products/event-submission/
  • /astro-scaffold/products/source-ingest/
  • /astro-scaffold/prototypes/mobilis-seo-aeo-dashboard/?viewer=non-technical-admin&role=admin&surface=desktop-console
  • /astro-scaffold/prototypes/whatsapp-submission/?viewer=non-technical-admin&role=admin&surface=mobile-app
  • /astro-scaffold/prototypes/whatsapp-missing-info/?viewer=non-technical-admin&role=moderator&surface=mobile-app
  • /astro-scaffold/prototypes/fiestagenius-submission/?viewer=non-technical-admin&role=admin&surface=mobile-app
  • /astro-scaffold/prototypes/fiestagenius-assistant-qna/?viewer=non-technical-admin&role=admin&surface=mobile-app
  • /astro-scaffold/prototypes/fiestagenius-support-agent/?viewer=non-technical-admin&role=admin&surface=mobile-app
  • /astro-scaffold/prototypes/fiestagenius-category-taxonomy/?viewer=non-technical-admin&role=admin&surface=mobile-app
  • /astro-scaffold/prototypes/fiestagenius-distribution-review/?viewer=non-technical-admin&role=admin&surface=mobile-app
  • /astro-scaffold/prototypes/fiestagenius-billing-readiness/?viewer=non-technical-admin&role=admin&surface=mobile-app
  • /astro-scaffold/prototypes/gld-event-submission/?viewer=non-technical-admin&role=moderator&surface=desktop-console
  • /astro-scaffold/prototypes/gld-ingest-aggregator/?viewer=non-technical-admin&role=moderator&surface=mobile-app
  • /astro-scaffold/prototypes/migente-directory/?viewer=non-technical-admin&role=moderator&surface=mobile-app
  • /astro/prototypes/flow-studio-access-readiness/?viewer=non-technical-admin&role=admin&surface=desktop-console
  • /astro-scaffold/tenants/fiestagenius/
  • /astro-scaffold/prototypes/fiestagenius-public-chatbot/

The deploy artifact test opens those staged or preserved scaffold-reference routes in Chromium, takes full-page screenshots, verifies expected theme ids and visual regions, rejects horizontal overflow, and verifies approved _redirects entries. Add a baseline whenever a future product, Flow Studio shell, tenant shell, or prototype becomes part of the public scaffold contract.

Reference Migration Slice​

The first Astro-backed slice was the Mobilis SEO/AEO product experience:

  • the SEO/AEO engine owns the real Astro renderer and dashboard preview
  • Flow Studio owns the role-aware cockpit, scenario validation, and browser smoke coverage
  • shared test cases cover premade data first and read-only live evidence second
  • publish actions stay disabled until protected dashboard routes and server-side capability checks exist

The next registry batches expanded that same scaffold contract across Event Submission, Source Ingest, FiestaGenius, GLD, Mi Gente, and public Flow Studio access-readiness surfaces without replacing the Docusaurus docs portal. GLD event submission and GLD source ingest remain separate entries, scenarios, and lane boundaries.

The first owner-route handoff is now live for the SEO/AEO product shell:

  • owner repo: mobilis-seo-aeo-engine
  • staged scaffold route: /astro/products/mobilis-seo-aeo-dashboard/
  • owner route: https://mobilis-seo-aeo-engine.pages.dev/products/mobilis-seo-aeo-dashboard/
  • route report: https://mobilis-seo-aeo-engine.pages.dev/reports/product-canonical-routes.json
  • deployment evidence: https://mobilis-seo-aeo-engine.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/products/mobilis-seo-aeo-dashboard/ to the owner route, keeps /astro-scaffold/products/mobilis-seo-aeo-dashboard/ as the noindexed scaffold reference, and keeps deployment evidence plus route reports linked from the catalog and scaffold panel.

The second owner-route handoff is live for the Event Submission product shell:

  • owner repo: mobilis-product-event-submission
  • staged scaffold route: /astro/products/event-submission/
  • owner route: https://mobilis-product-event-submission.pages.dev/products/event-submission/
  • route report: https://mobilis-product-event-submission.pages.dev/reports/product-canonical-routes.json
  • deployment evidence: https://mobilis-product-event-submission.pages.dev/reports/deployment-evidence.json
  • runtime preflight report: https://mobilis-product-event-submission.pages.dev/reports/dashboard-runtime-config-preflight.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/products/event-submission/ to the owner route, keeps /astro-scaffold/products/event-submission/ as the noindexed scaffold reference, and keeps deployment evidence plus route reports linked from the catalog and scaffold panel.

The Event Submission owner route now also publishes the dashboard request-boundary, Clerk session verifier, Clerk claim adapter, session-adapter, route-protection, protected-entry, runtime preflight report, runtime remote secret audit, runtime source-lane guard, runtime operator bridge, runtime live-entry probe, private row-source probe, live-row-loader, Supabase access-policy, claim-proof-verifier, paid-state-verifier, and access-guard contracts in public-safe evidence. Product and tenant dashboard shells can reference read-only request handling, signed-session verification, sanitized account-claim mapping, disabled-provider behavior, safe route actions, protected-entry orchestration, stale-session denial, organization-match denial, server-side Mobilis identity labels, public-safe runtime state labels, remote secret presence labels, source-lane guard labels, operator readiness labels, live probe summary labels, row-source probe status labels, tenant-scoped row loading, read-only database policy, tenant-bound proof readiness, tenant-bound paid readiness, account-state, tenant-match, claim-proof, admin-review, paid-feature, visible-section, and disabled-action expectations without exposing provider payloads, private records, proof values, session values, account identifiers, private contact identifiers, protected setup values, key names, secret names, billing identifiers, or admin-only data.

Latest Event Submission dashboard contract evidence:

  • product PRs: mobilis-product-event-submission#25, #26, #30, #31, #32, #33, #34
  • product issue: mobilis-product-event-submission#29 closed as completed
  • merge commit: ebec25ef9b5fe70f66929c8667920e8edd255598
  • immutable deployment: https://f124b51c.mobilis-product-event-submission.pages.dev/products/event-submission/
  • route report: https://mobilis-product-event-submission.pages.dev/reports/product-canonical-routes.json
  • runtime preflight report: https://mobilis-product-event-submission.pages.dev/reports/dashboard-runtime-config-preflight.json
  • runtime remote secret audit: https://mobilis-product-event-submission.pages.dev/reports/dashboard-runtime-remote-secrets-audit.json
  • runtime source-lane guard: mobilis-product-event-submission#24
  • runtime row-source probe and dedicated schema: mobilis-product-event-submission#25, mobilis-product-event-submission#26
  • runtime live-entry probe: https://github.com/Mobilis-Mobile/mobilis-product-event-submission/blob/main/scripts/dashboard_runtime_live_probe.mjs
  • runtime row-source probe script: https://github.com/Mobilis-Mobile/mobilis-product-event-submission/blob/main/scripts/dashboard_runtime_row_source_probe.mjs
  • Pages Function status: public-safe protected-entry route readiness, runtime configuration readiness, runtime preflight state labels, ready remote secret presence labels, source-lane guard labels, runtime operator readiness labels, live probe summary labels, row-source probe status labels, missing-session redirect behavior, stale-session denial, organization-match denial, and server-side identity-contract handling are reported. The latest immutable and stable product routes return safe no-store/noindex missing-session redirects, and the public reports confirm the remote secret-label audit is ready without secret names or values. Provider writes, tenant launch publishing, claim-proof expansion, paid-feature expansion, and tenant-specific rollout gates remain separate.

Static Clerk auth shell status:

  • Docusaurus now owns public-safe /sign-in/ and /sign-up/ shell routes.
  • The docs navbar and Astro scaffold header expose sign-in/sign-up entry points without changing Flow Studio scenario access, allowedViewers, denied paths, or RestrictedScenarioView behavior.
  • The shell remains static-build compatible. It renders a placeholder when the public Clerk publishable-key setting is absent and activates the Clerk client only when that public setting is present at build time.
  • This shell is not live dashboard authorization. Product-owned server-side Clerk verification and row-source loading now pass on the Event Submission owner route, and FiestaGenius now records public-safe claim-proof, paid-state, and rollback-coverage decisions on its tenant owner route. Production tenant dashboards still require server-side proof verification, provider-backed paid state, and owner acceptance before they expose more than public-safe readiness.

The third owner-route handoff is live for the Source Ingest product shell:

  • owner repo: mobilis-product-source-ingest
  • staged scaffold route: /astro/products/source-ingest/
  • owner route: https://mobilis-product-source-ingest.pages.dev/products/source-ingest/
  • route report: https://mobilis-product-source-ingest.pages.dev/reports/product-canonical-routes.json
  • deployment evidence: https://mobilis-product-source-ingest.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/products/source-ingest/ to the owner route, keeps /astro-scaffold/products/source-ingest/ as the noindexed scaffold reference, and keeps deployment evidence plus route reports linked from the catalog and scaffold panel. Full retirement of the scaffold reference remains backlog work until the owner route has longer-lived production evidence and a separate rollback decision.

The fourth owner-route handoff is live for the FiestaGenius tenant shell:

  • owner repo: mobilis-tenant-fiestagenius
  • staged scaffold route: /astro/tenants/fiestagenius/
  • owner route: https://mobilis-tenant-fiestagenius.pages.dev/tenants/fiestagenius/
  • route report: https://mobilis-tenant-fiestagenius.pages.dev/reports/tenant-canonical-routes.json
  • deployment evidence: https://mobilis-tenant-fiestagenius.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/tenants/fiestagenius/ to the owner route, keeps /astro-scaffold/tenants/fiestagenius/ as the noindexed scaffold reference, and keeps deployment evidence plus route reports linked from the catalog and scaffold panel. Full retirement remains backlog work under #348.

The fifth owner-route handoff is live for the FiestaGenius public chatbot prototype shell:

  • owner repo: mobilis-tenant-fiestagenius
  • staged scaffold route: /astro/prototypes/fiestagenius-public-chatbot/
  • owner route: https://mobilis-tenant-fiestagenius.pages.dev/prototypes/fiestagenius-public-chatbot/
  • route report: https://mobilis-tenant-fiestagenius.pages.dev/reports/tenant-canonical-routes.json
  • deployment evidence: https://mobilis-tenant-fiestagenius.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/prototypes/fiestagenius-public-chatbot/ to the tenant-owned prototype route, keeps /astro-scaffold/prototypes/fiestagenius-public-chatbot/ as the noindexed scaffold reference, and keeps deployment evidence plus route reports linked from the catalog and scaffold panel. Full retirement remains option-three backlog work under #348.

The FiestaGenius dashboard owner-route handoff is live for the mobile dashboard readiness shell:

  • owner repo: mobilis-tenant-fiestagenius
  • staged scaffold route: /astro/prototypes/fiestagenius-dashboard/
  • owner route: https://mobilis-tenant-fiestagenius.pages.dev/dashboard/fiestagenius/
  • route report: https://mobilis-tenant-fiestagenius.pages.dev/reports/tenant-canonical-routes.json
  • deployment evidence: https://mobilis-tenant-fiestagenius.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/prototypes/fiestagenius-dashboard/ to the tenant-owned dashboard readiness route, keeps /astro-scaffold/prototypes/fiestagenius-dashboard/ as the noindexed scaffold reference, and keeps production Pages protected-entry configuration, live Clerk session verification, tenant claim mapping, Supabase dashboard reads/writes, WhatsApp return links, Stripe, calendar publishing, private distribution, and production publish disabled until their dedicated launch gates pass.

The FiestaGenius dashboard route now carries dashboardRequestBoundary, dashboardClerkSessionVerifier, dashboardClerkClaimAdapter, dashboardClerkLaunchGates, dashboardSessionAdapter, dashboardRouteProtection, dashboardProtectedEntry, dashboardRuntimeConfigReadiness, dashboardLiveRowLoader, dashboardSupabaseAccessPolicy, dashboardClaimProofVerifier, dashboardPaidStateVerifier, dashboardRollbackCoverage, and dashboardAccessGuard metadata sourced from the Event Submission product contracts and tenant owner-route decisions. This now includes public-safe evidence that the product owner route has an env-gated Pages Function protected-entry route, a runtime configuration readiness checklist, a runtime preflight report, a remote secret audit, a runtime source-lane guard, a private operator bridge for applying reviewed runtime state, a live-entry probe for deployed redirect/live-row behavior, and a private row-source probe for selected public dashboard columns. The tenant owner route also publishes dashboardClerkLaunchGates, dashboardClaimProofVerifier.tenantDecisionEvidence, dashboardPaidStateVerifier.tenantDecisionEvidence, and dashboardRollbackCoverage: Clerk launch gates map account states, denied-access evidence, owner acceptance steps, rollout marker clerk-cross-project-rollout-2026-05-28, and disabled live-entry gates; signed-link and owner-approved proof are future server-only paths after tenant/session/submission matching; phone/OTP proof remains blocked until public sender compliance evidence exists; paid dashboard features remain blocked until provider-backed entitlement evidence and tenant owner approval pass; and rollback coverage is recorded as retain-public-noindex. This is still readiness evidence, not live auth: live rows remain blocked until production Pages protected-entry configuration, Clerk route protection, signed-session verification, tenant mapping, denied-access evidence review, Supabase RLS/access review, server-side proof verification, provider-backed paid state, and tenant owner approval pass.

Latest FiestaGenius dashboard owner-route evidence:

  • tenant PRs: mobilis-tenant-fiestagenius#32, #33, #34, #35
  • merge commit: 3e4cfed8e39ec6c6b34e9e7fc71415f34d94b928
  • immutable deployment: https://62e446f8.mobilis-tenant-fiestagenius.pages.dev/dashboard/fiestagenius/
  • route report: https://mobilis-tenant-fiestagenius.pages.dev/reports/tenant-canonical-routes.json
  • product preflight report: https://mobilis-product-event-submission.pages.dev/reports/dashboard-runtime-config-preflight.json
  • product remote secret audit: https://mobilis-product-event-submission.pages.dev/reports/dashboard-runtime-remote-secrets-audit.json
  • product source-lane guard: mobilis-product-event-submission#24
  • product row-source probe: mobilis-product-event-submission#25
  • tenant row-source probe evidence: mobilis-tenant-fiestagenius#29
  • tenant public identifier scrub: mobilis-tenant-fiestagenius#30
  • tenant latest live-row evidence propagation: mobilis-tenant-fiestagenius#32
  • tenant claim-proof and paid-state decision evidence: mobilis-tenant-fiestagenius#33
  • product operator bridge: mobilis-product-event-submission#21
  • product live-entry probe: mobilis-product-event-submission#22
  • product live-row-safe deployment evidence: mobilis-product-event-submission#33 at https://f4ef38c0.mobilis-product-event-submission.pages.dev/products/event-submission/

The sixth owner-route handoff is live for the WhatsApp Submission Flow Studio shell:

  • owner repo: mobilis-flow-studio
  • staged scaffold route: /astro/prototypes/whatsapp-submission/
  • owner route: https://mobilis-flow-studio-scenarios.pages.dev/prototypes/whatsapp-submission/
  • route report: https://mobilis-flow-studio-scenarios.pages.dev/reports/flow-studio-canonical-routes.json
  • deployment evidence: https://mobilis-flow-studio-scenarios.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/prototypes/whatsapp-submission/ to the scenario-owned route on the dedicated Flow Studio scenario Pages project, keeps /astro-scaffold/prototypes/whatsapp-submission/ as the noindexed scaffold reference, and keeps deployment evidence plus route reports linked from the catalog and scaffold panel. Additional Flow Studio shell handoffs should use the same dedicated owner host instead of the architecture docs portal project.

The seventh owner-route handoff is live for the WhatsApp Missing Info Flow Studio shell:

  • owner repo: mobilis-flow-studio
  • staged scaffold route: /astro/prototypes/whatsapp-missing-info/
  • owner route: https://mobilis-flow-studio-scenarios.pages.dev/prototypes/whatsapp-missing-info/
  • route report: https://mobilis-flow-studio-scenarios.pages.dev/reports/flow-studio-canonical-routes.json
  • deployment evidence: https://mobilis-flow-studio-scenarios.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/prototypes/whatsapp-missing-info/ to the scenario-owned route on the dedicated Flow Studio scenario Pages project, keeps /astro-scaffold/prototypes/whatsapp-missing-info/ as the noindexed scaffold reference, and keeps deployment evidence plus route reports linked from the catalog and scaffold panel.

The eighth owner-route handoff is live for the FiestaGenius Submission Flow Studio shell:

  • owner repo: mobilis-flow-studio
  • staged scaffold route: /astro/prototypes/fiestagenius-submission/
  • owner route: https://mobilis-flow-studio-scenarios.pages.dev/prototypes/fiestagenius-submission/
  • route report: https://mobilis-flow-studio-scenarios.pages.dev/reports/flow-studio-canonical-routes.json
  • deployment evidence: https://mobilis-flow-studio-scenarios.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/prototypes/fiestagenius-submission/ to the scenario-owned route on the dedicated Flow Studio scenario Pages project, keeps /astro-scaffold/prototypes/fiestagenius-submission/ as the noindexed scaffold reference, and keeps deployment evidence plus route reports linked from the catalog and scaffold panel.

The ninth owner-route handoff is live for the FiestaGenius Assistant Q&A Flow Studio shell:

  • owner repo: mobilis-flow-studio
  • staged scaffold route: /astro/prototypes/fiestagenius-assistant-qna/
  • owner route: https://mobilis-flow-studio-scenarios.pages.dev/prototypes/fiestagenius-assistant-qna/
  • route report: https://mobilis-flow-studio-scenarios.pages.dev/reports/flow-studio-canonical-routes.json
  • deployment evidence: https://mobilis-flow-studio-scenarios.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/prototypes/fiestagenius-assistant-qna/ to the scenario-owned route on the dedicated Flow Studio scenario Pages project, keeps /astro-scaffold/prototypes/fiestagenius-assistant-qna/ as the noindexed scaffold reference, and keeps deployment evidence plus route reports linked from the catalog and scaffold panel.

The tenth owner-route handoff is live for the FiestaGenius Support Agent Flow Studio shell:

  • owner repo: mobilis-flow-studio
  • staged scaffold route: /astro/prototypes/fiestagenius-support-agent/
  • owner route: https://mobilis-flow-studio-scenarios.pages.dev/prototypes/fiestagenius-support-agent/
  • route report: https://mobilis-flow-studio-scenarios.pages.dev/reports/flow-studio-canonical-routes.json
  • deployment evidence: https://mobilis-flow-studio-scenarios.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/prototypes/fiestagenius-support-agent/ to the scenario-owned route on the dedicated Flow Studio scenario Pages project, keeps /astro-scaffold/prototypes/fiestagenius-support-agent/ as the noindexed scaffold reference, and keeps deployment evidence plus route reports linked from the catalog and scaffold panel.

The eleventh owner-route handoff is live for the FiestaGenius Category Taxonomy Flow Studio shell:

  • owner repo: mobilis-flow-studio
  • staged scaffold route: /astro/prototypes/fiestagenius-category-taxonomy/
  • owner route: https://mobilis-flow-studio-scenarios.pages.dev/prototypes/fiestagenius-category-taxonomy/
  • route report: https://mobilis-flow-studio-scenarios.pages.dev/reports/flow-studio-canonical-routes.json
  • deployment evidence: https://mobilis-flow-studio-scenarios.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/prototypes/fiestagenius-category-taxonomy/ to the scenario-owned route on the dedicated Flow Studio scenario Pages project, keeps /astro-scaffold/prototypes/fiestagenius-category-taxonomy/ as the noindexed scaffold reference, and keeps deployment evidence plus route reports linked from the catalog and scaffold panel.

The twelfth owner-route handoff is live for the FiestaGenius Distribution Review Flow Studio shell:

  • owner repo: mobilis-flow-studio
  • staged scaffold route: /astro/prototypes/fiestagenius-distribution-review/
  • owner route: https://mobilis-flow-studio-scenarios.pages.dev/prototypes/fiestagenius-distribution-review/
  • route report: https://mobilis-flow-studio-scenarios.pages.dev/reports/flow-studio-canonical-routes.json
  • deployment evidence: https://mobilis-flow-studio-scenarios.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/prototypes/fiestagenius-distribution-review/ to the scenario-owned route on the dedicated Flow Studio scenario Pages project, keeps /astro-scaffold/prototypes/fiestagenius-distribution-review/ as the noindexed scaffold reference, and keeps deployment evidence plus route reports linked from the catalog and scaffold panel.

The thirteenth owner-route handoff is live for the FiestaGenius Billing Readiness Flow Studio shell:

  • owner repo: mobilis-flow-studio
  • staged scaffold route: /astro/prototypes/fiestagenius-billing-readiness/
  • owner route: https://mobilis-flow-studio-scenarios.pages.dev/prototypes/fiestagenius-billing-readiness/
  • route report: https://mobilis-flow-studio-scenarios.pages.dev/reports/flow-studio-canonical-routes.json
  • deployment evidence: https://mobilis-flow-studio-scenarios.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/prototypes/fiestagenius-billing-readiness/ to the scenario-owned route on the dedicated Flow Studio scenario Pages project, keeps /astro-scaffold/prototypes/fiestagenius-billing-readiness/ as the noindexed scaffold reference, and keeps Stripe checkout, customer portal, webhook/subscription writes, and API payload panels disabled or hidden until protected billing controls and tenant approval exist.

The fourteenth owner-route handoff is live for the GLD Event Submission Flow Studio shell:

  • owner repo: mobilis-flow-studio
  • staged scaffold route: /astro/prototypes/gld-event-submission/
  • owner route: https://mobilis-flow-studio-scenarios.pages.dev/prototypes/gld-event-submission/
  • route report: https://mobilis-flow-studio-scenarios.pages.dev/reports/flow-studio-canonical-routes.json
  • deployment evidence: https://mobilis-flow-studio-scenarios.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/prototypes/gld-event-submission/ to the scenario-owned route on the dedicated Flow Studio scenario Pages project, keeps /astro-scaffold/prototypes/gld-event-submission/ as the noindexed scaffold reference, and keeps guarded Supabase review writes, connector publishing, source-queue ownership, and API payload panels disabled or hidden until protected GLD submitter-chat controls exist.

The fifteenth owner-route handoff is live for the Mobilis SEO/AEO Dashboard Flow Studio shell:

  • owner repo: mobilis-flow-studio
  • staged scaffold route: /astro/prototypes/mobilis-seo-aeo-dashboard/
  • owner route: https://mobilis-flow-studio-scenarios.pages.dev/prototypes/mobilis-seo-aeo-dashboard/
  • route report: https://mobilis-flow-studio-scenarios.pages.dev/reports/flow-studio-canonical-routes.json
  • deployment evidence: https://mobilis-flow-studio-scenarios.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/prototypes/mobilis-seo-aeo-dashboard/ to the scenario-owned route on the dedicated Flow Studio scenario Pages project, keeps /astro-scaffold/prototypes/mobilis-seo-aeo-dashboard/ as the noindexed scaffold reference, and keeps publish actions, tenant data writes, provider writes, and API payload panels disabled or hidden. The separate SEO/AEO product-owned route remains in mobilis-seo-aeo-engine.

The SEO/AEO scaffold readiness artifact now ties the product shell and Flow Studio shell together:

  • readiness report: /astro/seo-aeo-scaffold-readiness.json
  • status: complete-public-scaffold
  • checks: product-owned redirect, scenario-owned redirect, scenario-driven Flow Studio data, public-safe docs refs, disabled actions, read-only live checks, visual baselines, retained /astro-scaffold references, and technical-admin-only scenario exclusion
  • backlog: protected dashboard publish controls remain product-owned work, and option-three scaffold-reference retirement remains tracked under issue #348

The sixteenth owner-route handoff is live for the GLD Ingest and Aggregator Flow Studio shell:

  • owner repo: mobilis-flow-studio
  • staged scaffold route: /astro/prototypes/gld-ingest-aggregator/
  • owner route: https://mobilis-flow-studio-scenarios.pages.dev/prototypes/gld-ingest-aggregator/
  • route report: https://mobilis-flow-studio-scenarios.pages.dev/reports/flow-studio-canonical-routes.json
  • deployment evidence: https://mobilis-flow-studio-scenarios.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/prototypes/gld-ingest-aggregator/ to the scenario-owned route on the dedicated Flow Studio scenario Pages project, keeps /astro-scaffold/prototypes/gld-ingest-aggregator/ as the noindexed scaffold reference, and keeps source queue writes, publish package writes, submitter-chat ownership, and API payload panels disabled or hidden.

The seventeenth owner-route handoff is live for the Mi Gente Directory Flow Studio shell:

  • owner repo: mobilis-flow-studio
  • staged scaffold route: /astro/prototypes/migente-directory/
  • owner route: https://mobilis-flow-studio-scenarios.pages.dev/prototypes/migente-directory/
  • route report: https://mobilis-flow-studio-scenarios.pages.dev/reports/flow-studio-canonical-routes.json
  • deployment evidence: https://mobilis-flow-studio-scenarios.pages.dev/reports/deployment-evidence.json

The scaffold now records this as redirect-enabled. The approved migration behavior redirects /astro/prototypes/migente-directory/ to the scenario-owned route on the dedicated Flow Studio scenario Pages project, keeps /astro-scaffold/prototypes/migente-directory/ as the noindexed scaffold reference, and keeps directory correction writes, production publish, and API payload panels disabled or hidden. Reusable marketplace claim/correction ownership remains future product backlog work.

The GLD Flow Studio Delivery Lanes route remains a scaffold-preview switchboard. It links the already separated GLD event-submission and source-ingest lanes but does not duplicate canonical ownership or merge lane-local scenario copy.

The Flow Studio Access Readiness route remains a public-safe readiness shell with routeExposure.restrictedRouteState set to protected-host-verified. Technical-admin-only credential dashboard scenarios remain excluded from public Astro routes and are represented through the private Flow Studio access evidence route. Reusable Mi Gente claim/correction ownership remains future marketplace product backlog work; public routes continue to show correction intent as disabled launch feedback only.

The active post-cutover backlog is tracked in Project Completion Backlog. As of May 29, 2026, the immediate architecture-repo CI/deploy blockers are cleared; the remaining P0 work is real SEO/AEO Clerk/Mobilis authorization binding evidence and real authenticated Flow Studio viewer-claim mapping.

Related issues: