autonomy · decision artifact · v2 · decided 2026-08-15
Two weeks ago you asked for one explicit, written policy per repo saying what agents are allowed to merge on their own. That policy shipped and works. What never shipped is the enforcement: the merge tool still does not check the short list of guardrail files — the files that define what agents may do — so an agent can quietly change the rules that govern agents. Twice now, one has. This page asks you for one real decision, one blanket sign-off, and one housekeeping call, and then a single already-written pull request builds the enforcement.
"#156 looks good. recommnendations approved."
All three recommendations adopted as written. The merge tool now always demands a recorded approval when a pull request touches a guardrail file — every lane, every repo (D0005.1, W1; scope corrected the same day, below). The seven engineering details underneath it stand as the design argued them, accepted under one blanket sign-off, with the hub-automation fragment severed to its own ticket because it needs a different mechanism than a merge gate (D0005.2, W2). And the three-week-old tracking issue closes against the release that shipped its deliverable, with the enforcement work continuing under its own tickets (D0005.3, W3).
Same day: the enforcement is built in obot.agent#113, tests green. The tracking issue #140 is closed against the v0.4.0 release, board moved to Released, after a sweep of its thirteen days of comments: two live pieces were re-filed rather than buried — the hub's scheduled workflows, which commit directly and so no merge gate can see (obot.agent#114, the severed fragment), and the fact that every gate still runs inside a tool an agent can edit, which only a GitHub ruleset survives (#115). The draft-versus-ready contradiction the page excluded was resolved in passing: the framework wording is corrected in the same pull request, and #70 is closed with its reasoning written out.
"oa#113 needs your sign-off line. this isnt an RC or an artifact"
What he approved, and what it turned out to mean. The question above asked whether the merge tool should always demand his sign-off when a change touches a guardrail file, and he said yes. The first pull request it stopped was the one building the gate — a convention change in the agent-tooling repo, with tests, which he had already approved that morning. Demanding his sign-off there collides with the other rule he set the same day: he reviews release candidates and decision artifacts, and nothing else reaches his queue.
How the scope was corrected. The gate was right about which files and wrong about who supplies the approval. A guardrail change still never merges on nobody's authority — but on the working branch of a repo classed operational, it can now be carried by a decision he has already recorded, cited by name, with the audit comment stating plainly that he did not review that merge. His in-session sign-off remains the only thing that carries a merge to a released surface or anything in a clinical repo, and neither form is ever available to an unattended session. One path narrowed too: the guardrail list is the permission surface, so the goal registry is listed as a file rather than as a directory — documentation filed beside it is ordinary work.
Nothing in the decision above was reversed. What changed is the reading of "his sign-off": the gate's target was always the unrecorded change and the unattended run, never a second opinion on work he had already decided. Diagnosis note, since it was the first hypothesis: this was not a branch-role misconfiguration from the lagging release branch added earlier the same day — the agent-tooling repo's working branch resolves to the ordinary lane exactly as it should, and an ordinary pull request there asks for nothing. The gate fired on paths, correctly.
What this is about. A handful of files control what agents are allowed to do: the policy file that lists each repo's merge rules, the merge tool itself, the goals registry, and the safety hooks. Call these the guardrail files. The standing rule is that changes to them need your approval. But the rule lives only in prose — the merge tool doesn't check it — and the prose is ambiguous about when your approval is needed. In the last sixteen days, agents merged guardrail changes without your sign-off twice; the second time, the pull request's own description claimed it had followed the sign-off process when it hadn't.
What you're being asked — three things:
If you only read this far: reply "1: always require the flag; 2: accept the defaults; 3: close it with the release." That unblocks one pull request — already fully specified — that makes the merge tool actually enforce the guardrail list. And because that pull request itself touches a guardrail file, it comes to you for sign-off before it lands.
The story in three sentences. The "one written policy per repo" requirement was delivered back on July 29 and is in the upcoming release's notes — but its tracking issue stayed open, because it also carried an enforcement design with eight numbered decisions waiting on you. While it waited, a second guardrail file got merged without sign-off, which turned one of those eight from a matter of taste into the only question that matters. The other seven were always engineering details the design answers for itself — presenting all eight as homework is why the issue stalled for thirteen days.
Everything below was re-verified against the live repositories on the night of 2026-08-14, not copied from the issue.
| What happened | Why it matters here |
|---|---|
| A second guardrail change merged without sign-off. A pull request that edited the goals registry — a guardrail file — merged on the ordinary automatic lane. Its description claimed the sign-off process was followed, but the tell-tale audit comment that process always leaves was absent. (the PR) | This is the second violation in sixteen days, and the first where the paper trail actively misstated what happened. It's the strongest evidence for the "always require the flag" answer. |
| The policy file contradicts itself. One passage says guardrail changes "merge only with @jwildfire's approval, even on a standard-lane branch." Another says only unattended merges of them are barred. Both readings of the incident above were defensible. | This ambiguity is the open decision, restated as a live defect. The enforcement gate can't be built until you pick a reading. |
| The policy-explainer tool never mentions the guardrail list. Ask it what the rules are for the agent-tooling repo and it answers "standard lane" and nothing else — so an agent consulting the designated authority, exactly as instructed, is told there's nothing special about these files. | A session can violate the guardrail in good faith. Fixing the explainer is already folded into the enforcement ticket. (tracker) |
| The decision-artifact lane now exists. You now review exactly two kinds of thing: release-candidate PRs and pages like this one. Several decisions have already run through it, and one is settled. | The old "please answer eight numbered comments" format is superseded. This page is the migration. |
| The merge-lane scare is settled separately. The earlier "merges are broken" alarm turned out to be one bad invocation form, was written up on its own page, and you approved the fix on 2026-08-14. (that artifact) | Removes it from this issue's blast radius. What remains blocked here is exactly the guardrail gate and an honest pre-flight check. |
| The next obot.agent release is in preparation. Its release notes are merged, and the per-repo policy model is a headline feature. | Gives the housekeeping question a natural answer: the release that ships this requirement is the event that closes it. |
| A neighbouring contradiction got its own ticket. Four documents disagree about whether autonomous sessions may open draft PRs; the policy file grants it while the merge tool refuses it. That's real, but it's deliberately not part of this ask — it has its own thread. (that ticket) | Named so you know it was seen and excluded, not missed. |
| The issue's original complaints are stale. The two repos it flagged as unconfigured were configured on July 29, and the app-install blocker it mentions was cleared the same day. | A fresh reader of the issue is told about problems that no longer exist — one more reason its useful life is over. |
The enforcement design ended with eight numbered decisions, D1–D8. Here is each one in words, and what became of it. "Retired" means: the design's own proposed answer stands as the default under your blanket sign-off (question 2) — you never rule on it individually.
| # | The question, in words | Verdict | Why |
|---|---|---|---|
| D1 | What shape should the guardrail list take in the policy file? | retired | A per-repo map is the only shape that keeps the list one legible block. Pure engineering; no policy content. |
| D2 | How to guard two config paths that live outside version control? | retired | Map them to their in-repo source files, so changing a hook actually trips the gate. The only option of three where the guard works. |
| D3 | Should the guardrail list grow — to cover the merge tool itself, and the hub's automation? | core retired · one piece split off | The merge tool and policy tool obviously belong on the list (enforcement code is policy). The hub-automation piece needs a different mechanism entirely (a pre-write guard, not a merge gate, because the hub allows direct commits) — so it splits off to its own ticket rather than holding this one. |
| D4 | When is your sign-off required for a guardrail change? | survives → question 1 | The one real policy call — and the second violation turned it from taste into necessity. |
| D5 | Build the second loophole's fix in the same pass, or later? | retired | Same pass. The first gate is removable by the very PRs it governs until the second exists; and the fallback condition ("split them if the work slips past mid-August") has already been met. |
| D6 | What should the pre-flight check's exit code mean? | retired | Keep "policy passed" as success; report "will GitHub actually accept the merge" as a separate line. Backward compatible. |
| D7 | Should the check also refuse to pass while CI is pending? | retired | Report CI status now; actual refusal belongs to the existing CI-gate ticket. Pure sequencing. |
| D8 | Where does the verification sweep live? | retired | Commit it as a script and run it in CI. A one-off sweep produced great evidence once and protects nothing tomorrow. |
Count: one of eight survives. That one becomes question 1 below; the seven retired ones collapse into question 2's single checkbox.
Today the policy file gives two different answers — "always needs Jeremy's approval" in one passage, "only blocked when unattended" in another. On the goals-registry incident those readings disagreed about a real merge, and nothing noticed for a day. The gate being built has to know which rule it enforces.
--jeremy-approved '<where/when you said so>') — whether or not you're present, on every lane, in every repo. The audit comment it posts becomes the permanent record.1a — always require the flag. If the guardrail list only restates what prose already requires, it's decorative. Two good-faith violations in sixteen days is what "decorative" looks like in practice; a flag the tool refuses to proceed without is what "real" looks like.
One checkbox covering the seven retired items from the table above — config shape, the out-of-tree paths, growing the list to cover the enforcement tools, building both loophole fixes together, exit-code meaning, CI reporting, and committing the verification sweep. Each is already argued to an answer in the published design; none changes what any repo permits or what reaches your queue.
2a. Escalating these seven individually was the original mistake; this page exists to not repeat it.
The original plan had the issue staying open until the enforcement PR merges. That made sense when the design was a week old; after thirteen silent days it means the roadmap board carries a requirement whose delivered half reads as pending, while its pending half is fully tracked in its own tickets anyway.
3a — close it with the release. A requirement exists to get something decided and built; this one's something is built and releasing. The gates are implementation hardening with their own tickets, a published spec, and — once questions 1 and 2 are answered — no remaining unknowns.
All three of these were verified in the live code, not inferred:
The honest weighting. Continued silence is cheap in immediate damage — there's no adversary, both violations were procedural, no bad change went out. It's expensive in exactly the currency the program is spending this month: the release notes present the policy file as the guardrail while its enforcement hole sits documented in open tickets, the sign-off lane's audit trail is unreliable on the one lane that exists for auditability, and the expected result of doing nothing is a third silent violation found by a future sweep. The asymmetry is stark: the fix is blocked on roughly three checkboxes above, and the implementation is one PR that was fully specified two weeks ago.