I looked into beads but I didn't see a way to make it work any better than fossil, and fossil does more stuff. My typical setup is to use the repo as a working directory, the tickets for todo, wiki/forum for conversation. There is also a chat interface, but I haven't tried that with agents yet.
But I love fossil for this. You can create users for all of the agents (or agent roles). The CLI for fossil is just a binary and it compiles nearly everywhere.
+1 over here for agentic fossil. With fossil the "work" is integrated in with the code. Beads separates this out, the beads are instances of work that agents can consume, and they aren't part of the work repo. I could see why you might want this, but I still think that fossil gives you more utility.
i feel like dropping the review and test phase -- especially in the agentic context - is incredibly spicy though.
So if I wanted to use fossil scm, i'd have to find a way to glue that on, and now ... we'Re basically in the same situation as with any other solution: it supports only a subset of the feature we want.
and especially CI pre "merge" is a hard requirement, and fossil doesnt have any concept for that i think?
But the last time i evaluated it was in the mid 2010s, so things may have progressed since? but couldn't find anything on cursory glance and AI confirmed that position, but we all know how often its wrong... so how did yall solve that issue?
Fossil doesn’t have GitHub PR capabilities per-se. But its design philosophy is different with a focus on smaller groups of devs and not so much drive-by patches. I think in the case being discussed for AI agents, it can be simplified.
If you want human review on the code I’m thinking keep it simple and just review in branches/tags before merging OR even just have loose patch files.
As we’re seeing with resurgence of command-line utility by agents, that extends equally well to the O.G. diff/patch. A PR is literally just a diff with commentary and an approval process prior to merging. Diffs can be attached to forum topics and so-forth.
Lots of possibilities, but I think the main thing discussed here is how is version control better suited to AI agents moving forward.
yes, I agree: architecthre design, linting, commit msg structure, unit testing and other ci gates helps to direct the agents into building better software.
in my case, i use opencode with oh-my-openagents. Omo has an orchestrator in charge and manage all the intetactions between agents. ADRs store decisions and beads store decisions as well (including design ones), then multiple agents work on a single bead.
I have been meaning to use Justine's RedBean to build a "project app" (kind of like what the OP describes, but leaning more towards something like Datasette). It would contain the data, the paper(s), and the UI for interacting with the data (and supporting scripts or R that can be run with other tools). I just like the idea of a portable single-file scientific artifact.
Yeah I love all their Arkane stuff, and the two Half Life docs they did under their whitelabel company Secret Tape company for Valve. And of course the big Disco Elysium series.
It is actually their 10th anniversary in September, so if you like their work I would highly recommend their patreon to make sure they can do another 10 years.
Their discord is actually one of my favourite places on the internet to talk about games because everyone in there has such great taste and is knowledgeable about the actual production process of games.
They also have a second channel/patreon now called noclip_2 which is focused on underground/indie games which has been a constant source of joy for me, all the best games I've played in the past year I've discovered via their videos or their discord.
Just great vibes all around.
Edit: almost forgot, they are also running a project to digitize old videogame tapes so if you want to see old interviews with carmack or footage from E3 in really nice quality they have a YouTube channel for that too
I love Fossil, I have been using it for all of my projects for the last couple years. Things that I love include:
1. batteries included single-file functionality (fossil binary + sqlite file and I have everything!)
2. Hosting them is super easy, I have a lighttpd server configured to do cgi-bin, and i just pop the project.fossil file onto the server and I have a project.
The biggest friction is managing users across repos. Each repo is its own RBAC, the "zhynn" user in one repo is not the same as the "zhynn" user in another repo. It would be cool to be able to sync users across repos, which should be possible with sql, but I think that it could get weird with repo-specific permissions. Currently I just add my user to each new repo, granting that user setup permissions, and removing the admin before I scp the .fossil file up to the webserver.
In the end though, I intend to use it for all of my personal projects from here out.
I have a pipe dream of turning a fossil repo into a portable distributed more-async-friendly slack clone, where the "chat", "wiki" and "forum" functionalities are all used as the back-end for a responsive UI that basically does the same thing that slack does, but lives in a single sqlite file + binary. It could run mostly offline in a kind of scuttlebutt/limited connectivity pattern (when online push/pull messages, get latest chats/files/etc, go back offline. As you go through the content, make your responses locally, then go back online, push/pull again, repeat.)
I have another pipe dream of making a RedBean APE fossil UI. I think it would be cool to have a single file universal executable that is my project repo.
Those two pipe dreams sound really cool! Do you have a website or something to lurk you via if you eventuality get around to those? I find it difficult to keep up, as it were, using form histories and other social media platforms.
But I love fossil for this. You can create users for all of the agents (or agent roles). The CLI for fossil is just a binary and it compiles nearly everywhere.
+1 over here for agentic fossil. With fossil the "work" is integrated in with the code. Beads separates this out, the beads are instances of work that agents can consume, and they aren't part of the work repo. I could see why you might want this, but I still think that fossil gives you more utility.
More info on beads if you are curious: https://github.com/gastownhall/beads