Workspace And Alma Layout Model

Purpose

The Alma layout model makes Prox OS feel like an AI-native Studio System instead of a browser workspace with a chat drawer. The sidecar is part of the workspace geometry.

Studio Workspace Model

Large screens use:

Workspace Shell + Alma

The window manager continues to own windows, spaces, focus, z-index, drag, resize, snap, and fullscreen spaces. Alma sits outside the normal window stack and reduces the available workspace area.

The host-side principle is:

Alma is outside the workspace but aware of it.

Current UI behavior:

• Default side is right.
• Display Options exposes Alma settings in a dedicated panel, separate from Shell layout and appearance settings.
• Rail width is local setting plus drag-resize handle.
• Closing the rail restores the full workspace.
• Collapsing the rail leaves a narrow sidecar affordance.
• Expanded rail width is capped at 90% of the viewport through host layout variables so the workspace never relies on hard-coded browser-width math.
• Alma Settings is a rail-local overlay. It is centered inside the Alma container instead of portaling to the global viewport.
• WindowLayer still measures the real workspace element, so windows use the remaining area instead of hiding beneath the rail.
• Alma must change the measured workspace size, not add an interior snap inset. Snapped, quartered, desktop-filled, and fullscreen windows still fill their target inside the remaining workspace exactly.
• Top and bottom RuntimeCommandStrip placements live inside the workspace column, not underneath the Alma.
• Cmd+K, shell dialogs, sign-in overlays, and app switcher overlays are workspace overlays and should not cover the Alma. Community is now a first-class workspace route rather than a workspace overlay.

Left And Right Rail Behavior

The sidecar belongs to the shell layout, not to app content.

Right side:

• Default placement.
• Resize handle sits on the left edge of the rail.
• Dragging left increases width, dragging right decreases width.

Left side:

• Available through Display Options.
• Resize handle sits on the right edge of the rail.
• Dragging right increases width, dragging left decreases width.

Both sides should preserve:

• RuntimeCommandStrip behavior.
• Desktop Runtime icon behavior.
• Window drag and resize constraints.
• Mission Control and Spaces mental model.

RuntimeCommandStrip Top And Bottom Boundary

Top and bottom RuntimeCommandStrip placements are workspace chrome. They should be constrained to the workspace column after Alma width has been removed. This prevents RuntimeCommandStrip controls from running below or above the Alma.

When Alma is collapsed or closed, the workspace column can expand and the RuntimeCommandStrip follows that available workspace width.

Workspace Overlay Boundary

Workspace overlays are scoped to the workspace overlay root:

• Cmd+K Global Command Surface.
• Shell dialogs and sign-in overlays.
• App switcher and workspace blur.
• Prox Switchbar backdrop and center placement.

Alma owns its own local menus, mode selector, permission chips, and settings dialog. The settings dialog should be positioned relative to the rail container and remain usable when the rail is narrow or expanded up to the 90% cap. Workspace overlays should not obscure Alma unless the user explicitly enters a future privacy or presentation mode.

Mobile Direction

Narrow screens should become AI-first:

Alma first + Remote OS control + workspace preview

The current shell adds a responsive fallback where Alma can cover the narrow workspace instead of crushing it. Future product work should add a dedicated mobile AI console with approval inbox, workspace previews, connector and permission review, and profile/data vault access.

Future Layout Objects

Workspace Generator should eventually produce:

• app list
• window layout
• artifact list
• workflow cards
• permissions
• automation suggestions
• restore policy

Those outputs should be explicit workspace objects, not hidden prompt text.

Non-goals In This Task

• No backend workspace generator.
• No provider adapter.
• No database persistence.
• No mobile native application.
• No API worker business route.