Release 0.9.0 new flow

.boardown/config.yaml

@@ -1,8 +1,14 @@
 idPrefix: BD
-nextId: 121
+nextId: 122
 projectName: Boardown
 theme: dark
 multipleActiveReleases: true
+statuses:
+  - key: todo
+  - key: ready
+  - key: in-progress
+  - key: review
+  - key: done
 customFields:
   - key: spec
     label: Spec

.boardown/releases/v0.9.0.md

@@ -8,12 +8,89 @@ name: v0.9.0
 ---
 id: BD-36
 type: feature
-status: todo
+status: done
 epic: git-integration
-order: 500
+order: 2200
+checklist:
+  - id: c1
+    text: 1. spec read, code explored, open calls settled
+    done: true
+  - id: c2
+    text: 2. tech plan written
+    done: true
+  - id: c3
+    text: 3. architecture review closed
+    done: true
+  - id: c4
+    text: 4. implemented, gates green
+    done: true
+  - id: c5
+    text: 5. code review closed
+    done: true
+  - id: c6
+    text: 5r. review findings fixed
+    done: true
+  - id: c7
+    text: 6. manual test passed
+    done: true
+  - id: c8
+    text: 6r. test findings fixed
+    done: true
+  - id: c9
+    text: 7. committed
+    done: true
+  - id: c10
+    text: r2. round scoped, remarks triaged
+    done: true
+  - id: c11
+    text: r2. implemented, gates green
+    done: true
+  - id: c12
+    text: r2. code review closed
+    done: true
+  - id: c13
+    text: r2. affected scenarios retested
+    done: true
+  - id: c14
+    text: r2. committed
+    done: true
+  - id: c15
+    text: r3. round scoped, remarks triaged
+    done: true
+  - id: c16
+    text: r3. implemented, gates green
+    done: true
+  - id: c17
+    text: r3. code review closed
+    done: true
+  - id: c18
+    text: r3. affected scenarios retested
+    done: true
+  - id: c19
+    text: r3. committed
+    done: true
+notes:
+  - id: n1
+    text: "In the task dialog's Commits panel the short hash and the commit subject sit on separate lines. It should become: the hash and the subject sit side by side on one line, and a subject too long for the width wraps inside its own column - every wrapped line aligned to the subject's left edge, never running under the hash. Nothing else in the panel changes."
+    createdAt: "2026-09-01T22:01:04.110Z"
+  - id: n2
+    text: "Run 2: the remark from n1 is worked, in the commit that carries this note. The Commits panel's row is now one line - monospaced hash, then the subject beside it, wrapping inside its own column so no wrapped line runs under the hash. Nothing else in the panel changed. Retested in the browser: the row layout, a 150-character unbroken subject, and the whole of run 1's demo walkthrough all pass."
+    createdAt: "2026-09-01T22:44:26.588Z"
+  - id: n3
+    text: "In the task dialog's Commits panel a row no longer shows the commit's short hash. Instead each row shows the commit's subject first and the commit's date and time after it, both on one line, the date and time formatted as DD.MM.YYYY HH:MM. A subject too long for the width still wraps inside its own column - every wrapped line aligned to the subject's left edge - and the date and time stay out of that column, staying with the row's first line. Nothing else in the panel changes: same commits, same order, no buttons or links."
+    createdAt: "2026-09-02T09:11:49.664Z"
+  - id: n4
+    text: "Run 3: the remark from n3 is worked, in the commit that carries this note. A Commits row now reads subject first and the commit's date and time after it, DD.MM.YYYY HH:MM in your own time zone, at the row's end; the short hash is gone from the panel. A long subject still wraps inside its own column and the date stays on the row's first line. Nothing else in the panel changed. The CLI's task commits deliberately keeps its published { hash, subject } and never carries the date. Retested in the browser and from the CLI: the row layout, the date against git's own, a 150-character unbroken subject, and run 1's whole walkthrough all pass."
+    createdAt: "2026-09-02T09:41:58.776Z"
 links:
   - type: relates
     to: BD-51
+  - type: relates
+    to: BD-88
+spec: "[[repo:.claude/specs/BD-36-show-related-commits-in-task/product.md]]"
+plan: "[[repo:.claude/specs/BD-36-show-related-commits-in-task/tech.md]]"
+log: "[[repo:.claude/specs/BD-36-show-related-commits-in-task/log.md]]"
+session: 7ff0b16b-1eda-408e-b88e-2d788de50976
 ---
 
 ## Operation notifications
@@ -49,9 +126,44 @@ order: 800
 ---
 id: BD-88
 type: feature
-status: todo
+status: done
 epic: git-integration
-order: 700
+order: 2100
+checklist:
+  - id: c1
+    text: 1. spec read, code explored, open calls settled
+    done: true
+  - id: c2
+    text: 2. tech plan written
+    done: true
+  - id: c3
+    text: 3. architecture review closed
+    done: true
+  - id: c4
+    text: 4. implemented, gates green
+    done: true
+  - id: c5
+    text: 5. code review closed
+    done: true
+  - id: c6
+    text: 5r. review findings fixed
+    done: true
+  - id: c7
+    text: 6. manual test passed
+    done: true
+  - id: c8
+    text: 6r. test findings fixed
+    done: true
+  - id: c9
+    text: 7. committed
+    done: true
+links:
+  - type: relates
+    to: BD-36
+spec: "[[repo:.claude/specs/BD-88-copy-commit-message/product.md]]"
+plan: "[[repo:.claude/specs/BD-88-copy-commit-message/tech.md]]"
+log: "[[repo:.claude/specs/BD-88-copy-commit-message/log.md]]"
+session: ab5bd227-ec1a-42f9-b112-1824e1970c6c
 ---
 
 ## Run boardown-web as a local server
@@ -360,3 +472,44 @@ log: "[[repo:.claude/specs/BD-120-unreadable-frontmatter-guard/log.md]]"
 ---
 
 PR #12 fixed this only for the CLI (packages/cli/src/persistence.ts): a task block whose frontmatter does not parse never enters container.tasks, so writing the container back silently drops the block. The same bug is still live in packages/ui/src/store.ts, i.e. in the VS Code, Electron and web shells: problems sit in the store and no write path consults them. Contradicts PRODUCT.md (Lenient parsing: the app never rewrites a file it could not fully parse) and CLAUDE.md. Decide where the guard belongs - most likely createGuardedFs / core, so the CLI stops carrying its own copy - and what the UI shows instead of writing. To be specced out later.
+
+## Make external links clickable
+
+---
+id: BD-121
+type: feature
+status: done
+order: 2000
+checklist:
+  - id: c1
+    text: 1. spec read, code explored, open calls settled
+    done: true
+  - id: c2
+    text: 2. tech plan written
+    done: true
+  - id: c3
+    text: 3. architecture review closed
+    done: true
+  - id: c4
+    text: 4. implemented, gates green
+    done: true
+  - id: c5
+    text: 5. code review closed
+    done: true
+  - id: c6
+    text: 5r. review findings fixed
+    done: true
+  - id: c7
+    text: 6. manual test passed
+    done: true
+  - id: c8
+    text: 6r. test findings fixed
+    done: true
+  - id: c9
+    text: 7. committed
+    done: true
+spec: "[[repo:.claude/specs/BD-121-external-links/product.md]]"
+plan: "[[repo:.claude/specs/BD-121-external-links/tech.md]]"
+log: "[[repo:.claude/specs/BD-121-external-links/log.md]]"
+session: d483953f-608f-4521-90b6-5074de89d458
+---

.claude/agents/manual-tester.md

@@ -191,27 +191,29 @@ expensive, and the snapshot already tells you what changed structurally.
 ## The demo scenario — write it whenever the feature is walkable
 
 A **demo scenario** is the route someone walks in front of the user when this
-feature is shown to him. You write it because you are the only one who has just
-walked the feature by hand and knows where everything actually is.
+feature is shown. You write it because you are the only one who has just walked the
+feature by hand and knows where everything actually is. **Unless your verdict is
+`broken`, write it before you report** — a feature with findings is still one that
+can be shown, and nobody has to ask you for it.
 
-**Unless your verdict is `broken`, write it before you report** — a feature with
-minor or major findings is still a feature that can be shown, and a broken one has
-nothing to show. Nobody has to ask you for it.
-
-**It goes into a file, not into your answer**: `demo.md`, next to the `product.md`
-you were given — same folder, and nobody has to hand you the path. Your report
-then carries one line: the path and how many steps it has. A scenario that travels
+It goes into `demo.md`, next to the `product.md` you were given; your report then
+carries one line, the path and how many steps it has. A scenario that travels
 through someone else's context arrives edited.
 
-**Every retest round, rewrite it if the fixes changed anything it describes** —
-same path, replacing what is there. There is only ever one file, so it is always
-the state you last saw; nobody downstream has to work out which version is current.
-A round that changed nothing visible leaves it alone.
+**Every retest round, rewrite what the fixes changed** — the same file, so it is
+always the state you last saw. A round that changed nothing visible leaves it alone.
+
+**A rework round adds its own section at the end**, while the scenario above it is
+brought up to date as usual: the user has already watched this feature and sent it
+back over one finding, and what he needs to see is that finding closed, not the
+whole walk again.
 
-**A rework round adds a section for that round**, at the end of the file, while
-the scenario above it is brought up to date as usual. The user has already watched
-this feature and sent it back over one finding; what he needs to see now is that
-finding closed, not the whole walk again:
+**A round is one the user sent back**, and you know it because the prompt hands you
+the remark he made at the demo. Findings of your own, fixed and retested inside this
+same run, are not rounds — they never reached him. They go into the scenario above
+and leave no section behind; a `## Rework` section written for them makes the demo
+announce a round that never happened, and he spends the show working out what he is
+supposed to have sent back.
 
 ```
 ## Rework 1 — <the finding, in a few words>
@@ -222,25 +224,14 @@ Now: <what is observably different>
 2. … (two or three steps)
 ```
 
-Number it by counting the `## Rework` sections already in the file: the first
-round writes `Rework 1`, the next `Rework 2`. Rounds are kept, not replaced —
-which one gets shown is decided in front of the user, and the older ones say what
-this feature has already been through.
-
-Its steps are **its own, not references into the scenario above** — the sandbox is
-reset to the fixture before the task is shown, so "see step 4" with no route to
-step 4 cannot be walked. Whatever preparation those steps need is in them.
-
-A first run has no such section at all.
+Number it by counting the `## Rework` sections already there; rounds are kept, not
+replaced, and the older ones say what this feature has been through. Its steps stand
+on their own — the sandbox is reset to the fixture before the show, so "see step 4"
+cannot be walked. A first run has no such section.
 
-This is **the only file you create in the whole run**, and creating it does not
-loosen anything else: source, tests, the fixture, the board and every existing
-file in the repo stay untouched. Read-only meant "you change nothing that is
-already there", and that still holds.
-
-It is prose, not code — whoever shows it is a person driving a browser, and a
-wrong selector costs him a glance, not a debugging session. Name **what becomes
-visible**, not which element to click.
+This is **the only file you create in the whole run**; everything already in the
+repo stays untouched. It is prose, not code — whoever shows it is a person driving a
+browser, so name **what becomes visible**, not which element to click.
 
 ```
 ## What is new
@@ -260,26 +251,20 @@ visible**, not which element to click.
  anything removed by the task — there is nothing there to look at.>
 ```
 
-Keep it to fifteen or twenty-five lines. It is not a test plan and not a summary
-of your run: everything you checked that a person would not need to watch stays
-out. Where the feature is about size or layout, say the size that makes it
-visible — "six lines, not two" — because the wrong data makes the demo show
-nothing while looking like it worked.
-
-Three things make a scenario walkable, and all three come from watching one being
-walked:
-
-- **A step is one action.** The person showing this drives the browser through a
-  tool, where "delete the three lines you just typed" is sixty keystrokes, not one
-  gesture. Anything that is one movement for a hand and many for a tool gets
-  rewritten — "select all and retype" — or left out.
-- **Preparation is a command, not a click-through.** Data the show needs comes
-  from a CLI line against the sandbox board; walking the create dialog to make it
-  costs four steps before anything is shown. Prepare through the interface only
-  when the preparing is itself worth watching.
-- **Name menu items and popovers by their text.** They render in portals, outside
-  the structure of the page, so "Create → Task" can be found and "the menu under
-  the Create button" cannot.
+Keep it to fifteen or twenty-five lines — not a test plan and not a summary of your
+run. Where the feature is about size or layout, say the data that makes it visible
+("six lines, not two"): the wrong data makes the demo show nothing while looking
+like it worked.
+
+Three things make it walkable, and all three come from the show being driven through
+a tool rather than by hand:
+
+- **a step is one action** — "delete the three lines you just typed" is sixty
+  keystrokes there; rewrite it ("select all and retype") or leave it out;
+- **preparation is a CLI line against the sandbox board**, not a click-through,
+  unless the preparing is itself worth watching;
+- **menu items and popovers are named by their text** — they render in portals, so
+  "Create → Task" can be found and "the menu under the Create button" cannot.
 
 ## Report