chadtmiller.com/knotless

Switch repository

Loading…

What changes

The author of an issue, pull or comment can tick and untick the task boxes (- [ ]) in what they wrote. Until now the boxes were always disabled. Each tick rewrites that one item's mark in the body through dev.knotless.editItem, so the record in the author's PDS says it. The boxes wait while the write runs, and a box whose write fails goes back. Anyone else still sees the boxes disabled, since only the author can write the record.

Why

Issues with a checklist, such as Basic forge features missing, from archive downloads to webhooks, couldn't be ticked off on the page.

A tick finds its item in the Markdown by counting list items that start with a box (inside quotes too), leaving out fenced code. The pages get only the rendered HTML from serve, so this count has to match pulldown-cmark's. When it doesn't, for example with a task inside indented code, the boxes stay disabled rather than risk rewriting the wrong line.

How it was checked

• npm run check in web/ passes.
• I checked the task finder by hand on nested, numbered, quoted, [X] and fenced items.
• A new e2e flow, "ticking a task in what was written", ticks a box as the issue's author and reads it back from the PDS and the index.
• I looked at it with just look issue --as bob.test: boxes are live for the author and disabled for others, in desktop light and phone dark.

Shortcomings

• Maintainers can't tick boxes in someone else's issue, as GitHub allows, because the record lives in the author's account.
• Line comments on a diff aren't covered.
• Tick two boxes in quick succession and the second waits for the first write to finish.

🤖 Generated with Claude Code

This lets the author of an issue, pull or comment tick its task boxes. A tick finds its item by counting task list items in the Markdown, then rewrites that item's mark through editItem. The boxes stay disabled unless the count matches the rendered boxes, and a failed write puts the box back.

I found nothing that must change. The guard is sound: the count and the offsets are in the same JS string that is sent back, so a mismatch disables the boxes rather than rewriting the wrong line. Only the author gets tick, which matches the server's author-only rule. Sending body with no images is fine, since forge::edit attaches the pictures the new body links to.

• The guard compares counts only. A body with a task-looking line in code the finder misreads, and a real task it misses, would give equal counts and tick the wrong item. That needs an unusual document, so I'd accept it, but the "boxes disabled on mismatch" comment in tasks.ts slightly overstates the guarantee.
• The checks were still running when I read them: check and lexicons had passed, docs was skipped, and e2e, test, web and shots hadn't finished. Their results should be read before merging, in particular the new e2e flow and web.
• tasks.ts has no unit test, and web/ has no test runner to add one to. The e2e flow is the only automated cover for the finder, so the nested, numbered, quoted and fenced cases rest on your hand check.