# Jarvis Desktop — three UI design proposals

A self-contained, static design-review artifact. Three click-through UI proposals for the complete Jarvis
Desktop bundle, built from the 2026-07-26 screenshot capture of v2.10.0.

**This is review material, not production UI.** Nothing here is imported by the application, nothing talks to a
backend, and no file outside this folder was created or modified.

---

## Launch

The prototype is plain HTML, CSS and classic `<script>` tags — no build step, no modules, no dependencies. Any
static server works, and `file://` works too.

```bash
cd artifacts/ui-redesign-proposals
python3 -m http.server 8791 --bind 0.0.0.0
```

Then open **`http://<host>:8791/index.html`**.

Opening `index.html` directly from disk also works and has one advantage: the screenshot-mapping page can then
reach the read-only library beside the repo and shows the original captures as thumbnails. Over the standalone
server those thumbnails are hidden and the source path is shown instead.

## Review paths

| Page | What it is |
| --- | --- |
| `index.html` | Proposal chooser. Live previews of all three directions, the problems each one had to solve, and a ten-minute review script. |
| `prototype.html?d=<direction>` | The click-through prototype. `d` is `foundry`, `atelier` or `meridian`. |
| `prototype.html?d=<direction>&s=<screen>` | Deep link to any screen — the URL updates as you navigate, so it can be shared. |
| `specimen.html?d=<direction>` | Live design-system specimen: tokens, type scale, colour, space, geometry, elevation, the full icon set, controls, states, layout and motion rules. Every value is read back out of the running stylesheet. |
| `compare.html` | Side-by-side matrix across eleven dimensions, per-direction strengths and tradeoffs, the recommendation, a build order and the open risks. |
| `mapping.html` | All 109 captured screenshots mapped to their redesigned equivalent, with what changed per area. |

### The three directions

| | Direction | Thesis | Shell |
| --- | --- | --- | --- |
| 01 | **Foundry** | Instrument-grade calm. | Product rail + contextual panel |
| 02 | **Atelier** | A studio, not a console. | Workspace bar + one warm sidebar |
| 03 | **Meridian** | Everything running, visible at once. | Command bar + nav + persistent operations rail |

**Recommendation: Meridian**, grafting Foundry's mono-for-machine-strings rule and Atelier's empty states. The
reasoning is on `compare.html`.

### Fastest way to see the point

1. `prototype.html?d=meridian` — note the operations rail on the right.
2. Product switcher → **Design**, then → **Team**. The rail and the command bar do not move. That is the whole
   argument: the inner products no longer bring their own shells.
3. Same trip in `?d=foundry` and `?d=atelier` to see the two other answers.

### Keyboard

`⌘K` / `Ctrl-K` search · `⌘B` / `Ctrl-B` collapse navigation · `Esc` close any menu or dialog · `Tab` to check
focus rings.

### The review bar

Every prototype window carries a bar at the bottom. It is review chrome, not part of the design: it switches
direction, flips the current screen between **populated / empty / loading / error**, toggles light/dark, and
links to the specimen, the comparison and the overview. Add `&chrome=0` to the URL to hide it (that is how the
live previews on `index.html` are embedded).

### Responsive

Designed for desktop and compact desktop. Narrow the window past ~1380px to see the operations rail fold, and
past ~1180px to see navigation collapse to the icon rail.

---

## What is real and what is not

**Real:** navigation, the product switcher, the profile menu, every settings section, tabs, filters, search
fields, the assistant / model / permission / project selectors, toggles, dialogs, the state switcher, theme
switching, deep links, and the light and dark variants of all three design systems.

**Inert by design:** sending a message, deploying, generating, signing out, installing a harness, and every
destructive action. They answer with a toast that says so.

All content — names, model ids, paths, digests, status strings, empty-state copy — is taken from the capture.
Where the capture showed an empty product, the prototype carries both the empty state and a realistic populated
state, because a layout is only proven by its full case.

---

## Files

```
index.html          proposal chooser
prototype.html      click-through prototype (?d=, &s=, &chrome=0, &theme=)
specimen.html       design-system specimen (?d=)
compare.html        comparison matrix + recommendation
mapping.html        screenshot → redesign mapping
app/
  base.css          structure only: shell layouts + component anatomy, no values
  docs.css          neutral chrome for the review documents
  review.css        specimen page layout
  icons.js          one 24px stroke icon family (~90 glyphs)
  data.js           content model drawn from the capture
  screens.js        all 29 screens + dialog bodies
  shell.js          state, routing, shell chrome, overlays
  specimen.js       specimen renderer
themes/
  foundry.css       direction 01 design system (dark + light)
  atelier.css       direction 02 design system (light + dark)
  meridian.css      direction 03 design system (dark + light)
docs/
  smoke.mjs           click-through test: 3 directions × 29 screens × 2 widths
  verify-mapping.mjs  proves every screenshot is mapped exactly once
  contrast.mjs        measures WCAG contrast across all six theme variants
```

`base.css` never hard-codes a colour, font, radius or spacing value — it reads everything through the token
contract documented at the top of the file. That is what lets the three directions be genuinely different
systems over identical component anatomy, and it is the same split recommended for the real implementation.

## Tests

With the server running on `:8791`:

```bash
node docs/verify-mapping.mjs   # every captured screenshot mapped exactly once
node docs/contrast.mjs         # WCAG contrast across all six theme variants
node docs/smoke.mjs            # 174 screen renders + interaction paths
```

`smoke.mjs` checks, for every direction × screen × viewport: no console or page errors, no horizontal page
overflow, no text clipped by its own box, no control bound to an unknown action (i.e. no dead buttons), and that
the main region actually rendered. It then walks the principal interaction paths — product switcher, profile
menu, model selection, `⌘K` search, dialog submit, theme toggle, the four screen states and nav collapse — and
finally loads every review page and follows every internal link.

`contrast.mjs` measures the token pairs that carry meaning — body and secondary text, the accent as text, the
label on a primary button, all five semantic states, and the focus ring — in every direction × light/dark, and
fails if any of them falls below 4.5:1. The same numbers are computed live on each specimen page, so the
specimen cannot claim a ratio its theme does not deliver.

All three are read-only; they touch nothing outside this folder.