Visible hierarchy in ID

[lukaskawerau]

Love this - much cleaner than beads.

The one thing I wish it had that beads did well would be to have issues inside an epic be clearly related to the epic.
For example, right now I have:

• Epic: rwp-6b67 — Some epic
• Feature part 1: rwp-9afa — something
• Feature part 2: rwp-31eb — something else

When scanning the markdown files or the ticket list, it's impossible to relate these to each other without parsing the file itself.
I would like something like:

• Epic: rwp-6b67 — Some epic
• Feature part 1: rwp-6b67.9afa — something
• Feature part 2: rwp-6b67.31eb — something else

OR

• Epic: rwp-6b67 — Some epic
• Feature part 1: rwp-6b67.1— something
• Feature part 2: rwp-6b67.2 — something else

I actually would prefer the first version, since that doesn't force ordering of tickets – that is something that can be done inside the ticket. But rough hierarchical relationships here (epic -> task; epic -> feature; chore; bug; [maybe add other conventional commit types as well]) would be awesome.

[snapwich]

agreed it would be nice to see the hierarchy in tk ls and such. this is a bit tricky though as if you actually make the IDs include the parent id while sticking to the convention that the filename is the ID, that means you need to rename the file if you change the parent.

i don't see any reason why you shouldn't be able to change a child's parent, but having the filenames being an immutable ID has a lot of benefits, imo; especially since they'll be committed in source control.

it kind of makes me think whatever is done should only be done at a presentational level.