finding(pm-dispatch): the new timestamped-reading rule has no gate and nothing in the round-open sequence re-reads the skill — its first live test was violated 12 minutes after it landed

[huangyiirene]

Filed unassigned by the triage seat (R+118). Recording + measurement only — ⛔ no severity asserted, no fix chosen. ⛔ Self-implicating: the violation measured below is my own. Per this seat's standing practice I file the facts and ⛔ recuse from grading it — no priority, no domain, no recommendation from me.

The rule

PR #14784 (commit 1596b4c58, merged 2026-09-03T07:48:45Z) added to .claude/skills/pm-dispatch/SKILL.md:166-171, on maintainer ruling 2026-09-02, verbatim 「其他同意」:

同为成立条件 —— 板面/树/队列读数自带取数时刻：写进认领、派发令、复核、轮次报告、座位贴段落的读数恒带 UTC 时间戳（形如 2026-03T00:21Z），树读数另带 ref 或 tip；无时间戳的读数是格式错误不是现值，读者按未取处理 —— 改的是键入什么，不是要记住什么。

and beside it the remediation-shape ranking:

PM 侧失效的修法按序取：(a) 删掉容许出错的构造 → (b) 让正确形态成为协议唯一拼写 → (c) 加一条要记住的检查；(c) 型屡复发、(a) 型守住 —— 占位符禁令与本条取数时刻皆 (a) 型。

The measurement

Reading taken 2026-09-03T10:37:51Z, tree origin/main 431979e:

1. git grep -rln "取数时刻|timestamped reading|UTC 时间戳" -- scripts/ .github/ → 0 files. There is no gate.
2. git grep -rn "取数时刻" over the whole tree → 2 hits, both SKILL.md:166 and :171. The rule exists in exactly one place: the prose a seat is expected to have read.

The first live test, and it failed

This seat opened R+118 at 2026-09-03T10:25:34Z — 2h37m after the rule landed on main, with the text already on origin/main. The round-open marker (objectstack#6015, comment 5524293471, posted 2026-09-03T10:31Z) states a board reading as a table:

| finding box, OPEN | count |
| objectstack | 2 |
| objectui | 92 |

⛔ No timestamp. Under the rule as written that reading is malformed, and a reader must treat it as untaken — in the very artefact the rule names first ("轮次报告"、"座位贴段落").

I did not find the rule by reading the skill. I found it through the governed-merge audit, at the end of the same round, because PR #14784 touched .claude/** and therefore printed as a governed entry. Had the change touched a non-governed path, this seat would have finished the round without ever learning the rule existed.

The observation, stated narrowly

⛔ Not a claim that the rule is wrong, and ⛔ not a claim it is mis-classified — the ranking's own note calls it (a)-type, and declaring an untimestamped reading malformed rather than merely incomplete is a real (a)-shaped move: it removes the construct's validity rather than asking anyone to remember something.

The narrow fact is about delivery, not the rule: a protocol change to a standing seat's own governing file reaches that seat only when it next re-reads the file, and nothing in the round-open sequence causes a re-read. The mutual-exclusion four-reads that every round does perform read the seat post, not the skill. So the interval between "rule lands" and "seat obeys it" is unbounded, and its actual first value here was "never, within the round" — recovered only by an audit that happened to cover the path.

⇒ Under the ranking the rule itself records, "the seat should remember to re-read the skill" would be a (c)-type answer to that delivery gap, and (c) 型屡复发.

What I did NOT measure

• ⛔ Whether other PM seats picked the rule up this round. I read no other seat's round reports; this is one seat's data point, not a population.
• ⛔ Whether a gate is even feasible. The readings the rule governs are free prose in issue comments, and I did not look for whether any existing gate reads comment bodies at all.
• ⛔ Whether .claude/skills/** changes already trigger a notification path I am simply not on.

Related

#14784 (the PR that landed the rule) · #14867 (governed-audit scope: an unconfigured repo produces no row at all — same family: the audit is how this seat learns things, and its coverage bounds what can be learned) · #13562 (a maintainer-ruled archive whose "intentional" state is invisible on the label face — the same delivery-versus-state distinction).

[huangyiirene]

Facts from R+120 — ⛔ recused, no recommendation. This is my own card; per this seat's standing practice I record measurements on it and ⛔ do not grade it, prioritise it, or propose the fix.

The R+119 data point: the remedy I tried, and how it failed

R+119 ran a bespoke round-open grep over .claude/skills/pm-dispatch/ at 11:34:57Z → 1 hit. The governed audit at 11:39:09Z, same round, returned 4 governed merges — three of which touched governance surfaces the grep did not cover (#14855 CLAUDE.md; #14862 .claude/agents/ + skills/objectstack-pm-dispatch/; #14819 skills/objectstack-ai/). Of those, the first two are seat-governing; #14819 is not.

The R+120 measurement

Widened the round-open read to CLAUDE.md AGENTS.md .claude/ skills/, both repos, at 12:36:19Z → 0 hits.

⚠️ Zero-hit control, since a zero proves nothing alone: the identical command over the previous window (431979e67cc4..b3a63d32c9a0) returns 4 commits — d355c36, 7b19b9e, 365141f, 5290fcb. The control fired, so the widened command reaches the class and the zero is real.

The governed audit at 12:40:20Z then reported a clean window: 0 governed merges, 2/2 audited, topological. ⇒ The two channels agreed for the first time.

⭐ Three measured facts about the relationship between the two channels

1 — The audit's governed-surface class contains the whole freshness class. The surface labels the audit prints for governance entries are CLAUDE.md, .claude/** and skills/** (observed on #14855, #14862, #14856, #14819 in the R+119 run). Those are exactly the paths the widened round-open read covers. ⇒ For this class the two reads are not independent evidence; the audit subsumes the grep.

2 — The audit covered a strictly longer window than my freshness read, in the same round. At 12:36:19Z origin/main was ca3fd4b; by the 12:40:20Z audit it was e560b4d, 8 commits further on. My freshness read ran over b3a63d32c9a0..ca3fd4b and therefore did not cover ca3fd4b..e560b4d. The audit ran over b3a63d32c9a0..e560b4d and reported zero across all of it. ⇒ In this round the freshness read was the weaker of the two, and its zero was the less complete one.

3 — But the audit runs after the work, and the grep runs before it. In R+119 the audit did surface all four, and it surfaced them at 11:39:09Z — after the round's grading was already done. The R+118 sequence was the same shape: the audit found #14784 at the end of a round whose open marker had already violated it.

⇒ Stated without inference: for the governed-surface class, the complete read exists and already runs every round; what differs between the two channels is when in the round they run, not what they can see.

⛔ What I am not doing

I am not proposing which channel should move, nor whether either should. Under the ranking recorded at SKILL.md:166-171 — (a) 删构造 → (b) 唯一拼写 → (c) 加一条要记住的检查 — the R+119 remedy was a (c) and it behaved like one, failing on its first outing. Whether facts 1–3 point at an (a) or a (b) is a judgement about my own failure and ⛔ is not mine to make.

⚠️ One thing the facts above do not establish: whether the governed-surface list is itself complete for "files that bind a PM seat". AGENTS.md is in my round-open read but I have not observed it in an audit surface label, so I cannot say whether a lone AGENTS.md change would print as a governed entry. ⛔ Not measured, ⛔ not assumed either way.

---

Generated by Claude Code

[huangyiirene]

⛔ Correcting a fact I recorded here at R+120 — still recused, still no recommendation.

What I wrote, and why it was wrong

At R+120 I recorded as fact ①:

The surface labels the audit prints for governance entries are CLAUDE.md, .claude/** and skills/** … Those are exactly the paths the widened round-open read covers. ⇒ For this class the two reads are not independent evidence; the audit subsumes the grep.

⛔ The word "exactly" was wrong, and it was wrong in the direction that matters. I generalised a surface class from four observed entries (#14855, #14862, #14856, #14819) — the same "a sample is not a census" error this seat has now made three times on three different objects (R+118 the finding box, R+119 the pm:retriage label, here the surface class).

The measurement — audit run 2026-09-03T16:07:34Z, window 4b4d5a331593..5bc2f2727aef

Five governed entries, and two of them carry a surface label outside the three I named:

PR	surface
#14860	.claude/** ×4
#14808	.claude/** ×1
#14737	skills/** ×4
#14277	docs/adr/** ×35
#14498	docs/adr/** ×1

⇒ docs/adr/** is a governed surface. My round-open freshness read is git log … -- CLAUDE.md AGENTS.md .claude/ skills/, so it does not cover it.

Why this is not a cosmetic gap for a PM seat

ADRs are load-bearing for this seat's own output, not background material. In this session alone I have cited ADR-0089 as the deciding evidence on objectui#7455 (it puts the boolean visible explicitly out of scope, which is why option A there extends a direction an accepted ADR scoped against) and ADR-0049 on objectui#6910 and #7516. A ruling I write can turn on an ADR's text.

⇒ And #14277's own title is "migrate rotted ADR line anchors to resolver-gated symbol anchors" — 35 ADR files changed in one merge. A seat quoting an ADR by line anchor across that boundary would quote the wrong line and not know it.

⚠️ ⛔ Two things I did not establish, so they stay open rather than assumed:

1. Whether the governed-surface class has further members I still have not observed. Five entries is a bigger sample than four; it is not a census either. The authoritative answer is in scripts/pm/check-governed-merges.mjs's own surface definition, which I have not read. ⇒ ⛔ Do not treat "the four I have now seen" as the list.
2. Whether AGENTS.md — which my read does cover — prints as a governed surface. Still unobserved, as noted at R+120.

What stands from R+120, and what does not

• Fact ① (subsumption) — ⛔ withdrawn as stated. The audit does not merely subsume the grep; the two cover different sets, and the grep is missing a member the audit has.
• Fact ② (the audit covered a longer window) — stands, and did again this round.
• Fact ③ (the audit runs after the work) — stands, and was realised concretely at R+121: docs(pm-dispatch): X0 quote policy — date pointers for non-operative maintainer quotations (item 2 of the skills batch, ruling B) #14911 landed 23 minutes after a correct, complete freshness read and reached me only at the closing audit, after four decision cards were written.

⇒ Restated as one measured sentence: neither channel is a superset of the other. The grep runs early and misses docs/adr/** and anything landing mid-round; the audit sees the full surface class but only at the end.

⛔ I am not proposing which channel changes, nor widening my own read as a fix — a fourth narrower guess by me is the (c) again, and this correction is itself evidence that my guesses about the surface class are not reliable. The authority is the script's surface definition, and reading it against my round-open command is the measurement someone other than me should make.

---

Generated by Claude Code

[huangyiirene]

R+123 — the scope half of this card is now MEASURED, not guessed. ⛔ Still recused; facts only, no recommendation.

I read the authority instead of sampling it

At R+122 I withdrew my "the surface class is exactly these three" fact and wrote that the authoritative answer "is in scripts/pm/check-governed-merges.mjs's surface definition, which I have not read." Read it this round.

scripts/pm/check-governed-merges.mjs:641, origin/main 6392b9c, read 2026-09-03T17:05:39Z — GOVERNED_SURFACES is Object.freeze([…]) with exactly five entries:

id	matcher	what
adr	prefix docs/adr/	architecture decision records
claude-tree	prefix .claude/	the agent instruction tree (skills, agents, hooks, settings)
skills-catalog	prefix skills/	the published skills catalog
agents-md	exact AGENTS.md	the repo-root agent instruction file
claude-md	exact CLAUDE.md	the repo-root Claude instruction file

Both open questions from R+120/R+122 are answered

① "Are there further members I have not observed?" → No. Five, frozen. My round-open read is now -- CLAUDE.md AGENTS.md .claude/ skills/ docs/adr/, which is exactly all five. ⇒ As of this round the freshness read covers the complete governed-surface class.

② "Does AGENTS.md print as a governed surface?" → Yes — id: 'agents-md', and note it is an exact match, not a prefix. Same for CLAUDE.md. ⇒ A file like docs/AGENTS.md or a nested CLAUDE.md would not match those two rows. ⛔ I did not check whether any such nested file exists; recording the matcher shape, not a claim about the tree.

What this does to the three facts on this card

• Fact ① — restored, in corrected form. At R+120 I claimed subsumption from a four-entry sample and it was wrong; at R+122 I withdrew it. Measured against the frozen list, the freshness read and the audit now cover the same surface class. ⇒ Subsumption holds after all, but it holds because the read was widened to match a definition I finally looked at — ⛔ not because my original generalisation was sound. The reasoning was invalid even where the conclusion is now true.
• Fact ② — stands (the audit's window is longer; it was again this round).
• Fact ③ — stands, and is now the ONLY residual gap. The freshness read runs before the work; the audit runs after. R+121 is the worked example: a correct, complete freshness read at 13:39:58Z, docs(pm-dispatch): X0 quote policy — date pointers for non-operative maintainer quotations (item 2 of the skills batch, ruling B) #14911 landing at 14:02:35Z, and the seat learning of it at the 15:05Z audit — after four decision cards.

⇒ Restated with the guesswork removed: the two channels see the same five surfaces. What separates them is only when they run. Everything I previously attributed to a scope difference was my own incomplete read.

⚠️ One thing this does NOT settle

GOVERNED_SURFACES defines what the audit reports. ⛔ It does not follow that those five are the only files that can bind a PM seat — that is a different question, and this card is not evidence either way on it. I measured the audit's class, not the set of things that can change my instructions.

---

Generated by Claude Code