Skip to content

V0.9.0 web app - #11

Merged
grinev merged 9 commits into
mainfrom
v0.9.0-web-app
Aug 26, 2026
Merged

grinev merged 9 commits into
mainfrom
v0.9.0-web-app

Conversation

@grinev

@grinev grinev commented Aug 25, 2026

Copy link
Copy Markdown
Owner

No description provided.

grinev and others added 9 commits August 25, 2026 19:48
…o board

boardown-web with no argument now serves the registry of projects kept with the
OS's user configuration, instead of the board of the current directory. A server
started from a shortcut has no meaningful working directory, so the source of a
board is the machine's own list.

A default file that is not there is not an error: the server starts, the list
page shows no projects, and neither the folder nor the file is created. One that
exists and cannot be read refuses the start, as --registry always has. The list
page no longer promises the last version that loaded when none ever did.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The project list page in registry mode becomes editable. Each row carries a
Remove control beside its link, and an Add a project section below the list
takes an absolute path and an id, filling the id in from the folder's name as
the path is typed. Adding does not require a board: a folder with no .boardown/
is registered like any other, and its row reads "no board yet". Removing asks
first and drops that one entry; the project's own files are never touched.

Both edits go through POST /api/projects/{add,remove}, which patch the registry
file as text -- one line in or out, every comment and the order of the rest left
as they were -- and re-read it first, so an entry added by hand meanwhile
survives. Every patch is re-parsed and compared against what the edit intended
before it is written, so a file shape the patcher misreads becomes a refusal
rather than a corrupted registry, and the write itself goes through a temporary
file and a rename. A registry that cannot be parsed refuses both.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…e on disk

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Demo of the three web-app tasks on review. BD-115 and BD-117 passed their
scenarios and are done. BD-116 goes back with one requirement: the Add form
moves into a dialog that looks like the board's create-epic dialog, the page
keeps a single Add project button, and confirming a removal becomes a dialog
too. The path is still typed - a folder picker is not part of the round.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QZtsCoGRwvTjKH7kadDuFq
The inline Add a project section is replaced by a single Add project button
that opens a dialog holding the same two fields, and the browser's confirm()
window for a removal is replaced by a Remove project dialog naming the project.
Both are native <dialog> elements opened with showModal(), reproducing the shape
of the board's create-epic dialog -- a header with a close button, uppercase
field labels each over its own message slot, a right-aligned Cancel and a filled
confirming button -- while still following the reader's colour scheme rather
than the board's theme, which the page has never carried.

Nothing else on the page moves: the rows, the two endpoints, the refusal rules
and where each refusal is shown are exactly what they were. The id still fills
in from the folder name as the path is typed and stops once the id is edited by
hand; a refused Add keeps the dialog open with the reason under its field, and a
failed Remove still lands on the row it happened on.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@grinev
grinev merged commit 70ddbcf into main Aug 26, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant