Add an organization-level /roadmap/ quest-line to Organization Intelligence

[szmyty]

Outcome

Add a first-class organization-level /roadmap/ experience to Organization Intelligence that visualizes the canonical Ego Hygiene organization roadmap together with the repository roadmaps that implement it.

The goal is to let a human architect answer:

What are we building across the whole organization, what is active or blocked, what can run in parallel, and what GitHub work is actually moving each initiative forward?

without opening every repository individually.

This is the dedicated Roadmap module anticipated by #27.

Dependencies

• Canonical organization-roadmap contract/source: egohygiene/hygiene#60
• Normalized organization-roadmap graph: egohygiene/observatory#22
• Existing repository /roadmap/ quest-line: egohygiene/relay#31
• Existing modular Organization Intelligence shell: Evolve Organization Intelligence into a modular fleet control plane #27
• Human-reviewed focus/portfolio projection: egohygiene/pace#25

UX model

Reuse the visual grammar of repository /roadmap/ where practical, but adapt it for organization scale.

A useful experience should support:

Organization quest line

Render organization initiatives as major chapters/quests with:

• stable initiative ID;
• title and outcome;
• horizon/phase;
• active/ready/blocked/completed/deferred/optional state;
• participating repositories;
• dependencies/blockers;
• freshness;
• progress/evidence summary;
• unresolved human decisions.

Repository contribution lanes

Within or beneath an organization initiative, show the repository roadmap nodes that contribute to it.

Allow the user to expand from:

organization initiative
    ↓
repository roadmap step
    ↓
GitHub issue / PR / commit / release evidence

Every repository roadmap node should deep-link to that repository's /roadmap/ route and canonical ROADMAP.md source.

Cross-repository dependencies

Visualize true dependency direction separately from simple conceptual relationships.

Support:

• blocked-by / depends-on edges;
• safe parallel lanes;
• enabling work;
• superseded/deferred paths;
• unresolved/inferred edges clearly marked as non-authoritative.

GitHub execution links

Expanded roadmap nodes should link directly to relevant:

• GitHub issues/epics;
• pull requests;
• commits/checks;
• releases/deployments;
• ADRs;
• audits/hygiene/sanity evidence where relevant.

The roadmap page should make GitHub feel like the underlying execution engine rather than forcing the user to mentally reconstruct the plan from issue lists.

Default orientation

The default page should optimize for reducing cognitive load and anxiety from the size of the backlog.

Show first:

1. current organization phase/horizon;
2. active initiatives;
3. blockers and human decisions;
4. safe parallel lanes;
5. the next few evidence-backed initiative outcomes;
6. collapsed later/optional work.

Do not default to displaying every GitHub issue in the organization.

Progress semantics

Do not invent a naive percentage based on closed issue count.

Progress should be derived from declared roadmap structure and evidence, with explicit unknown/partial states.

If compact progress indicators are used, expose how they are calculated and allow drill-down to underlying roadmap nodes/evidence.

Relationship to Pace focus queue

The organization roadmap is durable strategic direction.

Pace #25 is the current human-reviewed focus/Now-Next-Later-Parked projection.

The /roadmap/ experience may overlay or link to current focus, but must visually distinguish:

• strategic roadmap placement;
• currently selected execution focus.

A temporary focus change must not silently rewrite roadmap priority.

Cross-links

Integrate with the rest of Organization Intelligence:

• /sanity/ — whether the architecture behind the roadmap still makes sense;
• Hygiene — whether required platform contracts are adopted;
• Audits — findings/opportunities that may produce proposed roadmap changes;
• Decisions — ADRs affecting roadmap topology;
• Dependencies — detailed cross-repository graph;
• Releases/Distribution — delivery evidence;
• repository-level /roadmap/ routes.

Source-of-truth behavior

The generated page is a projection only.

Every initiative/node must retain links to:

• canonical organization roadmap source;
• canonical repository roadmap source;
• represented revisions;
• GitHub execution evidence.

The page must never become an independently editable roadmap database.

Partial / stale states

Support honestly:

• repository roadmap unavailable;
• organization roadmap stale;
• roadmap node with no GitHub implementation issue yet;
• issue/PR evidence newer than roadmap reconciliation;
• blocked/partial repository access;
• private repository contribution hidden in public projection;
• unknown dependency state.

Missing data must not appear complete.

Accessibility / scale

• responsive mobile-first summary;
• keyboard-accessible navigation;
• screen-reader equivalent hierarchy;
• reduced-motion mode;
• text/table equivalent for visual graphs;
• virtualization or progressive loading for large roadmaps;
• stable deep links to organization initiatives and repository nodes;
• filters/search by repository, initiative, horizon, state, owner, and dependency.

Acceptance criteria

• Organization Intelligence exposes a first-class /roadmap/ route.
• The route consumes Observatory Protect default branches and standardize organization merge governance #22 rather than independently scraping every repository in the browser.
• Organization initiatives compose repository roadmap nodes by reference.
• Repository nodes deep-link to repository /roadmap/, ROADMAP.md, and relevant GitHub work.
• True dependencies and safe parallel lanes are visible and distinguishable from related-to edges.
• Active/blocked/completed/deferred/optional/stale/unknown states render honestly.
• Strategic roadmap placement and Pace current focus are visually distinct.
• No naive closed-issue percentage is presented as strategic progress.
• Later/optional work can be collapsed so the default view remains psychologically manageable.
• Every visible item retains provenance, represented revision, and source links.
• Private repository participation cannot leak into public output.
• Mobile, keyboard, screen-reader, reduced-motion, and text-equivalent experiences are verified.

Related

• Evolve Organization Intelligence into a modular fleet control plane #27 — modular Organization Intelligence
• Add an organization-level /sanity/ architecture alignment view #28 — organization /sanity/
• egohygiene/hygiene#60 — organization roadmap contract
• egohygiene/observatory#22 — organization roadmap read model
• egohygiene/relay#31 — repository roadmap renderer
• egohygiene/pace#25 — portfolio/focus queue

Non-goals

• Replacing GitHub Issues or repository roadmaps.
• Editing roadmap strategy from the dashboard.
• Showing every open issue by default.
• Using activity or issue count as a proxy for strategic value.
• Building a separate roadmap data store.

[szmyty]

Mock/reference checkpoint: PR #31 preserves the current organization-roadmap visual north star as a versioned SVG plus explicit source-of-truth boundaries and a cross-chat CONTINUITY.md handoff.

The mock is intentionally non-canonical. It should guide the eventual /roadmap/ information architecture while #29 continues to depend on egohygiene/hygiene#60 for canonical organization-roadmap semantics and egohygiene/observatory#22 for the normalized read model.

Reference PR: #31

The visual framing is two parallel lanes: reusable engine maturation, and Flow-suite/creative proof leading to reuse by Incompris LLC and future products.