GitHub: a tour of the repositories I maintain (and why they exist)

For me, a repository is the cheapest way to think an idea through until it talks back. That isn’t metaphor — it’s workflow. I start by writing a README, and when the README starts arguing with me I know the rest is worth building. The README that doesn’t argue — the one that stays polite and stays vague and lets me write whatever I want — usually means the idea hasn’t hit anything real yet. I’ve learned to distrust a README I can finish in twenty minutes.

There are 64 public repositories on my GitHub. Most of them are the README stage: the idea survived long enough to get a name and a first commit, and then ran into something. A few of them are where I actually live.

What occupies most of my head#

That caption is doing a lot of quiet work. I’m a public attorney in Rondônia — Estado do Pará’s neighbor, Amazonia’s working edge. My day job involves reading official gazettes looking for things that matter: appointments, contracts, regulatory decisions, the kind of legal text that gets published because publication is required and then disappears into a search engine that doesn’t index it properly. Causaganha is my attempt to automate what I spend too many hours doing manually. It is also my clearest answer to the question of what I would build if I could only build one thing.

The README argued back for three years. It’s still arguing.

Agents and harness#

Orbiting causaganha is a layer I built because I needed it.

These exist because causaganha kept needing things that didn’t exist yet. Canivete because I needed one tool that could talk to several agents. Funes because agents forget, and the forgetting is usually what breaks a session more than anything technical. The-theater because some problems are better understood when you watch two positions fight it out rather than trying to hold both at once.

I don’t always know whether they’re good tools or just tools I’m used to. That distinction matters and I’m often unable to make it clearly.

What Porto Velho smells like in code#

Civic-tech without a lawyer nearby tends to become a pretty blog post with no legal effect. I know because I’ve watched it happen, and once or twice I’ve been the one watching it happen to something I built.

Here’s what that looks like in practice. A team builds a clean political-finance tracker. The data pipeline is solid; the visualization is good. But the entity resolution uses CNPJ as a canonical identifier, and in Brazilian law an operator running three shell companies under the same beneficial owner appears as three distinct entities with a third the reported income each. The interface is beautiful and the numbers are wrong and there is nobody on the team who knows why Article 10 of the Lei Eleitoral distinguishes declared from effective income. Someone files a complaint with the Tribunal de Contas using the numbers. The complaint gets rejected on a technicality that any lawyer would have caught before the first commit. The README never hit the legal layer, so it never argued back.

The reverse is also true — a lawyer without technical capacity can read a contract and miss the database structure underneath it that determines whether the contract is enforceable or theater. I’ve been that lawyer too. Once I reviewed a service contract with a well-drafted SLA clause — response times, uptime guarantees, penalty schedule — and signed off on it. Two years later the contractor missed the SLA for six consecutive months and we had no grounds to apply the penalty, because the contract didn’t specify what monitoring system would generate the evidence, and the only system that could prove the violation was the contractor’s own. Legally correct. Technically unenforceable. I was the lawyer who didn’t think to ask what database was generating the SLA report.

These three are the clearest expression of the gap I’m trying to close:

Porto Velho is far. Infrastructure is expensive. The accountability layer that exists in larger capitals exists here mostly on paper, and the paper is in a gazette that nobody is reading systematically. Most weeks I am one of the people who should be reading it, and I’m in a hearing instead, or writing a parecer about something else entirely. The Diário Oficial do Estado de Rondônia publishes appointments and contracts and regulatory decisions because the law requires publication — not because anyone is guaranteed to see them. I build tools for reading it systematically not out of civic virtue, exactly. It’s frustration that found a compiler.

Satellites#

The other 49 or 50 I cannot defend one by one. Some I reread with pleasure; others, with embarrassment. The embarrassing ones are usually the ones where I knew, when I wrote the README, that it wasn’t arguing back yet — and I committed anyway because the idea seemed exciting and I didn’t want to wait for the friction.

The best tool for telling those apart is time. Open a repo after six months and know within thirty seconds whether you were building something or just performing the act of building something. The thirty-second test is pretty reliable. What I’ve noticed, applying it, is that the repos that survive are the ones whose READMEs argued with both layers simultaneously — technical and legal at the same time, neither one letting the other make the easy move. The ones that die tend to die on one side. Code that runs fine and has no accountability structure attached to it. A legal argument that’s solid and has no compiler. Most of my satellites are that: one layer present, one layer absent, README too polite to say so.

causaganha has been arguing with me for three years because it can’t afford to stop arguing. The moment it accepts what I hand it without pushing back, the gazette becomes a folder of PDFs again. That’s the test. Half of the 64 will die without a reader, and that’s fine. What I can’t afford is for the ones that shouldn’t die to die quietly — the ones whose READMEs were still arguing and I just got tired of listening.