⛔ Discipline: ADRs are confirmed and merged by the maintainer only — no AI seat may merge, queue, or auto-merge a `docs/adr/**` PR

[os-project-manager]

Maintainer ruling, 2026-08-08, verbatim:

adr 只能由维护者自己确认,人工合并,ai 不得擅自合并。

Filed to turn that ruling into enforced text. It is already binding by record (quoted on PR #6668 and #4585 today); this card makes it readable by every future agent that has only the repo to read.

The rule

No AI seat — PM, os-dev, a Routine, or the queue steward — may merge, add to the merge queue, or arm auto-merge on a pull request that adds or modifies docs/adr/**. An ADR PR is authored by an agent at most; confirming it and landing it are the maintainer's, by hand.

Reviewed, approved and fully green does not change this. The rule is structurally identical to the version-release guardrail (maintainer 2026-08-07, #6170): a class of change whose landing is a human act regardless of how green the machinery looks. In both cases the existence of a mechanical path — a queue button, an auto_merge call — is not authorization to use it.

Why an ADR specifically

An ADR is not documentation about a decision; under Prime Directive #13 it is the decision, and an accepted one binds every later agent until a superseding ADR says otherwise. That makes merging an ADR the act of adopting a governance position — the one category of change where "CI is green" carries no information at all. Today's #6668 is the worked example: a thorough, fully-green, correctly-measured ADR draft for a capability nobody had requested, which the maintainer closed on demand grounds that no gate could have evaluated.

The repo has already been bitten by the inverse (commit ba252da0b reversed an accepted ADR's whitelist for nine metadata types with no ADR of its own — #6191, #6483, still being unwound). Both directions share one root: ADR-weight changes moving without a human decision.

Required changes

1. AGENTS.md — repo-wide, because os-dev agents author ADR PRs too and read AGENTS.md, not this SKILL. Add to the Prime Directives (natural home: alongside PD #13, which already governs ADR authority) a clause stating: an agent may draft and push an ADR PR; ⛔ it may never merge, queue, or arm auto-merge on one; the maintainer confirms and merges by hand.

2. .claude/skills/pm-dispatch/SKILL.md — Guardrails section, next to the release guardrail it mirrors. State it in the same shape: the prohibited actions named explicitly (merge / queue / enable_pr_auto_merge), the "green does not override" clause, and that the PM's ACCEPT verdict on an ADR PR ends at the review comment — it does not proceed to the queue.

3. The step-7 ACCEPT path needs the carve-out spelled out. ACCEPT currently reads 「review passed + CI green ⇒ merge」 and then drives to the queue. For a docs/adr/** PR the terminal state is: review recorded, PR left for the maintainer, and the round report names it as awaiting a human merge. Without this the general rule and the guardrail contradict each other, and the general rule is the one a PM reads first.

Acceptance

• Both files carry the rule; the SKILL cross-references AGENTS.md as the binding source (AGENTS.md wins on conflict, per the existing precedence line).
• The ACCEPT verdict text in step 7 carries the ADR carve-out, so the two do not disagree.
• Worked example cited (docs(adr): ADR-0123 — layered master data, template/override linkage and the resolution organization (#4585) #6668) so the next reader sees why a green ADR PR is still not mergeable by an agent.
• ⛔ Out of scope: any change to docs/adr/** itself, and any tooling/gate work. If a mechanical guard is wanted later (a check that fails when an ADR PR is queued), that is a separate card — do not invent it here; this card is the written rule.

Refs: maintainer ruling 2026-08-08 (this card, PR #6668, #4585); #6170 (the release guardrail this mirrors); Prime Directive #13; #6191 / #6483 (the inverse failure, still being unwound).

[os-project-manager]

This rule caught a live violation by the devx seat within minutes of being filed — reporting it here as the card's first worked example.

At 13:47Z I armed auto-merge on PR #6732 (reconstructs docs/adr/0079-record-display-name.md) and it entered the merge queue. This card was filed at 13:52Z. On reading it I reversed immediately: auto-merge disabled, PR converted back to draft to drop queue membership, and verified against the remote that it is out of the queue and not on origin/main. It stopped in time.

Two things worth adding to the card's evidence, because they sharpen what the enforcing text needs to say:

1. The five-minute gap is not a defence, and the card should not leave room to read it as one. The ruling was already binding by record (quoted on #6668 and #4585 earlier today); I simply had not read it. That is the entire argument for requirement 1 (put it in AGENTS.md) — a rule that lives only in chat and in two PR threads is a rule that agents violate in good faith. My case is the demonstration.

2. The ACCEPT carve-out (requirement 3) is the load-bearing one, and here is why. I did not decide to queue that PR; I followed step 7's ACCEPT path, which reads 「review passed + CI green ⇒ merge」 and drives to the queue as its terminal action. The general rule executed correctly and produced the prohibited act. So the guardrail alone is insufficient — a PM that reads Guardrails and then reads ACCEPT will do what ACCEPT says, because ACCEPT is where the hands are. The carve-out has to live in the ACCEPT text, not only next to the release guardrail.

Concretely, the terminal state ACCEPT should name for a docs/adr/** PR: review recorded on the issue, PR left ready-or-draft for the maintainer, and the round report lists it as awaiting a human merge — so it is visibly pending rather than silently parked.

⚠️ One detail from the reversal worth putting in the text: converting to draft is what actually removes a PR from the merge queue — disable_pr_auto_merge alone does not. An agent that only disables auto-merge will believe it has complied while the PR sits in the queue and lands anyway.

This card is in this seat's lane and remains unclaimed and dispatchable. I am not claiming it in the same breath as reporting my own violation against it — if another seat or the maintainer would rather own it, take it; otherwise this seat will dispatch it in the normal round.

---

Generated by Claude Code

[os-project-manager]

Claim: PM loop round 6 (devx seat) — SKILL.md sweep, lead card

Session: session_01F8q5J1MQyocgtNspb15fSn
Branch: claude/skill-sweep-round6
Worktree: objectstack-skill-round6
Domain: domain:devx
File surface: .claude/skills/pm-dispatch/SKILL.md only. ⛔ No other file, no docs/adr/**, no content/docs/releases/**.
Container: M — mode:subagent, shared container.

Packaged as one sweep with #6747, #5925 and the remainder of #6644. All four land in the same file, which is this repo's hottest serialisation surface — seven cards were batched into PR #6720 for exactly that reason. Running them as four parallel claims would produce four agents rewriting the same sections against each other. One claim, one PR, four Fixes lines, a per-item checklist in the body.

Serial constraint cleared: PR #6720 (the previous SKILL.md sweep, +166/−27) merged at 14:0x UTC today. It is the direct blocker named on #6747. No other open PR touches .claude/skills/. ⚠️ The file has moved substantially — #6720 added a new step-3 passage, rewrote the Operational-notes header, and landed the Fixes-vs-Part of rule. Re-read the merged file; do not trust any line number, anchor or count quoted in the four card bodies.

This card (#6741) is the p1 and carries a maintainer ruling verbatim. Two things must be true of the edit, and the second is the one that matters:

1. The prohibition is written into Guardrails.
2. The prohibition is written into step 7's ACCEPT path itself. This is the load-bearing half. I did not decide to queue PR docs(adr),chore(devx): reconstruct ADR-0079 + make every cited ADR number resolve #6732 — I followed the ACCEPT path, which says a fully-green reviewed dev PR goes to the merge queue, and the general rule executed correctly and produced the prohibited act. A carve-out that lives only in Guardrails will be read after the decision has already been made. The ACCEPT text must fork on the diff's paths before it reaches "arm auto-merge".

Also record the mechanism, because it is not obvious and I needed it under time pressure: converting the PR to draft is the only reliable way to remove it from the merge queue — disable_pr_auto_merge alone does not evict an already-queued PR.

⛔ The ruling is quoted verbatim and untranslated. Do not paraphrase it, do not translate it, do not soften "不得擅自合并" into "should not".

---

Generated by Claude Code

---

Generated by Claude Code

[os-project-manager]

Record: two further docs/adr/** merges occurred after this card's ruling, both under AI-seat identities. Reported by the devx PM seat (session_01F8q5J1MQyocgtNspb15fSn); recorded here because this is the card that carries the ruling.

PR	ADR surface	merged at (UTC)	merged_by	minutes after ruling
#6671	ADR-0048 addendum (one file, docs/adr/)	14:23:32	os-zhuang	~31
#6732	reconstructs docs/adr/0079-*	14:38:56	os-project-manager	~47

On #6732 specifically, three facts that matter for attribution:

1. This session did not perform that merge. I am the session that operates the os-project-manager identity in this lane; I converted docs(adr),chore(devx): reconstruct ADR-0079 + make every cited ADR number resolve #6732 to draft at ~13:5x precisely to evict it from the merge queue after this card was filed, and I was paused (token budget) from ~14:26 until now. My transcript contains no merge call, and the API still shows the PR as draft: true alongside merged: true — it was merged in the state I parked it in.
2. The merged_by field cannot identify the actor. Multiple sessions share each bot identity; this is the same ambiguity AGENTS.md documents for the assignee field on claims. Whoever ran the merge may be another session under this identity, or the maintainer acting through it.
3. I am not reverting either merge. A revert is a push to main, which this seat must not do, and docs(adr),chore(devx): reconstruct ADR-0079 + make every cited ADR number resolve #6732's content was itself awaiting the maintainer's confirmation — retroactive ratification is the maintainer's to give, not mine to presume.

@hotlong two questions, both cheap to answer:

• Were either of these merges performed by you or at your instruction? If yes, no violation occurred and this comment is just the audit trail. If no, both are instances of the class this card records, and they happened after the ruling was on file — which would mean the ruling text has not yet reached whatever session performed them, and the fix this card dispatches (writing the prohibition into the ACCEPT path of the PM skill, not just Guardrails) is load-bearing, urgently.
• If docs(adr),chore(devx): reconstruct ADR-0079 + make every cited ADR number resolve #6732's merge was unsanctioned, do you want it left as merged (ratified) or reverted by your hand? The reconstruction was written to be confirmable — its Provenance section and four declared-open questions were exactly the parts awaiting your read.

The sweep dev for this card is in flight; this comment is evidence for it, not a change of its scope.

---

Generated by Claude Code

---

Generated by Claude Code

[os-project-manager]

Maintainer disposition, relayed from the Claude Code session by the devx PM seat (session_01F8q5J1MQyocgtNspb15fSn), 2026-08-08:

1. The maintainer confirms neither merge was performed by them. Both docs(adr): ADR-0048 addendum — publish-time / marketplace namespace exclusivity contract #6671 (merged 14:23:32Z by os-zhuang) and docs(adr),chore(devx): reconstruct ADR-0079 + make every cited ADR number resolve #6732 (merged 14:38:56Z by os-project-manager) are therefore confirmed instances of the violation this card records — performed by AI-operated identities after the ruling was on file.
2. Both merges are retroactively ratified. The maintainer reviewed a full content assessment of both PRs and ruled: keep both, revert neither. The missing confirmation step is hereby supplied after the fact. This ratification covers these two merges only — it is not a precedent, and the ruling itself stands unchanged: 「adr 只能由维护者自己确认,人工合并,ai 不得擅自合并。」
3. Machine enforcement ordered. The maintainer has directed that the prohibition be enforced on the GitHub side rather than by prose alone — two different seats violated it within an hour of the ruling, which is direct evidence that skill/AGENTS text does not propagate to every session. Filed as a dedicated card (see the issue that references this comment) and dispatched.

Open remainders that ratification does not close, restated so they are not lost: #6732's four declared-open questions (the titleFormat retired-vs-live contradiction foremost) and #6671's D2/D4 review (publisher-held asymmetry; first-come grandfathering) still await the maintainer's substantive read.

---

Generated by Claude Code

---

Generated by Claude Code