kfickel/streamd

Fork 0

todo done: stable indices across calls + print completed task #95

New issue

Closed

opened 2026-04-24 19:54:14 +02:00 by kfickel · 1 comment

kfickel commented

2026-04-24 19:54:14 +02:00

Owner

Problem

streamd todo done re-reads open tasks from disk on every invocation. After done 1 marks task 1 as @Done, the list shrinks and old task 2 becomes task 1, old task 3 becomes task 2, etc. Running done 1; done 2 therefore marks what was originally task 1 and task 3 — not 1 and 2.

Additionally, done prints only a number and gives no feedback about which task was completed.

Feature 1 — Stable indices across sequential `done` calls

Accept multiple numbers in a single invocation (recommended)

Change the CLI signature to streamd todo done <N>... (variadic). Collect all requested indices up front from the same snapshot, then process them highest-index-first so earlier indices stay valid as tasks are removed.

streamd todo done 1 2     # marks original task 1 and task 2 in one shot

Session state file

On every todo list or todo done call, write a snapshot of (index → file:line) to a temp file (e.g section todo of. .streamd-cache.toml is an array of index -> {filename, line}). done N reads the snapshot to resolve the original file:line. The snapshot is invalidated whenever the markdown files change (compare mtime).

Feature 2 — Print the completed task on `done`

After successfully writing @Done, print the full task block (same format as todo list) so the user sees confirmation of what was completed.

Current output:

Marked task 1 as done

Desired output:

Done: [1] --- notes/work.md:42 ---
## Fix the flaky CI test @Task @Done

Implementation: in run_done, after writing the file, read back the (now-modified) lines for start_line..end_line and print them — same loop as run_list.

## Problem `streamd todo done` re-reads open tasks from disk on every invocation. After `done 1` marks task 1 as `@Done`, the list shrinks and old task 2 becomes task 1, old task 3 becomes task 2, etc. Running `done 1; done 2` therefore marks what was originally task 1 and task 3 — not 1 and 2. Additionally, `done` prints only a number and gives no feedback about *which* task was completed. --- ## Feature 1 — Stable indices across sequential `done` calls ### Accept multiple numbers in a single invocation (recommended) Change the CLI signature to `streamd todo done <N>...` (variadic). Collect all requested indices up front from the *same* snapshot, then process them **highest-index-first** so earlier indices stay valid as tasks are removed. ``` streamd todo done 1 2 # marks original task 1 and task 2 in one shot ``` ### Session state file On every `todo list` or `todo done` call, write a snapshot of `(index → file:line)` to a temp file (e.g section [[todo]] of. `.streamd-cache.toml` is an array of index -> {filename, line}). `done N` reads the snapshot to resolve the *original* file:line. The snapshot is invalidated whenever the markdown files change (compare mtime). --- ## Feature 2 — Print the completed task on `done` After successfully writing `@Done`, print the full task block (same format as `todo list`) so the user sees confirmation of what was completed. Current output: ``` Marked task 1 as done ``` Desired output: ``` Done: [1] --- notes/work.md:42 --- ## Fix the flaky CI test @Task @Done ``` Implementation: in `run_done`, after writing the file, read back the (now-modified) lines for `start_line..end_line` and print them — same loop as `run_list`.

kfickel referenced this issue from a pull request that will close it,

2026-04-24 20:06:55 +02:00

feat: todo done accepts multiple task numbers and prints completed task #96

kfickel commented

2026-04-24 20:07:02 +02:00

Author

Owner

Implemented in PR #96.

Duration: ~15 minutes
Tokens: ~40k input / ~3k output

Summary of findings:

Refactored run_done to accept &[usize] and extracted mark_task_done as a testable helper — clean separation that made TDD straightforward
The highest-index-first sort + upfront validation approach from the spec worked well; no edge cases needed beyond what the issue described
dedup() handles duplicate numbers gracefully (e.g. done 1 1 marks it once)
The print output reuses the same lines[start..end] slice already computed during file mutation, so it shows the post-@Done line — consistent with the desired confirmation output

Implemented in PR #96. **Duration:** ~15 minutes **Tokens:** ~40k input / ~3k output **Summary of findings:** - Refactored `run_done` to accept `&[usize]` and extracted `mark_task_done` as a testable helper — clean separation that made TDD straightforward - The highest-index-first sort + upfront validation approach from the spec worked well; no edge cases needed beyond what the issue described - `dedup()` handles duplicate numbers gracefully (e.g. `done 1 1` marks it once) - The print output reuses the same `lines[start..end]` slice already computed during file mutation, so it shows the post-`@Done` line — consistent with the desired confirmation output

kfickel closed this issue

2026-04-24 20:13:54 +02:00

No labels

planned

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference: kfickel/streamd#95

No description provided.

Rows
Columns