I'm curious, and in the spirit of a true MVP - does this need type, assignee, links or the parent relationship? Do you see the agent using them in practice? It seems like a minimal implementation could do without all of those, and I wonder if they're useful to the agent, or are just documentation for humans.

Since these seem more lightweight/ephemeral, it seems like it would be useful to search upwards for the nearest enclosing .tickets directory, so that subsystems could have separate issues.

Great call out. The agents will set those on `create` calls but don't typically reference them afterwards.

I have a fairly robust orchestration layer built on top of this tool that relies heavily on those fields though. But without that, they are a bit noisy.

Mixed feelings on upward search. One of my pain points with beads was that agents would sometimes create a bead outside of the correct directory and get dumped into a global `~/.beads/default.db` and make a mess. They've done that a couple times with ticket but run `tk ready` afterwards, see the new ticket is the only one, realize their mistake, and then relocate the ticket into the correct location. Still thinking on that one.