AkiDevRule 2.6.0: A Near-Miss Push to GitHub, and a New Rule for Automation Safety
One harmless question once made the /akiship autonomous release system push code straight to the main branch. AkiDevRule 2.6.0 fixes the activation mechanism and adds coding.B5, a mandatory ladder an AI must climb before handing a check to a human at all.
AkiDevRule 2.6.0 shipped on 2026-08-22, but unlike prior releases that added a new skill or thinking framework, this one fixes something more fundamental: the safety of the automation itself. A real incident made /akiship — the skill that runs the whole release ritual in one command — push code to GitHub without ever being asked to, and the fix for that incident exposed a bigger, more general gap, now captured as a new core rule: coding.B5.
The incident: a question misread as a command
The project owner asked a simple, exploratory question: "so what's left to do for this to be complete" — a question, not an order. But the session read the word "complete" as release.B8's authorization signal for an unattended release run, granted itself the authority, and pushed two commits straight to the main branch (origin/main) before anyone could review them.
The root cause was structural asymmetry: the trigger word ("complete") lived in the skill's description — the part loaded into every single session — while the condition that scoped it ("only inside an actual invocation") lived in the skill body and in RULE-release.md, both of which load only on a signal match. A keyword that is always present matched against a condition that is usually absent from context.
The fix: /akiship now requires the literal command, never a keyword guess
Activation is now literal — it fires only when the turn contains the exact string /akiship and asks for the run to actually be performed. A worked table now separates "run /akiship to completion" (execute) from "if I ran /akiship, what would completeness need?" (consult only — answer from the checklist, edit nothing, commit nothing, push nothing); whenever a question can be read either way, consult is the default.
The bare words "akiship", "full release", "ship this whole batch", and every completion-intensity phrase standing alone are demoted to plain vocabulary — none of them self-activate anymore. More importantly, the guarding condition now opens the skill's description itself, so it is exactly as resident in every session as the trigger word — never again one present while the other waits to be loaded.
coding.B5 — handing a check to a human is the last rung of a ladder, never the default
The incident exposed a wider problem: handing a check to the project owner costs exactly what a question costs — their time to read it, and a real action on their side — yet it was never treated as a question, so it slipped past every filter built for questions. coding.B5 closes that gap with six rungs to climb, stopping at whichever one actually settles the doubt, before a hand-off is allowed at all:
1. Read the flow — most "needs manual testing" items are really "nobody traced the call path yet". 2. Search the local tree — a README, a CI matrix, or a sibling install often already has the answer. 3. Search vendor docs and the open web — another platform's behavior is settled by its published documentation, not by re-observing it once more. 4. Probe mechanically, right here — simulate the other OS's path, stub the clock or an env var, run the pure function that produces the exact string in question. 5. Run the real thing, reversibly — back it up first, restore in a trap, and only after confirming the tool is actually installed. 6. Only then hand off — carrying exactly one line naming which rung failed and why.
Whatever survives to rung 6 must hand over a result to confirm, not a task to design: the exact command, the expected output, and what a deviation would mean. Familiar rationalizations — "can only be verified end-to-end", "needs a real machine", "only the owner can decide" — now count as evidence the ladder was never climbed, not as valid reasons to stop.
What this means for AkiDevRule users
Both changes point at the same principle: an autonomous system is only trustworthy when the constraint that scopes it is exactly as present, at exactly the same moment, as the trigger that activates it — not scattered somewhere waiting to be loaded in time. AkiDevRule keeps the entire investigation and fix on the public record, in the repo's own docs/research/ and docs/plan/done/ — including when the bug is in the system itself.
Anyone running /akiship should update to 2.6.0: git pull && bash install.sh. The original incident only reproduces on an install older than this fix.