use jsonl format for appending logs in track cmd + toolpath crate convenience methods#6
use jsonl format for appending logs in track cmd + toolpath crate convenience methods#6benbaarber wants to merge 2 commits intomainfrom
Conversation
benbaarber
commented
Feb 26, 2026
- added Path::load_jsonl and Path::steps_to_jsonl in toolpath crate
- update the track command to use an appendable jsonl log instead of expensive full read/write
|
🔍 Preview deployed: https://579ab1fb.toolpath.pages.dev |
akesling
left a comment
There was a problem hiding this comment.
LGTM
TBH with all this being a vibe-slop base my standards are fairly low right now. As long as this works as advertised and users of the track command can contentedly still use this, that's good enough.
That being said, if you're open to tidying this up and making it better, I'm happy to give more suggestions / guidance ;). I've made a couple comments that you can optionally follow to that end. Choose your own adventure.
| } | ||
|
|
||
| /// Append a single step as one JSONL line (no rewrite). | ||
| fn append_step(session: &std::path::Path, step: &v1::Step) -> Result<()> { |
There was a problem hiding this comment.
Does this need to care about it being a step? Maybe just s/append_step/append/ and take an impl Serialize?
| // ============================================================================ | ||
|
|
||
| /// Derive the `.jsonl` steps file path from the `.json` session path. | ||
| fn jsonl_path(session: &std::path::Path) -> PathBuf { |
There was a problem hiding this comment.
Any interest in refactoring this to be an on-disk manager that owns the two file management and abstracts away json/jsonl, etc. It could have an impl with rewrite/read/etc. methods and a clean constructor. I feel like the state machine for all of this would be better handled with something like that.
|
Will revisit in toolpath log implementation |