Runtime Session Map Publishing

We want the runtime-session map to become a real page inside the design app rather than staying only as a qmap experiment route. The strongest path is the native integration approach: a dedicated design-site page that imports qmap's public runtime-session wrapper and surrounds it with design-app navigation, narrative framing, and future companion surfaces.

That work should not begin yet. qmap still has active changes in c24, and the current experiment variants mix stable public exports with repo-local assumptions that are not ready to be treated as a design-site contract. Starting the port now would create churn on both sides and force the design app to absorb unstable qmap internals.

This cycle exists to capture the intended publish path, define the boundaries, and make the start conditions explicit so we can move cleanly once qmap is ready.

Record the implementation plan for a design-app-native runtime-session map page, using qmap's public exports and design-owned page scaffolding, while deliberately deferring code execution until qmap c24 settles.

In:

• cycle record and planning artifacts in cycles/c42.runtime-session-map-publishing/
• definition of the design-side route and page responsibility
• proposed boundaries between design-owned data/helpers and qmap-owned runtime-session primitives
• readiness criteria for starting implementation
• phased plan for a first publish pass and a later enhanced pass

Out for now:

• creating the actual design-app route
• porting qmap experiment files into this repo
• importing qmap-private internals into the design app
• moving VOX/OBJ model assets
• implementing the c23 model-lab variant inside the design site before qmap is stable

Phase 1: Publish The Native Runtime Session Page

When the dependency gate clears, build a design-side page that:

• uses QMapRuntimeSession and related public qmap helpers
• ports the stable c22 interaction model for source selection, grouping, and live polling
• frames the surface as part of the design app's visualization and storytelling system

Phase 2: Evaluate Enhanced Visual Treatment

Only after the first publish pass is stable, decide whether the c23 model-lab work should be:

• promoted into qmap as a stable extension point
• extracted into design-owned assets/helpers
• or kept as an experiment-only branch outside the published design surface

• CYCLE.md
• execution-plan.md

Potential later deliverables once implementation begins:

• /visualization/runtime-session-map page
• design-owned runtime-session fixtures and live-session helpers
• visualization index entry and narrative framing around the published page

This cycle remains in planning mode until the qmap dependency gate clears. Its job is to preserve the intended architecture and start conditions so the eventual implementation can move quickly without re-deciding the integration shape.

This cycle does not authorize implementation yet.

Implementation should wait until:

• qmap c24 has stabilized the runtime-session surface we intend to consume
• the public qmap API needed by the design app is confirmed as the intended integration boundary
• any c23-only asset or entity-model experiments are either promoted to a stable home or explicitly left out of the first design-side publish pass

The intended first publish target is a real design-app page under /visualization, built natively in Nuxt and wrapped in <ClientOnly> like the other visualization pages.

That page should:

• import qmap's public runtime-session exports rather than qmap experiment files
• own its page-level controls, explanatory copy, and information architecture in the design app
• keep fixtures, live-fetch helpers, and presentation wiring in design-owned files
• avoid direct dependencies on qmap experiment-local paths such as dev/experiments/...

The first pass should publish the runtime-session map experience, not the full c23 custom-model lab.

1. What is the exact public qmap API boundary the design app should consume for runtime-session rendering?
2. Which parts of the current qmap runtime-session experience belong in the first design publish pass, and which should stay experimental?
3. Which data adapters and live-fetch helpers should be owned by design versus qmap?
4. What readiness signal from qmap c24 is sufficient to begin implementation without inviting churn?
5. Should the first published page be a pure visualization surface, or should it launch with adjacent explanatory and provenance UI?

The plan is now captured, but execution is intentionally deferred.

Current decision:

• proceed later with the native design-app integration path
• do not embed or iframe the qmap experiment as the primary publish strategy
• do not start the port until qmap c24 is ready for a stable consumer