Repository navigation
chore(pm-dispatch): tooling cap per dispatch round, pm-rule cards on the maintainer's naming, two round-report readings, spec key lands with its first reader (D3 = A, D5 = A) - #25795
Conversation
…y on the maintainer's naming, two round-report readings; a new spec key lands with its first reader Maintainer rulings D3 = A and D5 = A, written into the pm-dispatch rule text. Every touched file stays at or under its line-ratchet ceiling; new lines are paid by deleting restated content in the same file. Claude-Session: https://claude.ai/code/session_01Fx58tcuqmi5bveQGdRYq8r Co-authored-by: Claude <noreply@anthropic.com>
Contract reviewServed-tier: Inputs read: card #25768 body and all three comments (triage 6396195056, claim 6397358483, os-dev-report 6397638451), PR body, file list, net diff, and the 44 check-runs on ① Derived judgmentsRuling fidelity — D3 = A (card body, bullet by bullet)
Ruling fidelity — D5 = A
Deleted or densified lines — does the rule still live?
Ratchet (read from the head tree, not re-run): line counts SKILL.md 319/319, cross-repo 51/51, execution-duties 188/188, filing-gate 67/68, lanes/ui 38/38, seat-lifecycle 96/96 against Gate verdicts (check-runs on the head): 26 success including Governed Surface Queue Guard, Lint · PM dispatch-gates, Lint · repo & tooling gates, Check Changeset, the three claim-parity checks; 18 skipped (UI, docs, matrix shards — no path hit); 0 failure. ② Semver levelNo package touched; ③ Boundary flags
Implemented-by: VERDICT: FAIL One item: D5's 「replaces rule 2's spec/后端先行 ordering for new keys」 is not carried by the rule text; L27/L28/L30 of |
…st ordering from the ui/ cutover, and is the key/reader exception to never-same-batch Contract review FAIL item 1 on the D5 line: the rule text now carries the supersession the ruling spells, paid inside the line and the never-same-batch line; no ceiling moved. Claude-Session: https://claude.ai/code/session_01Fx58tcuqmi5bveQGdRYq8r Co-authored-by: Claude <noreply@anthropic.com>
Contract reviewServed-tier: Re-review of the prior record (issuecomment 6397710959, 2026-10-25T12:35Z, head ① Derived judgmentsWhat moved between the heads — verified, not taken from the dev's claim
FAIL item 1 of the prior record — D5's supersession, now carried
D3 = A — carried from the prior record, undisturbed (files unchanged between heads)
Deleted or densified lines — carried, undisturbed: the four deletions ( Ratchet (read from the head tree against Gate verdicts (check-runs on ② Semver levelNo package touched; ③ Boundary flags
Implemented-by: VERDICT: PASS The one FAIL item of 6397710959 is cured on Reviewed 2026-10-25T12:46Z · reads only, no local re-run |
席位核对 · ACCEPT ·
|
Requested by Leehom · project thread
Fixes #25768
Clause-②: no
Metadata-protocol: none
Writes the maintainer's rulings D3 = A and D5 = A into the pm-dispatch rule text.
.claude/**only (Tier S); no package, no changeset (skip-changeset), no gate and no script.The ruling (verbatim, untranslated)
Tesla, 2026-10-25T09:23Z, director thread, answering the assessment's option lists:
"其他同意" = D3 A and D5 A as the card spells them. Triage record 6396195056: the cap is reported, not enforced (「不做门禁」). D4 and the npm dist-tag card are out of scope here.
What changed, rule by rule (each rule has one home)
toolingper dispatch round, overflow stays in backlog, no gatereferences/execution-duties.md〈候选与批次〉, right under the candidate linetoolinglabel gains a readerSKILL.mdlabel glossary rowreferences/filing-gate.md〈立卡门〉, under ③references/seat-lifecycle.md〈座位贴协议〉references/seat-lifecycle.md〈轮次报告与节奏〉.claude/,AGENTS.md,scripts/pm, gate scripts,.github/workflowsplannedrow alone; hotcrm readers use the same merge batch; effective onceui/exists onmainreferences/cross-repo-coordination.mdrule 2ui/onmain— absent on0790d0a4), and until then rule 2's spec/后端先行 standsLine budget (ratchet: paid by deletion, no ceiling raised)
SKILL.mdexecution-duties.mdpr_create带assignees: [LOGIN],同笔指派;席位自有 PR 指派自己」: the dev half isos-dev.mdrule 2 verbatim (and this file's own 「无条件条款只住角色文件」), the seat half follows from the line above it (「PR assignee = 卡的」; a seat's card names the seat as assignee)filing-gate.mdcheck-skill-line-ratchet.mjsis outside this card's file surfaceseat-lifecycle.mdSKILL.mdalready carries (「④ 轮次报告单列 awaiting a human merge」); the freed bytes carry the follow-up-PR readingcross-repo-coordination.mdpnpm objectui:refresh回流」, which AGENTS.md (Frontend section) carries;lanes/ui.md's pointer moves from this file to AGENTS.md in placelanes/ui.mdCorpus total over the six files: 759 → 759. No re-wrap: every freed line or byte comes from deleted text, named above.
Gates (local, at
da43591c)Re-derived on the rework head
da43591c(cross-repo-coordination.md L28/L30 only): same 20 families, all 20 exit 0,--ranreconcile 20 run, 0 NOT-MEASURED. The first round below ran at51664dd2.Derived with
node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack; each run with its exit captured before any pipe; reconciled with--ran:✓ dispatch-gates --ran: 20 derived famil(ies) accounted for — 20 run, 0 NOT-MEASURED.All 20 exit 0, among them
pnpm check:pm-skill-ratchet,pnpm check:pm-skill-id-lint(87 file(s) clean),pnpm check:skill-frame-sync,pnpm check:pm-governed-merges,pnpm check:pm-governed-prose,pnpm check:nul-bytes,pnpm check:doc-authoring. A first pass beforepnpm installanswered exit 3 (PREREQUISITE NOT MET) on eight families and exit 1 withERR_MODULE_NOT_FOUNDoncheck:pm-expected-skips(nothing measured); after install onlycheck:doc-formula-expressionsstill answered 3, until@objectstack/formulaand@objectstack/lintwere built. Every family was re-run and recorded 0. CI runs the full set on the PR.Acceptance notes
references/lanes/skills.mdpoints 「fold-or-serial 必答与家族派发五门」 at 「SKILL.md 批次独立性段」, but both live inreferences/execution-duties.md〈候选与批次〉. A stale pointer; carrier: none; not filed.lanes/hotcrm.md(a hotcrm reader unlocks on PUBLISHED, not merged) and rule 2'sBlocked-by:/ never-same-batch lines. The new line is inert untilui/exists onmain, so nothing conflicts today; the reading to adopt at cutover is an open question in the report.维护者速读(草稿)
改了什么:把 D3、D5 两条裁决写进 pm-dispatch 技能。D3:每轮派发里工具类卡最多占一成,超出的留在积压;改动 pm 规则的卡只有你点名才立;每轮报告多报两个数(产品提交占比、落地后 48 小时内的跟进 PR 数)。D5:objectui 并入本仓(
main上出现ui/)之后,新的 spec 键必须和它的第一个读者同一个 PR 落地,hotcrm 的读者走同一合并批,不再出现只声明没人读的planned行。为什么改:过去 14 天 17% 的合入提交在服务流程本身,新卡里三成多是工具/技能/流程;一个 spec 键曾拖成四个 PR、三次落地。这两条把精力拉回产品。
风险与代价(含回滚):不加门禁、不加脚本,只改规则文字,六个文件行数都不超上限。风险在解读:一成上限在一轮只派 1–3 张卡时按字面会变成零;hotcrm 依赖已发布的包,「同合并批」要在并仓时再定义。回滚 = revert 本 PR。
席位意见:
你要做的:无需操作;小轮次的一成怎么算、hotcrm 同合并批的含义,席位会在需要时单独请你裁。
Generated by Claude Code