Roadmap: complete the Repository Intelligence and Organization Intelligence visual control plane

[szmyty]

Outcome

Coordinate the remaining human-facing Intelligence/dashboard surfaces across Ego Hygiene so one focused implementation thread can build the visual control plane without rediscovering ownership or creating duplicate dashboards.

The system already has a strong architectural split:

canonical repository/org sources
        ↓
Hygiene / Aether contracts
        ↓
Egolint / Relay / specialist evidence
        ↓
Observatory normalized read models
        ↓
Relay repository Intelligence
        +
Organization Intelligence

This issue is a tracking roadmap only. Actual implementation remains in the owning repositories/issues below.

Product goal

The visual control plane should reduce the need to keep organization state in working memory.

A maintainer should be able to return after rapid parallel work and answer:

• What am I working on?
• What is next?
• What is blocked?
• What has actually shipped?
• What does the architecture mean?
• Does the architecture still make sense to me?
• Which contracts are missing or stale?
• What did recent audits find?
• What decisions caused the current state?
• Which repositories depend on each other?
• What should I inspect deeply versus ignore for now?

Every dashboard is a derived compression/navigation layer, never canonical state.

Existing repository-level foundation

Parent experience:

• egohygiene/relay#27 — Repository Intelligence shared experience
• egohygiene/relay#33 — deterministic build/publication

Already delivered or previously scoped:

• egohygiene/relay#31 — /roadmap/ scrollable quest-line
• egohygiene/relay#28 — shared shell + /now/
• egohygiene/relay#30 — /decisions/
• egohygiene/relay#32 — /journey/
• egohygiene/relay#29 — /dependencies/, /health/, /releases/, /work/, /search/, /compare/

New focused views:

• egohygiene/relay#74 — /audits/
• egohygiene/relay#75 — /hygiene/
• egohygiene/relay#76 — /sanity/

Additional domain-specific Repository Intelligence views should be added only when they answer a distinct question and consume an existing normalized model.

Organization-level foundation

• Build an organization-level Intelligence portal at egohygiene.io/intelligence/ #15 — baseline organization Intelligence portal
• Evolve Organization Intelligence into a modular fleet control plane #27 — modular fleet control-plane shell
• Add an organization-level /sanity/ architecture alignment view #28 — organization /sanity/
• Add an organization-level /roadmap/ quest-line to Organization Intelligence #29 — organization /roadmap/

Organization modules anticipated by #27 include:

• Now;
• Roadmap;
• Decisions;
• Identity;
• Hygiene;
• Audits;
• Sanity;
• Health;
• Dependencies;
• Releases / Distribution;
• Repositories/search.

Create dedicated implementation issues only when a module's data contract and question are sufficiently distinct from existing work.

Normalized-data dependencies

Core graph

• egohygiene/observatory#7 — normalized Repository Intelligence graph

Hygiene

• egohygiene/observatory#5 — fleet Hygiene conformance

Audits

• egohygiene/observatory#20 — normalized audit evidence

Architecture coherence / sanity

• egohygiene/observatory#21 — normalized coherence-review + human-ratification posture

Roadmap

• egohygiene/observatory#22 — organization-roadmap + cross-repository initiative read model

Distribution

• egohygiene/observatory#13 — package availability/version/installability

Organization portability/privacy

• egohygiene/observatory#17 — organization namespaces and multi-organization read models

Contract / source dependencies

Audit system

• egohygiene/aether#86 — composable audit profiles
• egohygiene/reflector#258 — repository/fleet audit orchestration

Sanity / architecture alignment

• egohygiene/aether#87 — architecture-coherence review skill
• egohygiene/hygiene#59 — human-ratification policy

Roadmap continuity

• egohygiene/hygiene#60 — canonical organization roadmap
• egohygiene/aether#88 — roadmap-impact PR completion hook
• egohygiene/pace#29 — fleet rollout of roadmap reconciliation

Audit capability rollout

• egohygiene/pace#28 — fleet rollout of canonical audit capability

Recommended dashboard delivery sequence

Do not wait for every live integration before designing UI. Use deterministic synthetic fixtures where upstream schemas are sufficiently stable, but pin accepted schemas before final integration.

Wave 0 — shell and navigation

1. Reconcile current state of relay#27, relay#28, and relay#33.
2. Reconcile current state of organization portal Build an organization-level Intelligence portal at egohygiene.io/intelligence/ #15 and modular shell Evolve Organization Intelligence into a modular fleet control plane #27.
3. Establish one information architecture, state vocabulary, evidence drawer pattern, deep-link convention, responsive behavior, and visual grammar.

Wave 1 — existing high-value navigation

4. Ensure repository /roadmap/ remains integrated and polished.
5. Complete /now/, /decisions/, and /journey/ as the base reorientation loop.
6. Wire /dependencies/, /health/, /releases/, /work/, /search/, and /compare/ progressively rather than in one oversized PR.

Wave 2 — new control-loop pages

7. Build repository /hygiene/ against Observatory fixtures.
8. Build repository /audits/ against Observatory fixtures.
9. Build repository /sanity/ against coherence/ratification fixtures.

These may proceed in parallel after the shared shell patterns are stable.

Wave 3 — organization aggregation

10. Complete the baseline organization Intelligence portal.
11. Add organization Roadmap.
12. Add organization Sanity.
13. Add organization Hygiene and Audits modules from the same Observatory snapshots used by repository views.
14. Add organization dependencies, decisions, identity, releases/distribution, and health modules as their models become available.

Wave 4 — live canaries and fleet expansion

15. Prove a small, large, and partially adopted public repository.
16. Prove organization aggregation when one or more repositories are unavailable/stale.
17. Add repositories incrementally through deterministic publication/manifest workflows.
18. Keep private/local organization views separately authorized.

UX invariants

Every view must:

• answer one primary human question;
• show a compact orientation before detail;
• preserve unknown/stale/partial/blocked/not-applicable states;
• avoid opaque universal scores;
• link every material claim to canonical evidence;
• show represented revision and freshness;
• preserve authoritative versus inferred relationships;
• support mobile, keyboard, screen readers, and reduced motion;
• use progressive disclosure for large histories;
• remain useful with partial adoption;
• never require the user to open 29 dashboards just to understand organization posture.

Cognitive-load rule

Default views should emphasize:

• now;
• blockers;
• human decisions;
• stale evidence;
• next attention;
• current roadmap horizon.

Later/optional/backlog-heavy detail should be collapsed or filtered by default.

The dashboard should reduce backlog anxiety, not visualize the entire backlog at maximum density.

GitHub as execution layer

Where a dashboard represents executable work, deep-link directly to GitHub Issues/PRs rather than reimplementing issue editing.

The intended flow is:

Intelligence visualization
        ↓ click
canonical roadmap / ADR / report
        ↓ click
GitHub issue / PR / commit / release

Parallel work protocol

A dashboard-focused implementation chat may work autonomously through one bounded issue/checkpoint at a time:

1. verify live GitHub state and dependencies;
2. choose the next dependency-ready dashboard issue;
3. implement only that bounded issue;
4. validate locally/CI;
5. reconcile roadmap/continuity/ADR impact as required;
6. open a PR for maintainer review;
7. do not merge it;
8. report the next dependency-ready dashboard issue.

Do not create one giant cross-repository dashboard PR.

Program acceptance criteria

• Repository and organization Intelligence use one coherent visual/information architecture.
• Roadmap, Sanity, Audits, Hygiene, Decisions, Now, Journey, Health, Dependencies, Releases, Work, Search, and Compare have explicit questions/owners.
• Organization modules aggregate normalized snapshots instead of duplicating repository parsers.
• Every view retains canonical source/evidence drill-down.
• Partial adoption and unavailable repositories remain honest and usable.
• Human-governed state such as architecture ratification and roadmap priority cannot be inferred by UI activity.
• GitHub remains the execution/review layer rather than being cloned into the dashboard.
• Shared UI primitives are reused instead of duplicated between repository and organization surfaces.
• A public organization portal can fail partially without losing all navigation.
• Private/local builds remain possible from authorized snapshots.
• The complete experience materially reduces the need to reconstruct organization state from chat history.

Related umbrella work

• egohygiene/hygiene#58 — continuous control loop
• egohygiene/relay#27 — Repository Intelligence
• Evolve Organization Intelligence into a modular fleet control plane #27 — Organization Intelligence

Non-goals

• Centralizing canonical source documents into a dashboard database.
• Replacing GitHub Issues/PRs.
• Building all pages in one PR.
• Waiting for 100% Hygiene adoption before shipping useful views.
• A universal organization score.
• Making dashboards mutation authority.

[szmyty]

Continuity/design checkpoint opened as PR #31: #31

It adds a versioned organization-roadmap mock reference and CONTINUITY.md so the visual-control-plane program can resume across chats without rebuilding context from conversation history.

Important boundary: the mock is presentation guidance only. Canonical roadmap, normalized evidence, and execution authority remain with their owning roadmap/Observatory/GitHub sources.

Also re-verified during this checkpoint: egohygiene/relay#78 has merged, so Repository Intelligence /dependencies/ is now part of the live foundation.