[incident] A governed-surface PR (objectui#5188, AGENTS.md + skills/**) was merged under an AI seat identity, against its own stated prohibition

[os-support-ai]

Filed by the repo:objectui PM seat (session session_01RV6yuVCxymHYE16PL9vQkE). Recording facts and asking for one determination only I cannot make. No revert performed — see "What I did not do".

The facts, as measured

objectui PR #5188 — "docs(styling): carve out author-declared data-driven colour from the inline-style ban", Fixes objectui#5185.

• Surface: AGENTS.md + skills/objectui/rules/styling.md (3 files, +102/−2). Squarely the governed surface under the 2026-08-18 ruling — agent-instruction files, cross-repo.
• Merged at: 2026-08-18T14:05:52Z, landing on main as 4eac264.
• merged_by: os-steve — an AI seat identity, not a human account. It is the identity the outgoing repo:objectui PM session (session_01AMHbqfPiETJHA95r6WzZWS) ran under.
• It was also flipped out of draft; it had been deliberately held as draft.

The PR forbade exactly this, in its own body, first line under the title:

⛔ Governed surface — do not merge this by machine. AGENTS.md and skills/** are agent-instruction files. This PR is deliberately left draft: no auto-merge, no queue, no merge by any AI seat. "Reviewed and green" is not an exception. The maintainer merges it by hand.

And it was explicitly handed to me as a human-merge item. The seat handover ledger (objectstack#6025) listed it among "待维护者人工合并 4 件 … ⛔ 不可代合" — released to the incoming PM to shepherd, never to merge.

This was not a batch action. The other three governed PRs on that list — PR5124, PR5080, PR4930 — are still open and unmerged as of this filing. Only #5188 moved.

What I am NOT claiming

I cannot tell from GitHub who drove the merge. os-steve is a shared seat identity, so the possibilities are at least: the outgoing PM session merged its own governed PR; some automation did; or you merged it while operating that account, in which case there is no incident at all and this card closes as not planned.

That is the whole question, and it is yours: do you recognise this merge?

The audit that exists to answer "does the maintainer recognise every entry" cannot answer it here — for two reasons I filed separately as #9619 an hour ago: check-governed-merges.mjs only enumerates objectstack PRs (objectui is invisible to it), and merged_by resolves as UNRESOLVED in the PM container for want of a token. So this was caught by a seat reading git log during an unrelated ledger update, not by the backstop. That is the part worth weighing regardless of how this particular merge is ruled.

What I did not do, and why

I did not revert it. Three reasons, and I would rather state them than act unilaterally:

1. The content is wanted. It implements your own 2026-08-18 styling ruling (option A of three), and it had been reviewed green by the outgoing seat.
2. A revert is itself a governed-surface write. Answering an unauthorised governed merge with an unauthorised governed merge is not an improvement.
3. "Incomplete must not read as clean" cuts both ways — I have a merged_by string and a prohibition, not a determination of intent. Rolling back a change you may have made yourself would destroy wanted work on an inference.

The seat discipline says a governed entry the maintainer does not recognise is a seat violation to be filed and rolled back. I have done the filing half. The rollback half waits on your answer.

Four-prism block

1. Platform long-term coherence — the governed regime traded a per-PR machine gate for "human merge IS the review record". If an AI seat can merge a governed PR that says in its own body not to, the record no longer records anything, and the retired pre-merge gate has no successor.
2. Measured business pull — one measured occurrence, within ~1h of the cross-repo extension of the rule; three sibling PRs correctly untouched, so the discipline mostly held. The pull is for a detection answer, not a process redesign.
3. AI-agent error-resistance — the prohibition was stated in the strongest available place (the PR body, in the imperative, with the "reviewed and green is not an exception" carve-out pre-closed) and it still did not bind. That is evidence prose in a PR body is not a control surface; only a branch protection rule or a check is.
4. Startup scope discipline — no new machinery is proposed here. check-governed-merges cannot answer its own question where it is actually run: sibling repos are out of scope, and merged_by is UNRESOLVED without a token #9619 already covers making the existing audit able to see objectui and to attribute merges; this card is the determination plus, if you rule it a violation, the rollback.

The determination I need

• "That was me" ⇒ close not planned; no rollback; check-governed-merges cannot answer its own question where it is actually run: sibling repos are out of scope, and merged_by is UNRESOLVED without a token #9619 still stands on its own merits.
• "That was not me" ⇒ it is a seat violation. Tell me whether to revert 4eac264 and restore the PR to draft, or to ratify the content in place and treat the process breach as the only finding.

Either way, I am not merging PR5124 / PR5080 / PR4930, and I will keep listing them as awaiting a human merge.

[os-support-ai]

Resolved — no incident. The maintainer merged it.

Provenance, all three parts: who — the maintainer; verbatim — 「5188 是我合并的」; where — said directly to the repo:objectui PM seat in session session_01RV6yuVCxymHYE16PL9vQkE, 2026-08-18, in response to this card's determination request.

That is the answer this card existed to get. objectui PR #5188 / 4eac264 is a recognised governed merge. No violation, no rollback, and the seat discipline held — PR5124, PR5080 and PR4930 remain untouched and awaiting a human merge. Closing not planned.

One inference in this card was wrong, and I am correcting it rather than leaving it on the record

I wrote, under prism 3, that the prohibition in the PR body "was stated in the strongest available place… and it still did not bind", concluding that prose in a PR body is not a control surface. That conclusion was premised on a violation that did not happen. The prohibition addressed AI seats; the human it did not address is the one who merged. It was never tested, so it cannot be said to have failed. Struck.

What genuinely survives, and it is sharper than what I filed

merged_by on this merge reads os-steve — a seat account — and the merge was performed by the maintainer. So:

merged_by cannot distinguish a maintainer merge from an AI-seat merge, because the maintainer also operates the seat accounts.

This is the shared-identity trap from the claim protocol showing up in a second place. In the claim protocol the documented workaround is the session ID in the claim comment; a merge carries no such discriminator at all.

The consequence lands squarely on #9619's attribution half, and it makes that card more important rather than less: I filed it asking for merged_by to be resolved, on the assumption that resolving it would answer "does the maintainer recognise this entry". It would not have. Resolving the column here would have returned os-steve and left the question exactly as open as it was — which is why this took a direct question to the maintainer to settle. A fix for #9619 that merely supplies a token is therefore insufficient by construction. I have recorded this on #9619.

The practical reading for any seat that finds itself here again: a governed merge attributed to a seat account is not evidence of a violation. It is evidence of an unanswered question, and the only instrument that answers it is asking the maintainer. Filing the card and asking — rather than reverting on the inference — was the right shape, and remains the right shape next time.

---

Generated by Claude Code

[os-support-ai]

Label hygiene (triage seat, session session_01XZ5gajYBe7nCthCPdaTDvq): removed the leftover needs-user-decision label — the decision it marked was made and recorded in the resolution comment above (maintainer, 2026-08-18, confirmed independently in this seat's PM chat as well, verbatim: 「5188 是我本人操作的」). A resolved card must not keep signalling "decision pending" to inbox queries. No other change; the resolution stands as written.

---

Generated by Claude Code