Skip to main content

Intention Flyout Navigation

What should the Playbook hand a reader before it shows the warehouse?

The Playbook navigation should behave like a First Mate, not like a warehouse shelf.

A reader arrives with an intention: learn the system, name something, make a decision, publish wisdom, build demand, prove a claim, or improve a loop. The navigation layer should hand them the right chart for that intention before it asks them to understand the folder tree.

The full tree still matters. It is the atlas. But the atlas is not the first interface under cognitive load.

Problem​

The current left-hand playbook menu fails two jobs.

The physical failure shows up on long pages: the sidebar behaves like an oversized static document element, not a viewport-height scroll container. A reader can lose the navigation while reading.

Second, it fails conceptually. It exposes taxonomy before intention. A reader who needs Naming Standards, Knowledge Schema, Wiki Control Plane, Rhetoric, Wisdom, or Matrix Thinking must already know the system well enough to find the gateway that teaches the system.

That is backwards.

The navigation system must answer one question:

What are you trying to do?

Then it should expose a small number of intention routes, each with a map, gateway pages, instruments, and proof of completion.

Interaction Model​

The default playbook left nav should become an intention flyout.

PLAYBOOK
  What are you trying to do?
    Learn the system       -> Knowledge Schema, Wiki Control Plane, Matrix Thinking
    Name something         -> Naming Standards, DDL, Dreamineering Symbols
    Make a decision        -> Wisdom, Decision Making, Situational Read
    Publish wisdom         -> Rhetoric, Wisdom, FLOW exit routes
    Build demand           -> Function Specs, Business Instruments, Stackmates handoff
    Prove a claim          -> Reality Scoreboard, Evidence, VVFL
    Improve a loop         -> VVFL, Meta Learning, Navigation

  Current page
    Why this page
    Nearby gateway
    Next article
    Proof of completion

  Full atlas
    Wiki Index
    Domain Matrix
    All docs tree

The visible sidebar should stay compact. The flyout carries depth only when the reader asks for a route.

Gateway Map​

Learn the system​

First gateway: Knowledge Schema

Second page: Wiki Control Plane

Instrument: schema table plus representation contract

Completion signal: the reader can say what exists, how it is known, where it belongs, and what representation it needs.

Name something​

First gateway: Naming Standards

Second page: DDL Nomenclature

Instrument: Name Integrity Stack

Completion signal: the name has ontology, epistemology, taxonomy, nomenclature, and axiology.

Make a decision​

First gateway: Wisdom

Second page: Decision Making

Instrument: situational read

Completion signal: the decision has state of play, state of mind, right move, prediction, and kill signal.

Publish wisdom​

First gateway: Rhetoric

Second page: Wisdom

Instrument: Rhetoric Tight Five

Completion signal: the artifact names reader, claim, proof path, changed decision, and kill condition.

Build demand​

First gateway: Function Catalog

Second page: Business Instruments

Instrument: demand story

Completion signal: the demand names outcome, evidence, Definition of Ready, and commissioning proof.

Prove a claim​

First gateway: Reality

Second page: Evidence

Instrument: receipt and proof-state

Completion signal: the claim is REALITY, DREAM, or CONSUMED with a proof path.

Improve a loop​

First gateway: VVFL Loop

Second page: Matrix Thinking

Instrument: feedback loop plus gap matrix

Completion signal: the loop increases situational wisdom and agency with a metric.

Diagram​

Each gateway route needs one diagram because the representation is part of the cognition.

The diagrams should be simple A&ID-style reader maps:

INTENTION -> GATEWAY -> INSTRUMENT -> PROOF -> NEXT QUESTION

Example for naming:

Name something
  -> Naming Standards
  -> Name Integrity Stack
  -> canonical name plus authority
  -> what action is now easier?

Example for learning:

Learn the system
  -> Knowledge Schema
  -> anchor-domain matrix
  -> governed schema row
  -> which gap is genuinely new?

The flyout should show the same shape for each route so readers learn the navigation grammar once.

Instrument Philosophy​

The flyout is not a menu of pages. It is an agent handing instruments to a reader.

First Mate: more knowledgeable other at the reader's edge. Hands the chart for the next leg.

Gateway page: domain guide. Explains the map.

Instrument page: reusable method. Does one kind of thought-work.

Proof page: reality check. Shows whether the move worked.

Full atlas: expert fallback. Supports exhaustive browsing.

This keeps the playbook from becoming a library that merely stores knowledge. The system should help readers choose the next instrument that increases agency.

Component Direction​

This navigation system serves Dreamineering and Stackmates. It should become a reusable navigation component family, not a one-off Docusaurus sidebar.

Ownership split:

Navigation doctrine belongs in the Dream repo. Its job is to define intent routes, gateway maps, rhetoric, knowledge architecture, and proof signals.

Language system belongs in the Dream repo. Its job is to use DDL Nomenclature and Dreamineering Symbols so routes have canonical terms, DML codes, and A&ID symbols.

Route and intention graph belongs in the Dream repo first, then a generated envelope. Its job is to expose serializable route data that humans and agents can consume.

Interaction primitives belong in Stackmates ui-interactive. Their job is to provide rail, menu, drawer, search, disclosure, sidebar, and navigation behavior.

Diagram language belongs in Stackmates ui-symbols. Its job is to render A&ID-style pictures for intent -> gateway -> instrument -> proof.

Design proof belongs in the Stackmates design-system app. Its job is to explore variants, compare UX, dogfood screenshots, and choose the component contract before production use.

Candidate Stackmates components:

  • Searchable persistent left rail: libs/app-client/ui-interactive/src/lib/blocks/SearchableNavigationRail
  • Top flyout / mega menu behavior: libs/app-client/ui-interactive/src/lib/molecules/NavigationMenu
  • Mobile intent drawer: libs/app-client/ui-interactive/src/lib/molecules/Drawer
  • Persistent app sidebar mechanics: libs/app-client/ui-interactive/src/lib/molecules/Sidebar
  • Ordered map previous/next affordance: libs/app-client/ui-interactive/src/lib/molecules/MapSubpageNav
  • Intent-flow diagram: libs/app-client/ui-symbols/src/lib/organisms/AgentInstrumentFlowDiagram
  • A&ID concept map: libs/app-client/ui-symbols/src/lib/organisms/AgentInstrumentDiagram
  • Visual exploration harness: apps/stackmates/stackmates-design-system/src/app/diagrams

The first reusable component should use a serializable route shape:

type IntentNavigationRoute = {
  id: string;
  label: string;
  headline: string;
  intentJob: string;
  href: string;
  canonicalTerm?: string;
  dmlCode?: string;
  aidSymbol?: string;
  picture?: {
    kind: "flow" | "matrix" | "aid" | "map";
    diagramId?: string;
    summary: string;
  };
  gatewayRole: "primary" | "support" | "instrument" | "proof" | "atlas";
  instrumentType: string;
  proofSignal: string;
  nextRoutes: string[];
  searchText: string;
};

That lets Dream generate the graph, Stackmates render and test it, and both repos consume the same navigation intelligence without copying prose.

UX Variants​

Use the Stackmates design-system app to compare variants before committing the Dream site.

Intent Rail: best for the Playbook left nav replacement. Shape: search at top, intent groups, active route context, full atlas fallback.

Story Mega Menu: best for the top Hero's Journey menu. Shape: where/why/who/kairos sections with headline thoughts and route cards.

Diagram Navigator: best for /playbook/navigation and Stackmates /diagrams. Shape: A&ID flow from intent to gateway to instrument to proof to next question.

Command Palette: best for agent and human power users. Shape: search by intention, page, instrument, proof, domain, DDL term, or DML code.

Venture Decision Rail: best for the ventures portfolio. Shape: chooser-fit rails for inspect, support, contribute, pressure-test, or ignore for now.

The likely best v1 is a hybrid:

Desktop: Intent Rail + diagram preview + atlas fallback
Mobile: Drawer with same intent groups + search
Navigation hub: full Diagram Navigator
Top menu: Story Mega Menu

Data Contract​

Gateway pages need explicit frontmatter or generated facets.

intent_jobs:
  - learn-the-system
  - name-something
reader_state: learning
gateway_role: primary
instrument_type: schema
proof_surface: receipt
diagram_required: true

Minimum fields:

intent_jobs: which reader intentions this page serves.

gateway_role: primary, support, instrument, proof, or atlas.

instrument_type: schema, standard, decision, rhetoric, demand, proof, or loop.

proof_surface: receipt, gauge, kill condition, metric, worked example, or none.

diagram_required: whether the page must expose a visual map.

The generated manifest should preserve these fields so First Mate, the flyout, wiki projections, and search can all read the same envelope.

Checks​

The navigation change is not done until these tests pass.

Sidebar usability: on desktop, the playbook left nav remains visible and scrolls independently from page content.

Mobile usability: the mobile menu opens into intention routes before taxonomy buckets.

Naming path: from any playbook page, a reader can reach Naming Standards in two clicks through "Name something."

Learning path: from any playbook page, a reader can reach Knowledge Schema in two clicks through "Learn the system."

Wisdom path: from any playbook page, a reader can reach Wisdom in two clicks through "Make a decision" or "Publish wisdom."

Atlas fallback: the full folder tree is still available, but never the default first decision.

Diagram contract: each primary gateway route exposes a simple intention -> gateway -> instrument -> proof -> next question diagram.

Build Sequence​

  1. Fix the physical sidebar bug: sticky viewport-height container with independent scroll.
  2. Add intention facets to the key gateway pages.
  3. Extend the generated playbook manifest with intention fields.
  4. Promote First Mate from hub decoration into the default playbook flyout model.
  5. Move the full atlas behind explicit Wiki Index / Full Atlas controls.
  6. Add the gateway diagrams to Knowledge Schema, Naming Standards, Rhetoric, Wisdom, Wiki Control Plane, and Matrix Thinking.
  7. Dogfood the golden paths above on desktop and mobile.
  8. Prototype reusable variants in Stackmates design-system using ui-interactive plus ui-symbols.
  9. Promote the chosen component contract back into Dream's Docusaurus sidebar or a shared generated navigation envelope.

Failure Modes​

Archive or redesign this model if:

  • readers still need folder knowledge to find the gateway pages;
  • the flyout becomes another exhaustive tree;
  • diagrams decorate instead of changing route choice;
  • the navigation no longer makes the next article easier to choose;
  • the system improves browsing but does not improve decisions, proofs, or agency.
  • Stackmates component exploration produces a beautiful component that cannot consume Dream's serializable route graph.
  • Dream hardcodes a component shape that Stackmates cannot reuse across products, ventures, and diagrams.

Context​

Questions​

Which reader intention should hold the top slot: learn the system, name something, make a decision, publish wisdom, build demand, prove a claim, or improve a loop?

  • Which prototype should prove the shared graph first: Intent Rail, Diagram Navigator, or Story Mega Menu?
  • What picture best explains the bridge from intent story to execution know-how?
  • Which route field should become mandatory first: headline thought, proof signal, DDL term, DML code, or A&ID symbol?