← Blog
AGENTS4 min read

Our trending-repo scanner proposed twelve adoptions. None of the records survived.

Aug 19, 2026DekimuAI-generated

A scheduled job scans GitHub's trending repos, writes a short case for anything new, and asks us to approve or decline it over Telegram. Reconstructing two weeks of its proposals this week, we found that every earlier approval had been decided — and then vanished, because the record of it never reached our main branch.

Why did approved work just disappear?

The bot that sends each proposal runs as a gateway with limited git access: it can commit to a feature branch, but it can't push straight to main. That's a deliberate boundary. What wasn't deliberate is that nothing ever watched for the branch it left behind. Four separate attempts to write down a batch of approvals, going back to late July, each landed on its own orphaned branch and sat there.

The consequence compounds. Our stalled-work monitor — the one whose entire job is reddening on anything left open past its deadline — reads from main. An item that only exists on a branch nobody merged was invisible to it from the start. A deadline had been attached to one batch of approvals; it lapsed two days before we even found the mess, and nothing noticed, because nothing could.

The fix wasn't the branch. It was the memory.

The deeper problem was where a proposal lived at all: a Telegram message, which we deliberately never mirror in full, and a workflow log with a seven-day expiry. An approval that takes two weeks to land — which is exactly how long this one took — outlives both. By the time anyone said yes, the reasoning that justified it was already gone.

The mechanism that was supposed to file the record was also the only thing that would have noticed the record was never filed.

So the fix wasn't just merging the stuck branch. Every validated proposal now gets written to a database the moment it's sent, kept for four months instead of seven days, and readable on demand with one command. A decision that takes two weeks no longer has to survive on luck.

What we actually said yes to

One item became a real adoption: an MIT-licensed diagramming project had five chart types we didn't — quadrant, pyramid, venn, org chart, layer stack. We didn't install it. We read how it built those shapes and rebuilt them as our own skill, on our own design tokens, and left its typography behind entirely, because matching a font isn't the same decision as matching a layout algorithm. We also diffed our own documentation conventions against a published open standard for how these tools should describe themselves, and confirmed we already meet it — a null result worth having on the record, since the alternative was assuming and being wrong later.

What we said no to, on purpose

Most of the batch was declines, and we wrote down why each one, so the same repo doesn't get proposed and re-litigated next month for free. A memory-and-audit platform asked us to run three services and an LLM proxy to solve a problem our existing file-based memory already solves for a company of one. A vulnerability-hunting agent that runs live exploits got held, not declined — pointing an exploitation tool at production isn't a decision a scanner gets to make unattended, no matter how good its pitch. A tool-version pinner turned into something more useful than the original proposal: we measured, for the first time, that our own workflows are split across three different Node versions with nothing enforcing any of them — a real, already-paid-for cost, still waiting on one human decision about which version wins.

AGENTS

This post was drafted by an AI system from Dekimu's public engineering record and published with automated checks, without per-post human editing.

← Back to blog