Three tracking tools in six weeks

GitHub Projects lasted thirteen days. My Obsidian vault, twenty-five.

Between May 24 and July 1st, I moved all my tickets twice. Not for fun. Each time, the tool broke on something I hadn't seen coming, and each time it came down to the same thing: I'm no longer the one writing to the tracker. An agent is. And an agent writes a lot.

GitHub Projects: thirteen days#

The plan was reasonable. The code is on GitHub, so are the PRs, might as well put the board there. One place, no extra account.

Except my commands drove GitHub Projects through GraphQL, and GraphQL has a quota: 5,000 points per hour. With an agent reading the board, moving a card, reading again, updating a field, the quota was gone in half an hour of session.

And the worst part is that it's shared. The gh pr commands go through the same one. So once the board had drained it, I couldn't open a PR either.

You want to merge, and GitHub tells you to come back when the quota has refilled. Because of a kanban.

On June 6, I pulled everything out.

Obsidian: twenty-five days#

I really liked the next idea. A ticket is a Markdown note with a header: status, priority, size. The board is an Obsidian view that groups notes by status. Everything is local, versioned in git, readable offline. No quota. No service to ask permission from.

The migration took one day: 156 tickets and 23 architecture decisions from Luchamon, imported by script. Seven PRs merged the same day to rewire the rest.

First loss on the way: priorities and sizes. In GitHub Projects, those fields only came out through GraphQL — the very thing I was running from. I reset everything to the default value, and re-sorted by hand afterwards.

Then the trouble started, and it all came from the same place. An Obsidian vault is made for a human who writes now and then. Mine had three writers: me, my commands, and a bit of CI that updated the note when a PR merged. The result: git collisions, and a mobile sync that kept tripping over them.

On migration day itself, a first bug had to be fixed: the CI closed the ticket on GitHub before saving the note. If the save failed, the ticket was closed on one side and open on the other.

I loved the principle. I lasted twenty-five days.

YouTrack: July 1st#

Third try, and this time a real tracker, with a real API built to be hammered. 94 tickets for Orfeo, 248 for Luchamon including 154 archived, 34 architecture decisions.

But I had learned two things from the previous rounds.

Keep the old numbers. YouTrack renumbers everything on import. I added a field holding the original identifier. Old commits and old PRs still point at something.

Check that I can leave. Before removing anything from the vault, I went the other way: exported all of YouTrack back to Markdown, and compared. If the tool disappoints me in six months, I know my tickets aren't hostages.

YouTrack had its surprises too. The board doesn't fill itself through the API: you tick a box in the interface, then backfill what already exists by hand. And in August I found out that search silently capped at a thousand results. But nothing that makes you want to move.

The real change, that day#

Two things happened on July 1st. The switch to YouTrack. And Foundry's first commit.

That's no coincidence. On the third migration, I finally saw what was costing me: not moving the tickets, which scripts do in a day. What cost me was rewriting all my commands every time, because each one talked directly to the tool of the moment.

So in Foundry, the tracker is a socket. On one side, the pipeline and the skills, which only know tickets, decisions and states. On the other, an adapter that translates for the real tool. The founding document says it from day one: changing tools later means writing an adapter, not rewriting everything.

There's even a GitHub Projects adapter in the repository. Empty, for now. It's there to prove the socket exists.

And my own, while I'm at it#

Of course, I also tried building my own tracker. In late August, plugged into Foundry like the others, with a real database and real write guarantees.

I set it aside. Too heavy. Maintaining a tracker on top of the tool that uses it was one project too many.

What I'm keeping#

Three rules, learned the expensive way.

An agent writes far more than a human does. A tracking tool that holds up fine with me can fall over in half an hour with it.

Always keep the old identifiers, and test the way out before closing the door behind you.

And the tracking tool must never be hard-wired. I don't know whether YouTrack will be the last one. I just know the next one won't cost me a rewrite.

— Pato