feat(hub): named views and sequences for blueprints

[tomasz-zajac-oss]

Summary

Until now each blueprint was one dense canvas. With this PR, blueprints ship named views and sequences, and the Hub viewer and both studio import paths use them.

The Hub format previously dropped views entirely. The few views that were already hand-authored in blueprints and patterns therefore never appeared anywhere.

Code

• hub/conceptViews.ts (new). Converts a concept's views into studio views. Three places use it:

  • the Hub viewer, which keeps the original ids;
  • both import paths (the import modal and importConcept), which remap ids to the newly created nodes, relations and sequences and prefix view names with the concept name.

  Conversion rules:

  • A view keeps only the elements that exist in the target model, so a partial blueprint import still gets usable views. A view with no remaining elements is dropped.
  • A dynamic view whose sequence was not imported becomes a static view.
  • Stored positions are applied only in the viewer. An import re-centres nodes on the viewport, so absolute positions would be wrong there.

• hubFormat / conceptToDiagramData. views is now carried through. The concept's canvas views are listed before the synthetic Wiki and Table views.

• Hub viewer. A view selector next to Canvas offers "All elements" plus the concept's own views. A view can be deep-linked with #/c/<id>/v/canvas/cv/<viewId>.

  The viewer runs in explore mode, where switching views deliberately keeps the current layout. So when you pick a view, the viewer reloads the concept laid out for that view. This is the same thing that happens on first open, and the viewer saves nothing.

Data: 47 views and 26 sequences across the 7 blueprints

• Three views in every blueprint:

  • System context: people, the platform collapsed, and external systems in one row
  • Containers
  • Governance: requirements, fitness functions and ADRs, with the elements they constrain

• One dynamic view per screen flow (19 in total). Each plays a sequence of the flow's navigates-to steps. A step description reads " → . ".

• New technical flows, each with a dynamic view, for the three blueprints that had none:

  Blueprint	Flow	Steps
  E-commerce	Place an order and pay	14
  SaaS B2B	Sign-up to a provisioned workspace	10
  Analytics	From event to dashboard	9

• Existing technical flow views. The four that already existed now have explicit positions.

Type of change

• New feature
• Bug fix (views in concept files were dropped by the Hub format)
• Tests

Checklist

• npm test passes (408/408)
• npm run typecheck passes with no errors
• New or changed behaviour is covered by tests:
  • conceptViewsToDiagram in the viewer and on import (id remap, dropped elements, static fallback, positions)
  • the cv route parameter
  • consistency of views and sequences in every blueprint

Test plan

• Checked in npm run dev:web with headless Chromium:
  • Hub, E-commerce blueprint: opened every view in the selector (System context, Containers, Place an order and pay, Governance, Shopper journey, All elements). Each shows the expected elements, and flow views show step numbers.
    • The first version of System context rendered the collapsed platform at its full expanded size, which pushed the other systems out of the row. Fixed by storing the collapsed size in that view.
  • Deep link: opening …/cv/view-flow-onboarding goes straight to the SaaS "Onboarding journey" view.
  • Studio import of the E-commerce blueprint:
    • creates 6 views, and every dynamic view has its sequence
    • also brings in the views of the related patterns (Transactional Outbox, Circuit Breaker)
    • "Shopper journey" renders as an 11-step sequence
  • No console errors.

Known issue, not introduced here: if a concept is open and only the URL hash changes to a different concept, the viewer closes and falls back to the catalogue. The same happens on main. Clicking cards and opening links in a new tab both work.

🤖 Generated with Claude Code