Repository navigation
Description
Bug
In the id web markdown codec (pkgs/id/src/web/markdown.rs), an ordered task list loses its ordering on save: it comes back as a bullet task list, and a non-1 start number is lost with it.
Evidence (verified this run, main 14dd66b6)
Standalone probe crate compiling the verbatim codec from current main (logs: goal hidden_files/probe-2026-10-26-1215/out2.log + out3.log):
- Input:
Parsed PM: a single
1. [ ] todo 2. [x] donetask_listnode (noorderattr anywhere). Saved output:- [ ] todo - [x] done - Input:
Saved output:
5. [ ] five 6. [x] six- [ ] five/- [x] six— both the numbering and the start value 5 are gone.
Root cause, both directions:
- Parse: the
NodeValue::Listarm (markdown.rs:~205-220) checks only whether the first child is aTaskItem; when it is, it emits{"type":"task_list"}and discardslist.list_type(Ordered vs Bullet) andlist.start. The non-task branch right below does preserve both (ordered_listwithattrs.order). - Save: the
task_listarm ofjson_to_ast(markdown.rs:~946) hardcodeslist_type: ListType::Bullet, bullet_char: b'-'— there is no PM shape that could carry the ordering even if parse kept it.
For comparison, a plain ordered list round-trips correctly (3. three / 4. four keep order: 3 — same probe), and a plain bullet task list round-trips correctly. Only the ordered+task combination loses data.
Why it matters
Ordered checklists are a natural way to write sequenced steps ("step 1… step 2…") with completion state. Opening such a file in id and saving any edit silently renumbers it into an unordered checklist — the sequence information the author encoded is destroyed without any visible warning in the editor.
Acceptance criteria
1. [ ] todo\n2. [x] doneround-trips as an ordered task list;5. [ ] five\n6. [x] sixadditionally preserves the start number 5 (sameorderconvention asordered_list).- The PM representation chosen (e.g. an
orderattr ontask_list, or ordered list semantics for task items) must be one the web editor schema can actually render/edit — checkpkgs/id/webbefore settling; if the editor cannot represent it today, the issue's fix note must say what was chosen and why. - Mixed content keeps working:
- [ ] todo\n- plain(task + plain items in one list, existing testtest_task_list_mixed_content) does not regress. - New unit tests in
pkgs/id/src/web/markdown.rscover ordered task lists with start 1 and start >1, both directions. - Existing codec tests pass.
Related
- Plain task lists and plain ordered lists are both fine (probe-verified this run) — this is only the intersection.
Activity
developing-today commentedon Oct 26, 2026
CODE-171
dezren39 commentedon Oct 26, 2026
🤖 Agent note · state: filed
14 remaining items
dezren39 commentedon Oct 27, 2026
Parked — PR #1042 opened, CI still running (15 SUCCESS incl. cargo-fmt-check, 12 pending, 0 failed). Local verification: verbatim-codec probe suite 70/70.
Merge pull request #1042 from developing-today/queue/1195-997-ordered…
dezren39 commentedon Oct 27, 2026
Done — PR #1042 merged (merge commit 1fdc882); issue auto-closed. Full CI green on the PR (test-web-unit, test-web-typecheck, cargo-check, clippy, fmt all SUCCESS).