From 0e5480b1a5ffa7630e5ac1caaf5fbda2d6a0d3df Mon Sep 17 00:00:00 2001 From: Ian Gulliver Date: Wed, 21 Oct 2026 15:54:42 -0700 Subject: [PATCH] Allow a task Page view web view and add it to TODO --- TODO.md | 2 + docs/macos.md | 2 +- mockups/html-preview.html | 147 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 150 insertions(+), 1 deletion(-) create mode 100644 mockups/html-preview.html diff --git a/TODO.md b/TODO.md index ae63ce7..ae097d5 100644 --- a/TODO.md +++ b/TODO.md @@ -17,5 +17,7 @@ # M8 — macOS client +- Page view for HTML + Build once the attached sheet over the lead pane (mockup 3b, task "Left-side task context") has landed. A task view that shows an HTML page in a `WKWebView` inside that sheet, with the task's transcript staying on the right. It opens from an HTML attachment on a question, from clicking an `.html` file in Files, or from a preview link. It reloads in place when the agent changes the file, and has a "↗ Browser" button that opens the page at full width in the default browser. One-file pages load through the worktree file endpoint; a page's neighboring CSS and image files need serving too. Wireframe: `mockups/html-preview.html`, option 2. `docs/macos.md`, "Decision", allows this one web view. - Phone app A native client for the phone over the same API, sharing the macOS client's SwiftUI code where it can. Every surveyed tool has one (Claude, Codex, Cursor and Conductor apps, GitHub Mobile, Superset for iPhone); it needs its own layout, since two half-width panes don't fit a phone. diff --git a/docs/macos.md b/docs/macos.md index dbfadc4..bf616bf 100644 --- a/docs/macos.md +++ b/docs/macos.md @@ -4,7 +4,7 @@ Platform constraints, build requirements and SwiftUI behavior observed live. ## Decision -**No web view, under any circumstances**: no `WKWebView`, no `WebView`, no HTML rendering of any kind, in the window, in a dialog, for Markdown, for diagrams, for the terminal or for previews. A link to a web page opens in the default browser. Mermaid needs a browser DOM, and its automatic layout can't give the banded, nested look of a hand-drawn architecture picture, so byre has its own ```` ```diagram ```` block (rows, nested boxes, a side column, routed arrows, named highlights), laid out on a grid by the app; its syntax is the `diagrams` knowledge-base article. It is byre's only diagram format: a ```` ```mermaid ```` block shows as code, and the workflow stage graphs are drawn by generating its source. Agents see their diagrams through the `render_diagram` tool, which runs the installed app's own binary as `Byre render-diagram` (source on stdin, PNG on stdout), so the picture is exactly what the transcript draws; that mode opens no window and never touches the app's iCloud-synced store, so it uses the default text size. byre's Markdown dialect (choice markers, `
` sections, `#/task/` links, worktree image paths, `NO_REPLY`) matches no library, so the app parses it itself. +**One web view only**: a task's Page view, which shows an HTML file from the task's worktree or one of its exposed previews in a `WKWebView`, in the attached sheet over the lead pane. Nothing else renders HTML: no `WKWebView` or `WebView` in the window, a dialog, Markdown, diagrams or the terminal. Any other link to a web page opens in the default browser. Mermaid needs a browser DOM, and its automatic layout can't give the banded, nested look of a hand-drawn architecture picture, so byre has its own ```` ```diagram ```` block (rows, nested boxes, a side column, routed arrows, named highlights), laid out on a grid by the app; its syntax is the `diagrams` knowledge-base article. It is byre's only diagram format: a ```` ```mermaid ```` block shows as code, and the workflow stage graphs are drawn by generating its source. Agents see their diagrams through the `render_diagram` tool, which runs the installed app's own binary as `Byre render-diagram` (source on stdin, PNG on stdout), so the picture is exactly what the transcript draws; that mode opens no window and never touches the app's iCloud-synced store, so it uses the default text size. byre's Markdown dialect (choice markers, `
` sections, `#/task/` links, worktree image paths, `NO_REPLY`) matches no library, so the app parses it itself. The app joins the tailnet as its own node with libtailscale and reaches byre's HTTPS origin on byre's node, so byre knows who is calling from the node itself. It never sends identity headers, and certificate validation is never relaxed. diff --git a/mockups/html-preview.html b/mockups/html-preview.html new file mode 100644 index 0000000..191ee5a --- /dev/null +++ b/mockups/html-preview.html @@ -0,0 +1,147 @@ + + + + + +HTML Preview Options + + + +
+

Where should an agent's HTML page show?

+

Same case for both: the "Left-side task context" agent asks ian to pick between mockups 3a and 3b, which live in mockups/left-layer.html (a 25 KB page whose sections are drawn by JavaScript and follow light/dark mode). Then it adds two more wireframes to the file and asks again.

+ +

1. Browser, as today

+

The agent calls client_open. The browser comes forward on murky over byre's window. Each call copies the file into a new folder, so the second round opens a second tab; the first tab still shows the old page.

+
+
+
+
+
LeadNotesWorkflowsStatus
+
Lead: the Left-side task agent has a question for you.
+
+
+
TranscriptChangesFiles
+
+
Which middle ground, 3a or 3b? +
( ) 3a — sheet covers the lead, no tabs
+
(•) 3b — attached sheet with the task's tabs
+
The wireframes are open in your browser.
+
+
+
+
+
byre window — behind the browser until ian switches back
+
+
+
…/open/7f3a/left-layer.html…/open/c91e/left-layer.html
+
+

Attached Sheet Mockups

+
3a. Sheet covers the lead
+
+
3b. Attached sheet with tabs
+
+
Full width, real browser: JS, dark mode, ⌘F, zoom, print, dev tools.
+
+
+
+
    +
  • Gets: nothing new to build or maintain; every page works exactly as written (JS, fonts, dark mode); full browser width and tools; the "no web view" rule stays.
    • +
  • Gives up: the page and the question are in two windows; ian switches back and forth to compare 3a/3b against the options; stale tabs pile up after each revision; it takes the screen on murky every time.
    • +
+ +

2. Built-in page view in the left sheet

+

The question carries the page as an attachment (or ian clicks left-layer.html in Files, or a preview link). The page opens in the attached sheet over the lead pane, the way 3b opens Changes or Files, with the question still on the right. When the agent edits the file, the sheet reloads in place. Needs a WKWebView.

+
+
+
+
+
LeadNotesWorkflowsStatus
+
+
Left-side task context · left-layer.html↗ Browser   ✕
+
+

Attached Sheet Mockups

+
3a. Sheet covers the lead
+
+
3b. Attached sheet with tabs
+
+
Half the window wide. Reloads when the agent changes the file.
+
+
+
+
+
TranscriptChangesFilesPage
+
+
Which middle ground, 3a or 3b? +
( ) 3a — sheet covers the lead, no tabs
+
(•) 3b — attached sheet with the task's tabs
+
left-layer.html — showing on the left
+
+
+
+
+
One byre window. Nothing else comes forward.
+
+
+
    +
  • Gets: page and question side by side in one window; the page refreshes in place after each revision; nothing takes the screen; works the same on every Mac without copying files.
    • +
  • Gives up: reverses "no web view, under any circumstances" in docs/macos.md; a WebKit view inside the app that runs agent-written JavaScript; half the window wide, so a 1240px-wide mockup page is cramped (a ↗ Browser button stays for that); a one-file page like left-layer.html loads through the existing worktree file endpoint, but a page with its own CSS or image files next to it needs those served too; one more view kind to keep working.
    • +
+
+ +