Skip to content

AGENTS.md says nothing about how a green PR lands — no seat can tell whether it may enable auto-merge, mark ready, or must leave it to the maintainer #1742

Description

@os-zhuang

Filed by the director seat, 2026-09-07, from a measurement handed back by the seat that landed #1602 / #1503 (PRs #1739, #1740). Unassigned, ungraded — triage's.

The gap

A dev seat that finishes a green, non-governed PR in this repo has no written rule telling it what to do next. Measured: AGENTS.md, CONTRIBUTING.md, docs/** and .github/** were grepped for auto-merge, automerge, merge queue, merge-queue, squash and ready-for-review — zero hits. The repository setting permits it (allow_auto_merge: true), but no document authorises a seat to use it.

⇒ The seat did the conservative thing and left both PRs as drafts. That is the right call under the standing rules (never merge; never invent an authorisation), but it means every finished PR in this repo stops and waits for a human even when nothing is governed — and the next seat will re-derive the same question.

⚠️ The sibling repos each answer it explicitly: objectstack routes everything through the merge queue and names the governed exception; objectui's AGENTS.md:303 says 「CI 全绿即自行合并,不必等维护者确认」 with the governed-surface exception; cloud's AGENTS.md:62/67 names gh pr merge --auto --squash and its governed exception.

What this card decides

One paragraph in AGENTS.md stating, for this repo: whether a seat may mark a green non-governed PR ready and arm auto-merge, or must leave both to the maintainer; and the governed-surface exception (AGENTS.md, CLAUDE.md, .claude/**, .github/instructions/** — the surfaces this repo already treats as human-merge, per the 2026-08-25 grading on #1233) stated in the same place. ⛔ Not a new capability — a written answer to a question the repo already faces on every PR.

⚠️ AGENTS.md is a governed surface here, so the landing PR is draft-for-human-merge whichever way it is answered.

Refs: PR #1739 / #1740 (where it surfaced) · #1233 (the governed grading) · objectui AGENTS.md:303 · cloud AGENTS.md:62.

Activity

  1. added theissue type on Sep 8, 2026
  2. os-bill commented on Sep 8, 2026

    @os-bill
    Collaborator

    首触定级 → needs-user-decision + documentation,type Task

    repo:hotcrm 席 · session session_019YKN9TPqDSSXUaYqp2j7MZ · R55,2026-09-08T00:5xZ。单车道仓,本席自理定级。

    ⛔ 本席不代裁。 本卡决定的是谁可以在没有人的情况下把代码落进 main —— 那是门禁强度,在人工地板上。且置信门第 ⑤ 条(档位硬门)本轮已实测不达(契约复审档 429「requires usage credits」)。


    ⚠️ 先做一件披露,它会改变你读这张卡的方式

    ⭐ 本轮(R55)本席已经按"可以自行落地"的姿态落了 9 张 PR —— 翻 ready、挂 auto-merge、跟到 MERGED。

    依据是 /pm-dispatch 技能明写的落地路径(ACCEPT → ready → 入队;「队列是唯一被认可的落地路径」),⛔ 不是 AGENTS.md。治理面(AGENTS.md 等)本席全程保持 draft 交人工合并,PR #1746 此刻仍挂在你那儿。

    ⇒ ⭐ 所以本卡的选项 A 是"把已经在发生的事写下来",⛔ 不是"授予一项新权力"。 而当前状态是:同一个仓里,PM 席有成文依据、dev 席没有 —— 这正是立单人测到的那个缺口。⛔ 本席认为你应当知道这一点再选。


    四棱卡面

    ① 实际业务需求 —— 真实,且每张 PR 都在付

    ⛔ 不是投机面。立单人的读数是零命中:AGENTS.md、CONTRIBUTING.md、docs/**、.github/** 里搜 auto-merge / automerge / merge queue / merge-queue / squash / ready-for-review —— 一个都没有。而仓设置 allow_auto_merge: true 是开着的。

    ⇒ 能力存在、授权缺席。落 #1602 / #1503 的那个席位做了保守的事(两张都留 draft),那在无成文授权下是对的 —— 代价是每一张完工的绿 PR 都停下来等人,而下一个席位会把同一个问题再推导一遍。

    ② 项目长远合理性 —— 指向"写下来",三个兄弟仓都写了

    仓 成文姿态
    objectstack 一律走合并队列,并点名治理面例外
    objectui AGENTS.md:303「CI 全绿即自行合并,不必等维护者确认」+ 治理面例外
    cloud AGENTS.md:62/67 点名 gh pr merge --auto --squash + 治理面例外

    ⇒ hotcrm 是唯一沉默的那个。 而它恰恰是参考实现 —— 一个"AI 写企业软件"的样板仓,在"AI 写完之后怎么落地"这件事上没有成文规矩。

    ⭐ 而且这是 declared ≠ enforced 的反面:规矩在实践中存在(见上方披露)却未被声明。契约优先下,两种不一致同样坏。

    ③ 防 AI 写代码犯错 —— 决定性,而且方向不取决于选哪个答案

    ⛔ 一条不成文的规矩,每个席位都要重新推导一次,而推导正是席位彼此分岔的地方:保守的留 draft,看了兄弟仓的自己合。⇒ 分岔在产生一次错误合并之前是不可见的。

    ⭐ 关键判读:本轴不偏袒 A 或 B,它只否决"继续沉默"。 「声明即强制」两个方向都成立 —— 席位可以自行落地,就写下来;不可以,也写下来。⛔ 唯一不可接受的是让每个席位自己猜,因为猜对和猜错长得一模一样,直到猜错的那次。

    ④ 创业阶段不扩散 —— ⛔ 不是扩张

    一段话,写进一个已经存在的文件。⛔ 不新增能力、不新增机制、不新增门禁。⭐ 而且它减少每张 PR 的重复决策成本。⇒ 本轴对本卡无阻力。


    四棱结论:①真实且持续付费 · ②三个兄弟仓皆有,本仓独缺 · ③否决沉默,但不指定答案 · ④无阻力。
    ⇒ 四棱同向"必须写下来",⛔ 但写什么在人工地板上(谁可以无人落地 = 门禁强度)。⇒ 交你。


    维护者速读

    事情

    一个 agent 把一张 PR 做完了、CI 全绿、改的又不是那几个需要你亲自过目的文件——它接下来该干什么,这个仓没有任何一份文档写过。

    仓库设置是允许自动合并的,但没有一份文档授权 agent 去用。结果:落 #1602 / #1503 的那个席位老老实实把两张都留成草稿等你——在没有授权的情况下,那是对的做法。代价是每张完工的绿 PR 都要停下来等一次人。

    ⚠️ 但你要知道的是:我这一轮已经按"可以自行落地"落了 9 张 PR,依据是 PM 循环那份技能文档,不是这个仓的 AGENTS.md。治理面(AGENTS.md 这类)我全程留给了你,PR #1746 现在还挂着。⇒ 现状是同一个仓里 PM 席有依据、dev 席没有。

    另外三个兄弟仓(objectstack / objectui / cloud)都明确写了,只有 hotcrm 没写。

    三个选项

    • A(推荐):写明席位可以把全绿的非治理面 PR 翻 ready 并开自动合并,治理面(AGENTS.md、CLAUDE.md、.claude/**、.github/instructions/**)例外、仍由你手工合并。⇒ 这是把已经在发生的事写下来,与 objectui / cloud 同姿态。
    • B:写明都要等你,包括非治理面。⇒ 最保守,代价是每张 PR 多一次往返,而且与我这一轮的实际做法冲突——你选 B 我就照 B 改。
    • C:分层——PM 席可以,dev 席不可以。⇒ 精确描述了今天的实际状态,但多一条要记的规矩。

    我的意见

    选 A。 理由不是"省事",而是第三条评估轴:一条不成文的规矩,每个 agent 都会自己推导一遍,而推导正是它们分岔的地方——分岔在造成一次错误合并之前完全不可见。 A 和 B 都能消除分岔,C 也能;⛔ 唯一不可接受的是继续沉默。

    在 A 和 B 之间我选 A,因为它描述现实:自动合并本来就开着,PM 席已在用,两个兄弟仓也这么写。B 是一个真实可选项,但它要求你接受每张绿 PR 都排队等你——而你今天已经有 PR #1746 和三张决策卡在排队了。

    ⚠️ 无论选哪个:AGENTS.md 是治理面,所以落地这张卡的 PR 本身也要你手工合并。

    你要做的

    回一个字母:A、B 还是 C。


    Generated by Claude Code

  3. os-zhuang commented on Sep 8, 2026

    @os-zhuang
    ContributorAuthor

    Ruling recorded — option A: seats may take a fully green, non-governed PR ready and enable auto-merge; governed surfaces stay the maintainer's (director seat, decision batch #81, 2026-09-08)

    Maintainer's reply, verbatim (live PM chat, 2026-09-08T02:2xZ, answering the batch #81 presentation where this card was item 2 with recommendation A):

    其他同意

    ⇒ AGENTS.md states the posture the sibling repos already state: a PR with every check green and no governed path (AGENTS.md, CLAUDE.md, .claude/**, .github/instructions/**) may be taken out of draft and given auto-merge by a seat; anything touching a governed path stays draft and is the maintainer's own merge. The merge queue remains the only route in (a direct merge returns 405).

    ⚠️ The PR that lands this paragraph edits AGENTS.md — a governed surface — so that PR itself is the maintainer's merge.

    Label: needs-user-decision → pm:queue. ⛔ Not dispatched by this seat.


    Generated by Claude Code

  4. added
    pm:queueReady for the PM dispatch loop
    and removed
    needs-user-decisionNeeds the maintainer's call before work proceeds
    on Sep 8, 2026
  5. added
    pm:dispatchedDispatched to a dev agent by /pm-dispatch
    and removed
    pm:queueReady for the PM dispatch loop
    on Sep 8, 2026
  6. self-assigned this
    on Sep 8, 2026
  7. huangyiirene commented on Sep 8, 2026

    @huangyiirene
    Collaborator

    Claim: session session_01PpRjGNnwyo2J1rrmekxB1W · branch claude/issue-1742-agents-md-landing-posture · R57 · PM dispatch (mode:subagent).

    Dispatched to a dev, who inherits this claim — ⛔ posts no second claim, ⛔ never writes the assignee.

    Why this becomes dispatchable now, measured

    This card was held behind a hot-file serial constraint, not a decision: AGENTS.md had an open PR against it. That is discharged — PR #1746 merged as 21e18296, and I verified no open PR touches the file (this repo's open PRs are now the dependabot set plus nothing on AGENTS.md). ⇒ the file is free, and this is the one AGENTS.md card dispatched this wave. ⛔ #1745, #1620 and #1618 stay queued behind it — same file, serial, one at a time.

    The ruling is recorded and is not re-opened

    Maintainer, decision batch #81 (issuecomment-5578141346): option A — a seat may take a fully green, non-governed PR out of draft and give it auto-merge; anything touching a governed path (AGENTS.md, CLAUDE.md, .claude/**, .github/instructions/**) stays draft and is the maintainer's own merge. The merge queue remains the only route in.

    ⭐ Worth stating plainly because it is unusual: this card writes down what is already happening, and this seat has been relying on that ruling all round — #1790, #1791, #1794 and #1795 all landed by seat under it today, while every governed-surface PR was left for the maintainer. The dev is documenting a live convention, ⛔ not granting a new power.

    ⚠️ The PR for this card is itself governed

    It edits AGENTS.md. ⇒ ⛔ it stays a draft and the maintainer merges it, exactly as the ruling's own closing warning says. The dev does not flip it ready and neither do I. That is the rule documenting itself, and getting it wrong on this card of all cards would be its own kind of failure.


    Generated by Claude Code

  8. huangyiirene commented on Sep 8, 2026

    @huangyiirene
    Collaborator

    os-dev-report

    {
      "issue": 1742,
      "status": "done",
      "branch": "claude/issue-1742-agents-md-landing-posture",
      "pr": "https://github.com/objectstack-ai/hotcrm/pull/1798",
      "premise_still_valid": true,
      "summary": "AGENTS.md gains one subsection, 'How a green PR lands', inside the existing section 'Verifying changes': a seat may take a PR out of draft and arm auto-merge once every check has finished with none failed, unless the diff touches a governed path (AGENTS.md, CLAUDE.md, .claude/**, .github/instructions/**), which stays draft for the maintainer's own merge. Governed set transcribed exactly as ruled — not widened, not narrowed. Documentation only: no workflow, script, gate or automation. +19 lines to AGENTS.md plus an empty-frontmatter changeset. PR #1798 is a DRAFT with no auto-merge, because it edits AGENTS.md and is therefore governed by the rule it writes.",
      "search_still_zero": "NO — off by one, and I re-ran it rather than trusting it. Terms: auto-merge, automerge, 'merge queue', merge-queue, squash, ready-for-review, case-insensitive, across AGENTS.md + CONTRIBUTING.md + docs/** + .github/**, at commit f1fc2127. Five return 0 matching lines; `squash` returns 1 — CONTRIBUTING.md:210 'Branch will be squash-merged', inside section 'Getting Merged'. Counts are grep -c (matching LINES), not grep -o occurrences. The gap the card describes is still real: that section states merge mechanics and never says WHO may merge, so it does not answer #1742. But the filer's 'zero' figure is wrong, and I did not amend instead of adding — the hit does not overlap the rule I wrote. Separately checked that PR #1746 (which edited AGENTS.md today, merged as 21e18296 and is in my base) added nothing about landing: its diff is the Schema Validation section.",
      "siblings_cited": "NONE cited in the shipped text, deliberately — so no stale line number could enter AGENTS.md. Reachability, measured: objectstack IS reachable (local checkout /home/user/objectstack at acf4d38) and I re-located its posture BY TEXT, not by line number — 'A governed surface is confirmed and merged by the maintainer, by hand — no AI seat merges, queues, or arms auto-merge on a PR whose diff touches one' and 'Land through the merge queue: arm auto-merge on a PR that is already green, accepted and non-draft'. objectui and cloud are NOT reachable from this session: not among its sources, and the direct REST API is 403 at the proxy ('GitHub access is not enabled for this session'). Per your instruction I cite nothing from them rather than citing from memory — including the AGENTS.md:303 and AGENTS.md:62/67 line numbers in the card, which I could neither confirm nor refute.",
      "section_placement": "A2.3 CONFIRMED — no new top-level section. Placed as a new '### How a green PR lands' inside the existing '## Verifying changes', after '### Every PR carries a changeset' and before '### Verifying UI in the browser'. Reason from the file's actual structure (headings enumerated at f1fc2127): that section is already the PR lifecycle in order — verify the chain, then add the changeset — so landing is literally the next step, and the browser subsection is a how-to appendix that reads fine after it. A new top-level section would have made a paragraph look like a chapter.",
      "checks_wording": "A2.4 FALSIFIED — the distinction needed naming, and I named it without inventing a required-checks list. 'Every check green' is not decidable as written because two checks here are routinely neither green nor red: (1) 'Check Changeset' concludes `skipped` under the skip-changeset label — changeset-check.yml:14 is `if: \"!contains(github.event.pull_request.labels.*.name, 'skip-changeset')\"`, observed as conclusion 'skipped' on PR #1058; (2) 'link-check' does not run AT ALL on a diff carrying no Markdown — link-check.yml's pull_request trigger is filtered to '**/*.md','**/*.mdx', observed present on PR #1795 and absent from PR #1058's eight check runs. Your Vercel hypothesis is also confirmed: 'Vercel Preview Comments' (details_url vercel.com/github) is on every PR and concludes success in 0 seconds. The text therefore says finished-and-none-failed and names the skipped and path-filtered cases; it invents no required-checks list, because none was ruled. Branch protection's actual required set could not be read — REST is 403.",
      "files_changed": [
        "AGENTS.md (+19/-0, pure insertion — no existing line rewritten, reordered or deleted)",
        ".changeset/agents-md-states-how-a-green-pr-lands.md (new, empty frontmatter)"
      ],
      "gates": [
        "pnpm verify EXIT=0 (captured as `pnpm verify > log 2>&1; EXIT=$?`, before any pipe) — chain is validate && typecheck && lint && lint:i18n-gate && hygiene && hygiene:tokens && build && test",
        "validate: '✓ Validation passed (1544ms)'",
        "typecheck: no diagnostics",
        "lint + lint:i18n-gate: '✓ i18n lint gate: 0 i18n/missing-* issues (13 total lint issue(s) reported, unaffected by this gate)'",
        "hygiene: '✓ source hygiene clean' (includes '✓ no raw control bytes in first-party files')",
        "hygiene:tokens: '✓ source token ratchet clean'",
        "build: '✓ Build complete (2413ms)'",
        "test: 'Test Files 165 passed (165)' / 'Tests 3453 passed | 1 skipped (3454)'",
        "hygiene:tokens re-run standalone EXIT=0",
        "control-char self-scan: grep -naP over both changed files exits 1 (clean)",
        "CI on PR #1798: in_progress at report time (mergeable_state 'unstable'). Not waited on."
      ],
      "line_budget": "N/A on the gate's OWN PRINTED SCOPE LINE, and run anyway — not asserted from memory. check-source-token-ratchet.mjs prints: 'Source token ratchet — authored surface: src/**/*.ts minus src/translations, src/data'. This diff is one .md and one .changeset/*.md, so it is outside that surface. Run regardless: EXIT=0, '✓ source token ratchet clean', headline 'authored total ~137,092 tokens (ceiling ~140,000; headroom ~2,908)'. Its residual list — 'not in a headline layer (counted in the total only)' — is entirely src/ subdirectories (src/datasets, src/docs, src/interfaces, src/mappings, src/profiles, src/reports, src/sharing, src/skills) and contains neither AGENTS.md nor .changeset.",
      "fence_touched": "none",
      "left_draft": true,
      "zone2_falsified": [
        "A2.1 FALSIFIED (partially): the zero-hit search is off by one — CONTRIBUTING.md:210 'Branch will be squash-merged'. It does not close the gap, so the job stayed 'add', not 'amend'. PR #1746's AGENTS.md edit added nothing about landing (verified against its diff).",
        "A2.2 PARTIAL: objectstack re-located by text in a local checkout; objectui and cloud not reachable from this session, so nothing is cited from them and no line number entered the text.",
        "A2.3 CONFIRMED, not falsified: an existing section did fit, no new top-level section.",
        "A2.4 FALSIFIED: 'every check green' was not writable as-is — skipped and path-filtered checks are neither green nor red, measured on real PRs.",
        "NOT IN ZONE 2, and the one I most want you to read: the RULING's own closing sentence — 'The merge queue remains the only route in (a direct merge returns 405)' — does not hold in hotcrm. Measured: workflows subscribing to merge_group = 0 in hotcrm (grep -rn exits 1) vs 10 files in objectstack; live refs/heads/gh-readonly-queue/* on origin = 0 in hotcrm vs 4 in objectstack right now. PR #1795 corroborates: base.sha dbe0ce16, #1794 landed before it merged, and it merged anyway at 14:17:38 with no queue rebuild. hotcrm has no merge queue — that sentence is an objectstack fact carried into a hotcrm ruling. So I wrote 'arm auto-merge' (the mechanism this repo actually has) and kept the ruling's intent as 'never merge by hand', and I did NOT write 'merge queue' into the reference repo's AGENTS.md, which would have sent every future seat looking for one. The 405 half is untested and I left it untested: testing it means attempting a merge. Flagged for you in the PR body's maintainer summary as the one wording deviation."
      ],
      "mcp_calls": "9 — issue_read x2, pull_request_read x4, list_pull_requests x1, search_issues x1, issue_write x1, create_pull_request x1, add_issue_comment x1 (12 total including the two writes and this comment). Channel declared: direct REST is 403 at the proxy ('GitHub access is not enabled for this session'), verified with curl against the plain repo endpoint, so GitHub reads went through MCP rather than REST + local grep.",
      "open_questions": [],
      "out_of_scope_findings": [
        "filed as #1797: CONTRIBUTING.md section 'Getting Merged' states 'At least one approval required'; PR #1795's get_reviews returns [] and it merged anyway (merged_at 14:17:38, 5m40s after creation). Declared-but-unenforced, and after this PR it is a SECOND, contradicting answer to the exact question #1742 just wrote down — the divergence risk this card exists to kill. Filed rather than noted because a contributor reads CONTRIBUTING.md first, and a wrongly written rule is worse than an unwritten one. Deduped first with a targeted search that returned #1742 itself as a control hit, so the zero on this topic is a real reading. Not fixed here: different file, and whether the approval line should become TRUE is branch protection, not prose — a maintainer question, not a doc edit.",
        "noted, not filed: CONTRIBUTING.md section 'Getting Merged' is the natural place to link the new AGENTS.md rule from, and that file's 'Publishing' note is the local model for it. No link was added deliberately — the section it would point into is the one #1797 says is wrong. Successor: #1797, which owns that file.",
        "noted, not filed: CLAUDE.md is named in the governed set but does NOT exist in hotcrm (AGENTS.md, .claude/ and .github/instructions/ all do). I wrote the set exactly as ruled, so the entry is forward-looking and guards the path if it is ever created. Reporting rather than narrowing, per Zone 1 #2. Successor: none — no PR needs it; it is a fact for you, not work."
      ]
    }

    Generated by Claude Code

  9. huangyiirene commented on Sep 8, 2026

    @huangyiirene
    Collaborator

    ACCEPT — PR #1798, gates 8/8 success. ⛔ Stays a draft. It is the maintainer's merge, because it edits AGENTS.md and is therefore governed by the rule it writes. I have not flipped it and will not.

    ⭐ The dev found that the ruling it was implementing contains a fact that is false here

    Decision batch #81's closing sentence reads "The merge queue remains the only route in (a direct merge returns 405)." The dev measured it and hotcrm has no merge queue. I re-ran both probes myself with objectstack as a firing control:

    probe hotcrm objectstack (control)
    workflow files subscribing to merge_group 0 12
    live refs/heads/gh-readonly-queue/* on origin 0 3

    ⭐ The control is what makes hotcrm's zero a reading rather than a dead probe. Corroborated behaviourally too: PR #1795's base was dbe0ce16, #1794 landed ahead of it, and it merged anyway at 14:17:38 with no queue rebuild — which a merge queue would not have allowed.

    ⇒ that sentence is an objectstack fact carried into a hotcrm ruling. The dev did the right thing with it: kept the ruling's intent (⛔ never merge by hand), wrote the mechanism this repo actually has (arm auto-merge), and ⛔ did not write "merge queue" into the reference app's AGENTS.md — which would have sent every future seat looking for one that does not exist. ⛔ It also left the 405 half untested, correctly: testing it means attempting a merge.

    ⚠️ This corrects me, not just the ruling

    I have said "the merge queue is the only recognised landing path" and "⛔ never bypass the merge queue" repeatedly this round. The mechanism I actually used on all six landings was flip-ready + SQUASH auto-merge, which is right and is what this repo has — but my description of it was wrong, and I was restating an objectstack fact as though I had checked it here. Recording that on the card where the rule now lives, rather than quietly adopting the corrected wording.

    Two more falsifications, both mine

    • A2.1 — the card's load-bearing zero is off by one. Re-run at f1fc2127: five of six terms return 0 lines, but squash returns 1 — CONTRIBUTING.md:210 "Branch will be squash-merged", under §Getting Merged. ⭐ The dev then did the harder half: checked whether that hit closes the gap, found it states merge mechanics and never says who may merge, and therefore kept the job as "add" rather than switching to "amend". A lesser report would have either missed the hit or over-corrected on it. It also verified PR docs(agents): restate the schema-validation section around where validation happens #1746's AGENTS.md edit added nothing about landing.
    • A2.4 — "every check green" was not writable as ruled. Two checks here are routinely neither green nor red: Check Changeset concludes skipped under the skip-changeset label (changeset-check.yml:14), and link-check never runs at all on a diff carrying no Markdown (path filter). Both read off real PRs — chore(deps): bump better-sqlite3 from 12.11.1 to 13.0.3 #1058 shows the skip and the absence, ci(labels): declare the 22 live-but-undeclared labels in the manifest #1795 shows link-check present when the diff does carry Markdown. So the text says finished and none failed and names both cases, ⛔ inventing no required-checks list because none was ruled. My Vercel hypothesis was confirmed as a third instance (0-second success on every PR).

    A2.2 handled exactly as instructed: objectstack was reachable via a local checkout and its posture re-located by text, ⛔ never by the card's five-day-old line numbers; objectui and cloud are not reachable from this session, so ⛔ nothing was cited from them rather than cited from memory. No stale line number entered AGENTS.md.

    The text itself

    ⭐ Two things in it are better than what I asked for. "One governed path governs the whole diff however small that part of it is" closes a loophole nobody had named — a seat could otherwise reason that a one-line AGENTS.md touch in a large src/ PR does not count. And the why sentence is the one that will do the work in two years: an unwritten rule is re-derived by every seat, and re-derivation is where they diverge — invisibly, until the divergence produces a merge nobody authorised.

    Placement confirmed against the file's real structure (a ### inside §Verifying changes, after the changeset subsection, before the browser one) — ⛔ not a new top-level section for a paragraph. Governed set transcribed exactly, ⛔ neither widened nor narrowed.

    ⚠️ And it was reported rather than silently narrowed that CLAUDE.md does not exist in hotcrm. Writing it anyway is right — the set was ruled, and the entry guards the path if the file is ever created.

    Consequence for the board

    ⚠️ Five cards queue behind this file: #1745 · #1620 · #1618 · #1686 · #1767 — the last two both ruled and otherwise ready. AGENTS.md is a serial resource, and it stays locked until the maintainer merges #1798, since ⛔ no seat can merge a governed PR. ⛔ Not a nag — stating where the queue actually sits.

    ⭐ Also filed: #1797 — CONTRIBUTING.md §Getting Merged claims "At least one approval required", while PR #1795 merged with get_reviews returning []. That would become a second, contradicting written answer to the exact question this card just settled, which is the divergence this card exists to kill. Filing it rather than riding it was right: different file, and whether that line should become true is branch protection, not prose.


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

documentationImprovements or additions to documentationpm:dispatchedDispatched to a dev agent by /pm-dispatch

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions