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 +83 -19
- package/bin/boxglow.js +2415 -653
- package/dist/assets/index-DlF7w2mD.js +3464 -0
- package/dist/assets/index-DrXehJJi.css +1 -0
- package/dist/index.html +5 -5
- package/docs/AGENTS_SNIPPET.md +40 -16
- package/examples/logic-daw/boxglow.json +58 -58
- package/examples/notes-app/boxglow.json +1681 -0
- package/package.json +4 -2
- package/dist/assets/index-BgLclRaq.css +0 -1
- package/dist/assets/index-BxV1l9_P.js +0 -3404
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
|
-
|
|
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" --
|
|
21
|
-
npx boxglow connect "Decide requirements.Requirements list" "Build it
|
|
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
|
|
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` |
|
|
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
|
-
| `
|
|
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
|
|
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`).
|
|
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 (
|
|
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
|
|
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.
|
|
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 → "
|
|
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
|
|
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
|
-
|
|
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:
|
|
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/ |
|