boxglow 0.1.0 → 0.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -5,7 +5,7 @@
5
5
  **Plans and progress as boxes and wires. See at a glance what your AI agents and your team are working on.**
6
6
  Tasks are boxes with inputs and outputs; a box goes New (BlackBox: dark, output decided but nothing inside yet) → In Progress (GrayBox: hatched) → Done (WhiteBox: paper) as its output gets confirmed. Humans and AI agents (Claude Code, Codex, ...) edit the same `boxglow.json`; the UI shows who is working where, what is waiting for your decision, and what is left. The CLI alone is enough for an agent; the UI is for people.
7
7
 
8
- **計画と進捗を、箱と線で。AI エージェントとチームが今どこを作っていて、何が終わり、どこで判断を待っているかが一目でわかる。**
8
+ **計画と進捗を、ボックスと線で。AI エージェントとチームが今どこを作っていて、何が終わり、どこで判断を待っているかが一目でわかる。**
9
9
 
10
10
  - Web app: https://boxglow.pages.dev/ (no sign-in; data stays in your browser, or opens a local `boxglow.json`)
11
11
  - CLI for agents: `npx boxglow` (status / start / done / split / ask / answer ...)
@@ -15,11 +15,11 @@ Tasks are boxes with inputs and outputs; a box goes New (BlackBox: dark, output
15
15
 
16
16
  ```bash
17
17
  cd your-repo
18
- npx boxglow init --name "My project"
18
+ npx boxglow init --name "My project" --lang en
19
19
  npx boxglow add "Decide requirements" --out "Requirements list"
20
- npx boxglow add "Build it" --in "Requirements list" --out "Working app"
21
- npx boxglow connect "Decide requirements.Requirements list" "Build it.Requirements list"
22
- npx boxglow connect "Build it.Working app" "project.最終成果物"
20
+ npx boxglow add "Build it" --out "Working app"
21
+ npx boxglow connect "Decide requirements.Requirements list" "Build it" # the input is created with the output's name
22
+ npx boxglow connect "Build it.Working app" "project.Final deliverable"
23
23
  npx boxglow status
24
24
  npx boxglow start "Build it" --note "scaffolding"
25
25
  npx boxglow ask "Build it" "Which framework?" --options "React|Svelte" # a human (or the agent itself) answers later
@@ -29,20 +29,45 @@ npx boxglow done "Build it" --artifact "app=src/App.tsx" # de
29
29
 
30
30
  Recommended flow for a new project: the agent reads the brief (README, request) and creates 3-7 top-level boxes with concrete outputs, asks the human to confirm the split (`ask`), and only then decomposes the box it starts (`split`). Decisions keep the candidates that were not chosen; `reopen` lets you change course later without losing the history.
31
31
 
32
- Then run `npx boxglow setup-agent` once: it appends the working agreement ([docs/AGENTS_SNIPPET.md](docs/AGENTS_SNIPPET.md)) to your `AGENTS.md` / `CLAUDE.md`, installs a Claude Code skill (`.claude/skills/boxglow`), a SessionStart hook that runs `npx boxglow status`, and registers the MCP server in `.mcp.json` (`npx boxglow mcp`), so the agent reads the plan at the start of every session and can call `boxglow_status` / `boxglow_start` / `boxglow_done` / `boxglow_ask` ... as tools. Open `boxglow.json` in the web app (Chrome / Edge: "boxglow.json を開く"): the agent creates and decomposes boxes, records `start` / `done` / `ask` by itself, and the boxes change in front of you.
32
+ Then run `npx boxglow setup-agent` once. It installs agent instructions and skills and enables the context guard described below. Claude Code also receives a SessionStart hook and `.mcp.json`; Codex MCP registration is separate. Open `npx boxglow serve --open` or the VS Code custom editor to edit the same repository file as the agent.
33
+
34
+ ### Remember decisions across sessions
35
+
36
+ Boxglow keeps task instructions, decisions (including acknowledged answers), input/output contracts and handoff notes in the plan. `context` retrieves the task, its parents and upstream dependencies. `checkpoint` keeps findings, next steps and unresolved questions outside the bounded activity log.
37
+
38
+ ```bash
39
+ npx boxglow context B12
40
+ # Read the returned context. Copy contextToken from that response.
41
+ npx boxglow start B12 --context-token <token> --note "Implement the agreed design"
42
+ npx boxglow checkpoint B12 --context-token <token> --note "Verified inputs; next: implement retries; open question: timeout"
43
+ # In the next session (or after any instruction/answer/handoff change):
44
+ npx boxglow context B12
45
+ npx boxglow done B12 --context-token <new-token> --artifact "implementation=src/retry.ts"
46
+ ```
47
+
48
+ `setup-agent` enables this guard on the existing plan; `boxglow guard on` also enables it without installing agent settings. With the guard enabled, `start`, `done`, `set`, `split`, `artifact`, `ack`, `blocked`, `review`, `leave` and `checkpoint` by an agent need the current context token (`--context-token`); a missing or outdated token is rejected. People are never asked for a token (`--actor human`). After the agent's own change (`ask`, `artifact`, `checkpoint`, ...) the CLI prints the new token, so it can continue without reading again; after a person answers or edits an answer, changes the instructions, or another agent leaves a handoff, the agent has to read the context again. Read the changed context and reconcile it before retrying. A checkpoint changes the context, so reread afterward. The receipt excludes acknowledgement flags and activity timestamps; starting work does not invalidate it. Existing plans stay compatible until setup or explicit activation. `guard off` is an explicit configuration choice, not a recovery step for a rejected receipt.
49
+
50
+ MCP provides `boxglow_context`, `boxglow_checkpoint`, and `contextToken` on guarded dedicated tools; `boxglow_run` accepts the CLI arguments for the remaining commands. The task inspector's **Agent handoff** section can edit the note and copy its context. Revising a human answer clears the old acknowledgement. These mechanisms prevent losing recorded context and reject Boxglow work transitions based on stale instructions; they do not control an agent's actions outside Boxglow.
51
+
52
+ `boxglow resume` (`--json` for structured output; MCP: `boxglow_resume`) lists answers the agent has not acknowledged yet, saved handoff notes and next candidates in one place; in the UI the same overview is the **Resume** tab of the activity panel, and a task's detail shows questions that need an answer first. Reading the overview does not acknowledge answers: before working, still read `boxglow context <block>` and use its token. Earlier agent log entries alone no longer count as an acknowledgement, so older answers without an explicit acknowledgement may show up as unread again.
53
+
33
54
 
34
55
  | Command | What it does |
35
56
  |---|---|
36
- | `setup-agent` | One-time setup for AI agents: AGENTS.md / CLAUDE.md snippet, Claude Code skill, SessionStart hook, `.mcp.json` |
57
+ | `setup-agent [--agent codex\|claude-code\|all]` | Install only the selected agent’s instructions and skill (default: `all`). Claude Code also gets a SessionStart hook and `.mcp.json`. Existing unrelated settings are preserved; malformed settings stop setup. |
37
58
  | `mcp [--file path]` | MCP server over stdio: every command above as a tool (`boxglow_status`, `boxglow_add`, `boxglow_split`, `boxglow_start`, `boxglow_done`, `boxglow_ask`, `boxglow_answer`, ... and `boxglow_run` for the rest) |
38
59
  | `serve [--port 4174] [--open]` | Local server: the bundled web app at `http://localhost:4174/?serve=1` reading and writing your `boxglow.json` through a small API, with live reload when the CLI or an agent changes the file. Works in any browser (Firefox, Safari) |
39
- | `status` | Markdown summary: pending decisions, who is working where, tree with ids, next candidates |
60
+ | `context <block>` / `checkpoint <block> --note ... --context-token ...` | Read persistent context with a receipt / record a durable handoff |
61
+ | `guard on\|off` | Enable or disable context checks (setup-agent enables them) |
62
+ | `resume [--json]` | Handoff notes, answers not yet acknowledged and next actions in one overview (read-only) |
63
+ | `status [--brief]` | Markdown summary (`--brief` omits the full tree): pending decisions, who is working where, tree with ids, next candidates |
40
64
  | `start <block> --note` / `done <block> --artifact name=url` | Record work in progress / completion with deliverables |
41
65
  | `split <block> --spec '<json>'` | Decompose a box into child boxes with named inputs / outputs and connections |
42
66
  | `ask <block> "question" --options "A\|B"` / `answer <block> "A"` | Ask a human for a decision / answer it |
43
67
  | `project <name>` | Add another project box to the same file (the top level holds only the input node, the output node and project boxes) |
44
68
  | `export-block <block>` / `import-block <file> --parent <block>` | Reuse a box (with its sub-boxes, ports and wiring) across projects as a `*.boxglow-block.json` template |
45
69
  | `reopen <block> --note "why"` | Reopen an answered decision: the old answer goes to its history, the candidates stay |
70
+ | `tidy` | Re-save the file by the rules: connected inputs take their source's name, major boxes collapsed, overlaps resolved (fixes files written before these rules) |
46
71
  | `port <block|project> --in/--out/--rename` / `disconnect` / `move <block> --parent <block>` / `remove <block> [--force]` | Edit ports, remove a wire, move a box to another parent (wires are re-routed through the boxes in between), delete a box (and its children with `--force`) |
47
72
  | `set <block> --status/--progress/--category/--due/--issue <url>/--repo` | Status, progress, category, schedule, JIRA / Redmine / GitHub issue link, repository |
48
73
  | `export --out docs/ROADMAP.md` / `export --format json` | Write the whole plan as Markdown (or JSON) |
@@ -50,23 +75,54 @@ Then run `npx boxglow setup-agent` once: it appends the working agreement ([docs
50
75
  | `merge <base> <ours> <theirs>` / `git-setup` | Box-level 3-way merge for Git (see below) |
51
76
  | `blocked`, `review`, `leave`, `show`, `log`, `layout`, `validate`, `prompt`, `group*` | See `npx boxglow help` |
52
77
 
78
+ ### Codex setup
79
+
80
+ ```bash
81
+ npx boxglow setup-agent --agent codex
82
+ npx boxglow status --brief
83
+ ```
84
+
85
+ This installs `AGENTS.md` and `.agents/skills/boxglow/SKILL.md`; it does not create Claude Code settings. `--agent claude-code` installs only Claude Code files; omit `--agent` to install both. The CLI is sufficient for either agent. `status --brief` keeps decisions, unacknowledged answers, activity and next candidates while omitting the complete tree; `status --json` still returns the full project.
86
+
87
+ For Codex MCP tools, register the server separately with an absolute path to your plan (run this in the same environment as Codex):
88
+
89
+ ```bash
90
+ codex mcp add boxglow -- npx -y boxglow mcp --file /absolute/path/to/boxglow.json --actor codex
91
+ ```
92
+
93
+ Use `codex mcp list` to verify the registration. `.mcp.json` in a repository is the Claude Code setup; it is not the Codex MCP registration. MCP `boxglow_status` accepts `brief: true`, and validation failures are returned with `isError: true` so the agent can act on them.
94
+
95
+ See the official [Codex skills locations](https://learn.chatgpt.com/docs/build-skills) and [Codex MCP configuration](https://learn.chatgpt.com/docs/extend/mcp?surface=cli).
96
+
53
97
  ## Any browser: `npx boxglow serve`
54
98
 
55
- The web app opens a local `boxglow.json` directly only in Chrome / Edge (File System Access API). `npx boxglow serve` runs a small local server (127.0.0.1 only) that serves the bundled app and exposes the file as `GET/PUT /api/project` plus an SSE `/api/events` stream, so the page updates a moment after the CLI or an agent writes the file, and edits in the page are written back. Open `http://localhost:4174/?serve=1` (`--open` opens it for you).
99
+ The web app opens a local `boxglow.json` directly only in Chrome / Edge (File System Access API), and those browsers refuse some locations: a file inside WSL (`\\wsl.localhost\...`) is rejected with a "contains system files" message. Use `serve` (or the VS Code extension) for those. `npx boxglow serve` runs a small local server (127.0.0.1 only) that serves the bundled app and exposes the file as `GET/PUT /api/project` plus an SSE `/api/events` stream, so the page updates a moment after the CLI or an agent writes the file, and edits in the page are written back. Open `http://localhost:4174/?serve=1` (`--open` opens it for you).
100
+
101
+ ### Save conflicts and recovery
102
+
103
+ CLI, local server and VS Code writers share a file lock (a `<file>.boxglow-lock` folder that records its owner). Writers wait a few seconds for each other, a lock left behind by a crashed process is recovered automatically, and concurrent CLI commands reload and retry. CLI/server saves compare the read revision and replace the file atomically; a stale writer must reread instead of replacing newer changes. The local API requires `If-Match` from the GET response's ETag, same-origin requests, an allowed loopback Host, JSON content type, valid schema/references and a body of at most 5 MiB.
104
+
105
+ The GUI retains unsaved edits when a save fails or another writer changes the file. Its persistent notice offers retry, JSON export and an explicit three-way merge. Changes to different fields are both kept; for a field changed on both sides, **Compare and choose** shows the two values side by side and you pick one (the choice and both values are recorded in the activity log). Export unsaved JSON for a separate backup. VS Code shows Saved only after `applyEdit`, `document.save()` and disk-content confirmation succeed. A 10-second acknowledgement timeout remains Unsaved and permits retry.
106
+
107
+ Direct File System Access opening is **read-only**, with live updates. Use `serve` or VS Code for shared editing; browser file handles cannot participate in the Node writer lock. Import JSON still creates a separate browser copy. All editors writing a shared file must use compatible Boxglow versions; unrelated programs and older versions do not honor the cooperative lock. **Versions and connection** at the bottom right of the UI shows the versions of the GUI, the connected CLI server and the VS Code extension; for the CLI alone use `boxglow --version` (`boxglow version --json` for details). If a process crashes leaving `<plan>.boxglow-lock`, first stop the associated Boxglow writers and verify no save is running, then remove that empty lock directory and retry. Never remove an active writer's lock.
56
108
 
57
109
  ## MCP server
58
110
 
59
111
  `npx boxglow mcp` is a stdio MCP server exposing the CLI as tools (`boxglow_status`, `boxglow_show`, `boxglow_add`, `boxglow_split`, `boxglow_connect`, `boxglow_start`, `boxglow_done`, `boxglow_blocked`, `boxglow_ask`, `boxglow_answer`, `boxglow_set`, `boxglow_export`, `boxglow_validate`, `boxglow_run`, ...). `setup-agent` writes the registration into `.mcp.json`:
60
112
 
61
113
  ```json
62
- { "mcpServers": { "boxglow": { "command": "npx", "args": ["boxglow", "mcp"] } } }
114
+ { "mcpServers": { "boxglow": { "command": "npx", "args": ["-y", "boxglow", "mcp"] } } }
63
115
  ```
64
116
 
65
117
  The server finds `boxglow.json` like the CLI does (current directory upwards, or `--file` / `BOXGLOW_FILE`). The CLI and the MCP tools write the same file, so either can be used.
66
118
 
119
+ ## VS Code extension
120
+
121
+ `vscode/` holds a VS Code extension that opens `boxglow.json` as the same diagram inside the editor (custom editor "Boxglow"; right-click the file or use the editor title button / command *Boxglow: Open boxglow.json as a diagram*). The diagram follows the file when the CLI or an agent writes it, edits in the diagram are written back, and light / dark follow the VS Code theme. Build it with `npm run build:vscode` (bundles the web app into `vscode/media/`) and package with `cd vscode && npm run package` (`.vsix`, install via *Extensions: Install from VSIX...*).
122
+
67
123
  ## Several repositories, one plan
68
124
 
69
- A `boxglow.json` can hold several project boxes (the top level only has Inputs, Outputs and project boxes). Add one with `+ Project` in the top bar or `npx boxglow project "Name" --repo ../path`, and set each box's Repository in the inspector. For a multi-repo workspace, keep the file in the parent folder and point every repository's agent at it:
125
+ A `boxglow.json` can hold several project boxes (the top level only has Inputs, Outputs and project boxes). Add one with `New Project` in the ⋯ menu of the top bar or `npx boxglow project "Name" --repo ../path`, and set each box's Repository in the inspector. For a multi-repo workspace, keep the file in the parent folder and point every repository's agent at it:
70
126
 
71
127
  ```
72
128
  workspace/
@@ -91,7 +147,7 @@ After that, `git merge` / `pull` / `rebase` combine both sides automatically. If
91
147
 
92
148
  ## Deliverables stay in Git (nothing is uploaded)
93
149
 
94
- Boxglow never uploads your files. A deliverable is a **reference**: a URL, or for files in a Git repository, `commit + path + blob hash` recorded by the CLI (`boxglow done ... --artifact path`, `boxglow artifact <block> path`). Because the reference is pinned to a commit it can always be retrieved with `git show <commit>:<path>`, and `boxglow check` follows renames (same blob in HEAD, or `git log --follow`) to update the current path; files that cannot be found are flagged. If the remote is GitHub / GitLab style, a commit-pinned web link is generated too. Only `boxglow.json` (plan, status, references) is shared, which keeps the tool usable where source and documents must not leave the company.
150
+ Boxglow never uploads your files. A deliverable is a **reference**: a URL, or for files in a Git repository, `commit + path + blob hash` recorded by the CLI (`boxglow done ... --artifact path`, `boxglow artifact <block> path`). Only files whose content matches HEAD receive a pinned Git reference. Modified, untracked or not-yet-committed files remain local file references, so they do not link to an older or nonexistent version. A pinned reference can be retrieved with `git show <commit>:<path>`, and `boxglow check` follows renames (same blob in HEAD, or `git log --follow`) to update the current path; files that cannot be found are flagged. If the remote is GitHub / GitLab style, a commit-pinned web link is generated too. Only `boxglow.json` (plan, status, references) is shared, which keeps the tool usable where source and documents must not leave the company.
95
151
 
96
152
  ## Concepts
97
153
 
@@ -101,7 +157,7 @@ Boxglow never uploads your files. A deliverable is a **reference**: a URL, or fo
101
157
  | In Progress (GrayBox) | Being decomposed or worked on | Hatched fill, ◐ icon, progress bar |
102
158
  | Done (WhiteBox) | Output confirmed with a deliverable | Paper fill, ● with a check |
103
159
 
104
- Expanded boxes (containers) are drawn as frames: the shallower the level, the thicker the border, and the fill alternates per level so nesting is visible. Wires are thin and use colors never used for borders (teal = the source already has a deliverable, light gray = not yet). Selecting a wire highlights the whole signal in orange, through parent ports, from the original output to the final input.
160
+ Expanded boxes (containers) are drawn as frames: the shallower the level, the thicker the border, and the fill alternates per level so nesting is visible. Wires are thin and use colors never used for borders (thick green = the source already has a deliverable, thin amber = not yet). Selecting a wire highlights the whole signal in orange, through parent ports, from the original output to the final input.
105
161
 
106
162
  - Every box has at least one output. Inputs can be added later.
107
163
  - The top level holds only the project's input node, its output node and one or more **project boxes**; tasks live inside a project box.
@@ -109,7 +165,7 @@ Expanded boxes (containers) are drawn as frames: the shallower the level, the th
109
165
  - **Reuse**: save any box as a template (structure, ports, descriptions, wiring; not status or artifacts) and insert it into another project, from the in-app library or as a `*.boxglow-block.json` file in your repo. Inserted boxes remember their template name and version.
110
166
  - An input with no source is automatically promoted to the project's input (dashed line) until someone connects it.
111
167
  - Activity badges: CC (Claude Code) / CX (Codex) / human, states working / blocked / needs decision / waiting review. Decisions are answered in the UI and read back by the agent.
112
- - Ready inputs: a wire whose source already has a deliverable (or is done) is drawn thick and teal, and the input name gets a dot, so you can see at a glance which inputs are available.
168
+ - Ready inputs: a wire whose source already has a deliverable (or is done) is drawn thick and green, and the input name gets a dot, so you can see at a glance which inputs are available.
113
169
  - Me / unassigned: pick yourself in the drawer; your boxes get a teal stripe. Owners are not printed on boxes (open the box to see them); filter by owner or "unassigned" in the drawer.
114
170
  - Decisions: `ask` records a question with candidates; the answer is kept together with the candidates that were not chosen, and `reopen` moves an answer to the history so you can change course later.
115
171
  - Issue link: a box can carry a JIRA / Redmine / GitHub issue URL (`--issue`, or the More tab); the key (PROJ-123, #45) is shown on the box and opens the issue.
@@ -122,18 +178,22 @@ Expanded boxes (containers) are drawn as frames: the shallower the level, the th
122
178
  - Progress: set a percentage per box (slider in the inspector or `boxglow set <block> --progress 60`); parents average their children, WhiteBox counts as 100.
123
179
  - Required inputs: every input is required by default; mark one as optional (任意) in the I/O tab if the box can start without it. A New box whose required inputs are all ready shows a `Ready` chip, and `boxglow status` lists such boxes first under next candidates.
124
180
  - Category: tag a box with what kind of work it is (study, research, design, ui, build, verify, evaluate, improve, fix, docs, ops, other). It shows as a colored stripe and a short label on the box, and the drawer's Filter can narrow by it. `boxglow add "..." --category design` / `boxglow set <block> --category verify|none`.
125
- - Saving: the top bar always shows Saved / Unsaved / Saving and a Save button. Opening a local file asks for read access only; write access is requested on the first edit.
181
+ - Saving: the top bar always shows Saved / Unsaved / Saving and a Save button. A local file opened directly in the browser is a read-only live view; edit it through `npx boxglow serve` or the VS Code extension.
126
182
  - `boxglow validate` reports broken wiring as errors and "holes in the plan" (unconnected ports, Done boxes without deliverables) as warnings; `done` without `--artifact` warns.
127
183
 
184
+ When a person answers a question an agent asked (`ask`), the answer stays listed as "Answered" (and editable) until an agent picks it up with `npx boxglow ack <block>` or by recording work on that box (`start`, `done`, `set`, ...). `status` lists such answers under "回答あり" so an agent never misses them.
185
+
128
186
  ## Example plan
129
187
 
130
- [examples/logic-daw/boxglow.json](examples/logic-daw/boxglow.json) is a mid-size plan for a browser DAW that borrows ideas from hardware logic design: a reference clock, dividers, counters and gates decide when sounds trigger. Open it in the web app (Home → "boxglow.json を開く") or run `BOXGLOW_FILE=examples/logic-daw/boxglow.json npx boxglow status` to see decisions, who is working where, and the next candidates.
188
+ [examples/logic-daw/boxglow.json](examples/logic-daw/boxglow.json) is a mid-size plan for a browser DAW that borrows ideas from hardware logic design: a reference clock, dividers, counters and gates decide when sounds trigger. Open it in the web app (Home → "Start with your own plan" → "View a file", read-only) or run `BOXGLOW_FILE=examples/logic-daw/boxglow.json npx boxglow status` to see decisions, who is working where, and the next candidates.
131
189
 
132
190
  Boxglow's own development is managed with Boxglow too (that plan stays local); what we learned by using it with Claude Code is in [docs/dogfooding.md](docs/dogfooding.md), and the working agreement for agents is in [CLAUDE.md](CLAUDE.md).
133
191
 
192
+ An English example lives in `examples/notes-app/boxglow.json` (a small notes app: 4 major boxes, 16 tasks, one in progress and one waiting for a decision). Open it from the web app's Home, or with the VS Code extension.
193
+
134
194
  ## Free and paid
135
195
 
136
- Boxglow is open core: everything that works with the one file on your machine (web app, CLI, Git workflow, members, parts, categories, dates, the planned VS Code extension) is MIT and stays free. Cloud sync, share links, team workspaces, Slack / JIRA connectors, a hosted MCP endpoint and a self-hosted edition are the paid product in preparation. The exact line is written down in [docs/MONETIZATION.md](docs/MONETIZATION.md); features already released under MIT will not move behind a paywall, and the paid product never stores your source or documents. To hear when it opens: https://boxglow.pages.dev/waitlist/
196
+ Boxglow is open core: everything that works with the one file on your machine (web app, CLI, Git workflow, members, parts, categories, dates, the VS Code extension) is MIT and stays free. Cloud sync, share links, team workspaces, Slack / JIRA connectors, a hosted MCP endpoint and a self-hosted edition are the paid product in preparation. The exact line is written down in [docs/MONETIZATION.md](docs/MONETIZATION.md); features already released under MIT will not move behind a paywall, and the paid product never stores your source or documents. To hear when it opens: https://boxglow.pages.dev/waitlist/
137
197
 
138
198
  ## Development
139
199
 
@@ -147,10 +207,14 @@ node bin/boxglow.js help
147
207
 
148
208
  Schema: `schemaVersion` 5. Older files (1-4) load and are upgraded on the first edit.
149
209
 
150
- URL parameters: `?demo=1` (sample), `&readonly=1`, `&embed=1`, `&theme=dark|light`, `?view=article` (= demo + embed + readonly), `#p=<id>`.
210
+ The CLI speaks the plan's language: `npx boxglow init --lang en` (or `ja`; the default follows your environment) stores it in `boxglow.json`, and messages, log lines, `status` and the agent instructions written by `setup-agent` follow it. Change it with `npx boxglow lang en`.
211
+
212
+ URL parameters: `?demo=1` (sample), `&readonly=1`, `&embed=1`, `&theme=dark|light`, `&lang=en|ja` (UI language; otherwise the browser language, remembered once switched from the ⋯ menu), `?view=article` (= demo + embed + readonly), `#p=<id>`.
151
213
 
152
214
  The web app is hosted on Cloudflare Pages (`npm run deploy:pages` builds with `VITE_BASE=/` into `dist-pages/` and uploads it). Any static host works: `vite build` with `VITE_BASE` set to the path you serve from (the default `/apps/boxglow/` is the author's blog mirror).
153
215
 
216
+ Browser checks live in `e2e/` (`npm run e2e`): wires never crossing boxes on every tab of the example plans (also with squeezed positions), tab switching time, double-click / selection / decision flows, the English UI and the VS Code webview mode. They need Playwright from outside this repository (`PLAYWRIGHT=<path>`; see `e2e/run.sh`) and are not part of CI; the unit and property tests (`npm test`) are.
217
+
154
218
  ## Layout
155
219
 
156
220
  | Path | Role |
@@ -165,5 +229,5 @@ The web app is hosted on Cloudflare Pages (`npm run deploy:pages` builds with `V
165
229
  | `cli/main.ts` | CLI (`bin/boxglow.js`) |
166
230
  | `src/canvas/` | React Flow canvas, block / terminal nodes, layout |
167
231
  | `src/panels/` | Top bar, drawer (tree / filter / members), inspector (block / edge / terminal / project / timeline), home |
168
- | `src/lib/localfile.ts` | Local file mode (File System Access API: watch + write back) |
232
+ | `src/lib/localfile.ts` | Local file mode (File System Access API: read-only live view) |
169
233
  | `docs/` | Plans, the agent instruction snippet, ROADMAP.md (exported plan), dogfooding.md (findings), logo/ |