Split the framed cockpit page by workspace boundary

[flyingrobots]

Why

The Bijou 7 conversion correctly keeps one coherent FramePage because Explorer, Atlas, and Operations share vault authentication, manifest caches, service state, and operation history. That decision also leaves bin/ui/dashboard.js and bin/ui/dashboard-view.js as large multi-workspace modules whose unrelated reducers and renderers are easy to couple accidentally.

Outcome

Keep the single framed cockpit page and shared DashModel, but extract workspace-specific reducers, command providers, and renderers behind explicit pure boundaries.

Acceptance criteria

• Explorer, Atlas, and Operations each have a named module boundary.
• Shared authentication, source selection, cache, and operation-feed state remain owned once.
• The public createDashboardPage() contract and static fallback remain unchanged.
• Workspace key maps and commands remain inspectable without opening the monolithic reducer.
• Existing frame, search, notification, and domain regression tests stay green.
• No mutable cross-module singleton is introduced.

Evidence

The debt is visible in bin/ui/dashboard.js and bin/ui/dashboard-view.js after issue #106 removes the duplicate outer shell. This issue is follow-on maintainability work and is not a v6.5.6 release blocker.

[coderabbitai]

🔗 Related PRs

#24 - feat(ui): upgrade git-cas to a Bijou v3 repository explorer [closed]
#76 - feat: add scoped staging workspaces [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!