Comparison & recommendation

Three defensible answers. One I would ship.

All three directions cover the same 29 screens, preserve every workflow visible in the 2026-07-26 capture, and solve the core problem — that Design and Team currently arrive with their own shells. They differ in what they optimise for, and that difference is structural, not cosmetic. Below: how they compare on the axes that matter for an industrial desktop, what each one costs, and which one I would build.

Side by side

Comparison matrix

Shaded cells mark where a direction is meaningfully ahead of the other two.

Dimension 01 · Foundry
Product rail + contextual panel
02 · Atelier
Workspace bar + warm sidebar
03 · Meridian
Command bar + nav + ops rail
Per direction

Strengths and tradeoffs

Recommendation

Ship Meridian. Take two things from the others.

Meridian, with Foundry's mono discipline and Atelier's empty states. The decisive argument is the persistent operations rail. This product's real failure mode is not that a screen is ugly — it is that a scheduled task silently skipped, a deployment went unhealthy, or an agent has been running on an issue for forty minutes, and none of it was visible because the operator was in Chat. Meridian is the only one of the three that makes that class of state ambient rather than something you have to remember to go and check. Everything else it does well — density, tabular figures, loud semantics on quiet neutrals — falls out of taking that problem seriously.

Why not Foundry

Foundry is the most beautiful of the three and its typographic discipline around identifiers is exactly right. But the rail-plus-panel shell spends 300px of horizontal space on navigation before any content appears, and it still answers "what is running?" with "go and look". It is the safest choice and the least ambitious one. If the team wants the smallest delta from today's build, this is that option — the current IA survives almost unchanged.

Why not Atelier

Atelier is the strongest on first impression and by far the best at making agents feel like colleagues rather than jobs — which matters for Jarvis Team specifically. The problem is density: at Atelier's spacing the Deployments table, the Issue Board and the Scheduled Tasks list all need scrolling where Meridian fits them on one screen, and a serif display face is a real localisation risk for the CJK locales the product already ships. It is the right direction for a marketing surface or a lighter product; it is a stretch for a control room.

Grafts

What to take from the runners-up

  • From Foundry — mono for machine strings. Every digest, snapshot, revision, deployment ref, file path and model id set in mono with tabular figures, and never truncated in the middle of a hash. This is a two-day change with a disproportionate effect on trust.
  • From Foundry — the section tick. A 3px accent mark on section titles gives the page a scannable spine without adding a single pixel of chrome.
  • From Atelier — empty states that teach. An icon, a sentence explaining what would fill the screen, and a primary action out of it. Meridian's empty states already use this pattern; it came from Atelier.
  • From Atelier — presence. Round agent avatars with a status ring, and authorship on every artifact. Cheap to add, and it is the difference between "a job ran" and "someone did this".
Sequencing

A build order that does not require a big-bang rewrite

  1. Tokens first. Land the token contract (colour, type, space, radius, control heights, elevation, motion) behind the existing components. Nothing moves; everything becomes changeable.
  2. Typography and semantics. Apply the type scale and the five-state semantic set. This alone fixes the hierarchy and contrast findings, and it is independent of any layout work.
  3. The shell. Introduce the command bar and unify the three navigation systems into one. This is the only step that requires Design and Team to give up their sidebars, so it is the one to schedule carefully.
  4. The operations rail. Ship it read-only first, fed by the state Scheduled Tasks, Issue Board and Deployments already hold. It needs no new backend contract.
  5. Density and tables. Convert the card grids that are really tables — deployments, schedules, issues, tasks — last, once the tokens make density a one-line change.

Risks to decide before building

  • Screen width. The operations rail costs 292px. Below about 1380px it must fold to a toggle — the prototype does this, but it needs a real decision about the minimum supported window.
  • Inner-product ownership. Jarvis Design (v0.11.0) and Jarvis Team (v0.5.0) version independently. Making them render into the host shell means agreeing a navigation contract, or the next release of either re-introduces its own sidebar.
  • Density and locale. Meridian's compressed scale needs verification against the German and Japanese strings before it ships; the current build's larger scale is hiding some overflow that density will expose.
  • Ambient state and noise. A rail that is always visible must never cry wolf. Only five state kinds should be allowed on it, and each needs a defined quiet condition.
Look again

The same screen in all three

Live previews of the Deployments screen — the screen where the differences are sharpest.