Ten consecutive clean landings of the same kind of automated pull request, in the same repository, now write themselves into a promotion proposal — a request to let that specific pairing of change-type and repo merge without a founder tap from then on. The proposal still needs a person's yes. Nothing in the mechanism can grant that yes to itself.
Every automated pull request in this system already carries a marker naming its category — a major dependency bump, a package publish, an anchors release. The new mechanism, internally called P6, watches every category flagged as eligible for promotion and counts how many of its marker-tagged pull requests have merged since the last time anyone checked. Ten in a row, with no failure in between, and the category earns a proposal: stop asking a person before landing this specific kind of change in this specific repo.
The count resets the moment something goes wrong. If an automated fix in a category gets flagged as a regression, that category's streak doesn't just pause — its baseline is pushed forward to the moment of the incident, so landings from before the failure can never quietly count toward a future promotion once the incident record ages out.
A major dependency bump doesn't land in one place. The same category of pull request opens across a dozen standalone repositories plus the shared monorepo, and a clean run in one of them proves nothing about the others — different maintainers reviewed the last incident differently, different repos carry different dependency graphs. So the streak is counted per pairing of category and repository, each against its own separately stored baseline. A repo with nine clean landings and one with eleven are two different proposals, not one blended average that lets the stronger repo cover for the weaker one.
The design went through an adversarial review before merging, and it caught two real problems. The first was a phantom repository: the plan for the anchors-publish category pointed at a GitHub repo slug that has never existed — anchors ships as a folder inside the monorepo, not its own repository, and an earlier automation had already died twice trying to reach that same nonexistent address. The second was a trust gap: the marker that names a pull request's category is just text in a comment, and nothing originally stopped a pull request from carrying that marker without having actually gone through the trusted, automated merge path. Both were fixed before the feature shipped — the repo pointer corrected, and every counted landing now also has to pass the same author and branch checks the real merge lane enforces.
A category earns the right to ask for less oversight. It still can't grant that to itself — the queue is where every proposal, including this one, waits for a person.
Two categories are wired into the mechanism so far. Major dependency bumps have been accruing a real streak since the automated merge lane itself went live the day before this shipped — the counter has actual landings behind it, not a simulated one. Anchors publishes report an honest zero, because no anchors release has gone through this specific path yet; the mechanism doesn't fabricate progress to look active, it just reports what hasn't happened. No category has crossed the ten-landing threshold yet, and no promotion has been ratified. The queue this feeds is the same review queue every other automated proposal lands in — read by a person, on their schedule, not the mechanism's.
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