← Commit history

Scrub unreleased project name for public page; genericize native-browser surface

John Lauer ·a0dd014755 ·4mo ago ·parent d5d516e
2 files changed +20−22
README.md+2−3
@@ -43,7 +43,7 @@ The AI picks the surface by what it needs to test, and it can use more than one  | Surface | What it is | Use it for | |---|---|---|-| **Native browser** | The user's real Chrome or Edge, reached through the `adom-browser-extension` | The real, signed-in experience. The browser already holds the user's auth cookies, so the app opens **logged in or auto-logs-in with zero friction**. Huge for demoing and testing anything behind a login. |+| **Native browser** | The user's own Chrome or Edge, driven through Adom Desktop | The real, signed-in experience. The browser is already the user's, so the app opens **logged in with zero friction**. Huge for demoing and testing anything behind a login. | | **pup** | A clean, scriptable Chrome the AI fully owns, via `adom-desktop` | The **fresh, logged-out, first-time-user** experience, and automated screenshot loops that should not fight the user's own tabs. | | **Hydrogen webview** | An in-workspace browser tab | Showing a result inside the workbench, next to the code and the chat. | @@ -313,8 +313,7 @@ This system is split across focused skills. The AI loads them by trigger word. U | `adom-app-header` | The 44px three-zone header and the app-info popover | | `adom-app-model` | How an Adom app is structured, distributed, and versioned | | `adom-screenshot` | Ralph loops and the visual feedback loop for debugging UI |-| `pup-vs-webview` / `adom-desktop-pup` | Choosing and driving pup, webview, or the native browser |-| `adom-browser-extension` | Driving the user's real Chrome or Edge (auth-cookie, auto-login) |+| `pup-vs-webview` / `adom-desktop-pup` | Choosing and driving pup, webview, or the user's native browser | | `adom-cli-design` | The `OK:`/`ERROR:`/`Hint:` CLI contract, in Rust | | `ai-hints-in-clis` | Writing hints that actually steer the AI | | `relay-hint-pattern` | Teaching a relay server to redirect callers to the CLI |
SKILL.md+18−19
@@ -3,22 +3,22 @@ name: adom-ui-design user-invocable: true description: >-   The Adom UI Design System: how the AI builds AND tests interfaces people love to use in the Adom-  ecosystem. The AI writes the app, shows it to the user (in the native browser via the-  adom-browser-extension so it is already logged in with the user's auth cookie, in pup for the-  logged-out experience, or in a Hydrogen webview), drives the front-end over a live SSE/WebSocket-  channel to exercise every path (auto-click buttons, show/hide floaty toolbars, load a different-  symbol or footprint, click send-to-kicad), and ralph-loops with screenshots until the UI is-  perfect. Covers the user-first interaction rules (instant feedback, controls that explain-  themselves, toasts that double as the AI's live narration channel to the user, forgiving errors),-  responsive and touch (mobile layouts, tooltips without hover), the 44px app header, AI-drivability-  (state on the server, GET /state + /console, the live channel, CLI driving commands), the-  OK/ERROR/Hint Rust CLI contract, Babylon 3D viewers, hero rules, and the polish tokens (colors,-  fonts, icons) last. Read BEFORE building or testing any Adom UI. Trigger words: ui design, design-  system, build an app, build a ui, test the ui, ralph test, ralph loop, drive the front-end,-  ai-drivable, ai drivable app, live channel, sse, websocket, server-sent events, show app in-  native browser, show app in pup, webview vs pup, auto-click, auto click buttons, toast, ui toast,-  app header, 44px header, tooltip, mobile tooltip, responsive, mobile layout, on-brand, color-  tokens, theme tokens, cli design, hints, 3d viewer, hero image, ui linter, make my app a joy to use.+  ecosystem. The AI writes the app, shows it to the user (in the user's own already-signed-in native+  browser via Adom Desktop, in pup for the logged-out experience, or in a Hydrogen webview), drives+  the front-end over a live SSE/WebSocket channel to exercise every path (auto-click buttons,+  show/hide floaty toolbars, load a different symbol or footprint, click send-to-kicad), and+  ralph-loops with screenshots until the UI is perfect. Covers the user-first interaction rules+  (instant feedback, controls that explain themselves, toasts that double as the AI's live narration+  channel to the user, forgiving errors), responsive and touch (mobile layouts, tooltips without+  hover), the 44px app header, AI-drivability (state on the server, GET /state + /console, the live+  channel, CLI driving commands), the OK/ERROR/Hint Rust CLI contract, Babylon 3D viewers, hero+  rules, and the polish tokens (colors, fonts, icons) last. Read BEFORE building or testing any Adom+  UI. Trigger words: ui design, design system, build an app, build a ui, test the ui, ralph test,+  ralph loop, drive the front-end, ai-drivable, ai drivable app, live channel, sse, websocket,+  server-sent events, show app in native browser, show app in pup, webview vs pup, auto-click,+  auto click buttons, toast, ui toast, app header, 44px header, tooltip, mobile tooltip, responsive,+  mobile layout, on-brand, color tokens, theme tokens, cli design, hints, 3d viewer, hero image,+  ui linter, make my app a joy to use. ---  # Adom UI Design System@@ -66,7 +66,7 @@ The AI picks the surface by what it needs to test, and it can use more than one  | Surface | What it is | Use it for | |---|---|---|-| **Native browser** | The user's real Chrome or Edge, reached through the `adom-browser-extension` | The real, signed-in experience. The browser already holds the user's auth cookies, so the app opens **logged in or auto-logs-in with zero friction**. Huge for demoing and testing anything behind a login. |+| **Native browser** | The user's own Chrome or Edge, driven through Adom Desktop | The real, signed-in experience. The browser is already the user's, so the app opens **logged in with zero friction**. Huge for demoing and testing anything behind a login. | | **pup** | A clean, scriptable Chrome the AI fully owns, via `adom-desktop` | The **fresh, logged-out, first-time-user** experience, and automated screenshot loops that should not fight the user's own tabs. | | **Hydrogen webview** | An in-workspace browser tab | Showing a result inside the workbench, next to the code and the chat. | @@ -336,8 +336,7 @@ This system is split across focused skills. The AI loads them by trigger word. U | `adom-app-header` | The 44px three-zone header and the app-info popover | | `adom-app-model` | How an Adom app is structured, distributed, and versioned | | `adom-screenshot` | Ralph loops and the visual feedback loop for debugging UI |-| `pup-vs-webview` / `adom-desktop-pup` | Choosing and driving pup, webview, or the native browser |-| `adom-browser-extension` | Driving the user's real Chrome or Edge (auth-cookie, auto-login) |+| `pup-vs-webview` / `adom-desktop-pup` | Choosing and driving pup, webview, or the user's native browser | | `adom-cli-design` | The `OK:`/`ERROR:`/`Hint:` CLI contract, in Rust | | `ai-hints-in-clis` | Writing hints that actually steer the AI | | `relay-hint-pattern` | Teaching a relay server to redirect callers to the CLI |