Looks great, well done.

What I do not understand about beads or alternatives such as this is: why not just use github issues? Or is it just the aversion of being tied to github?

My agent team does, easy to tell them so and give them access to suitable gh commands.

vendor lockin + slow network calls (+ GitHub is down sometimes). if you want to search over hundreds of issues, `gh search` isn’t bad but you can do a lot better with a filesystem or embedded database

that said for work I use GitHub and have CC make use of the gh CLI, works great. but I have wanted some sqlite/duckdb tracker you could just commit, maybe with back and forth between markdown files. also GH projects are pretty slow/clunky

It's a great question. I'm sure the answer varies a lot by who you ask.

For me, there's a ton of extra control and capability from having things local. Nothing wrong with github, and agents are great with the gh CLI, but it's really not quite the same.

Plus, having it based on directory structure rather than repo means I can locate tickets where the work actually happens. Not everything I work on is on github, and some of the things that are on github are in monorepos where each project really deserves its own set of tickets.

IMO Beads, Ticket, etc. give you optionality.

Not every project needs to have Github as a dependency. Its added overhead and coordination work that isn't needed for every job.

YMMV, and I get it if you're in a commercial/professional environment, but if you're a solo dev or a small team, then IMO Github doesn't need to be a part of your orchestration (setup project, issue CRUD, pr, etc), just state sync/distribution.

Agents can use local trackers as drop-ins to GH and have similar commands provided to do the same job.

Its fewer moving parts, and more forgiving as you can fix things locally, before pushing out to GH or your Git server of choice.

I agree with OP that beads has great primitives, but I think its become a bit unwieldy in trying to becoming something "everyone" including larger teams can use.

Going to try Ticket out, though personally I prefer JSONL to MD for this kind of tracking, since I find that Claude finds a good concise balance of detail on its own when writing to JSONL vs Markdown files where it tends to be verbose.

This is my question, and why not go a step further and just self host foregjo?

Forgejo is a single go binary and very fast.

You can script it using an API, you have full access to the database which can be sqlite3 or postgres.

Then you get all the benefits of an integrated issue tracker which has a great GUI for humans to review.

I really don't understand the raison-de-etre for beads other than yak shaving, and would really like to.