Filed by the repo:hotcrm PM seat on behalf of the #1188 dev, which found it and could not file it: that seat gets HTTP 403 from api.github.com and its dispatch contract forbids the MCP issue tools for the dedupe read that must precede filing. It reported instead of filing blind or withholding, which was the right call. Dedupe search run here before filing: no existing card covers it (#1188 and #1282 are the two siblings, both closed by this round's PRs).
The drift
test/sharing-coverage.test.ts:580-583, in the comment above the crm_campaign row of the object-label table:
// zh-Hans is 「营销活动」, the label the locale pack ships (`zh-CN.ts`
// `objects.crm_campaign.label`) and the word the other 14 zh-Hans doc pages
// already used. This row read 「市场活动」 until #830, which left the master
// spelled one way and the detail below spelled the other on the same page.
crm_campaign: { en: 'Campaign', 'zh-Hans': '营销活动', 'zh-Hant': '行銷活動' },Measured on origin/main @ cd198f10, independently by the dev and re-run by this seat:
67 total .zh-Hans.mdx pages under content/docs ← control term: the search reached the corpus
21 of them contain 营销活动
0 contain 市场活动 (the pre-#830 spelling the sentence contrasts against)
The comment says 14. It is 21. Same class as #1188 (the "15 lookups on sys_user" figure) and #1282 (the "eight authored records" figure) — a counted fact stated in prose with no producer and nothing checking it.
⚠️ This one differs from its two siblings in the way that matters
#1188's integer was correct on the day it was found (15, by coincidence — #1181 removing crm_account.renewal_owner happened to bring it back). #1282's was wrong by one and the file contradicted itself two hundred lines later.
This one is wrong by seven and nothing in the file disagrees with it. There is no internal contradiction to trip over, so it reads as a measurement to every subsequent reader — which is exactly the failure mode the class produces. It is the strongest of the three arguments that the number itself is the defect, not its current value.
Fix direction — same ruling as #1188 and #1282: delete the numeral, do not pin it
The sentence's load-bearing claim is:
「营销活动」 is the label the locale pack ships (zh-CN.ts objects.crm_campaign.label) and the word the zh-Hans doc pages already use.
That is complete and correct without any count, and it is stronger: a universal cannot be falsified by the next page someone writes. Both halves of it have real producers — the locale pack is a file, and "the docs already use it" is checkable by grep at any time.
⛔ Do not add a guard that counts the pages and asserts the integer. That creates one more hand-maintained number and merely puts a lock on it; ADR-0049 axis ③ is against it — an author editing that integer changes nothing a user sees, and the guard would only convert silent drift into red on every new zh-Hans page.
⚠️ The second half of the comment ("This row read 「市场活动」 until #830, which left the master spelled one way and the detail below spelled the other on the same page") is history with a producer — the #830 PR — and should stay. The measurement above confirms it discharged cleanly: 0 pages still carry the old spelling.
Scope
One file, one sentence: test/sharing-coverage.test.ts ~:581, the numeral only. The table row itself, the assertions, and the #810 comment below it are all out of scope.
⚠️ Fence note for whoever picks this up: test/sharing-coverage.test.ts is not in #1307's six-file list, so it is free once that card lands. It is also the 6th-largest file in the scanned trees (66,068 B, 64.5% of the byte cap) — see the sibling card filed alongside this one; ⛔ do not grow it.
Related
Filed by the
repo:hotcrmPM seat on behalf of the #1188 dev, which found it and could not file it: that seat gets HTTP 403 fromapi.github.comand its dispatch contract forbids the MCP issue tools for the dedupe read that must precede filing. It reported instead of filing blind or withholding, which was the right call. Dedupe search run here before filing: no existing card covers it (#1188 and #1282 are the two siblings, both closed by this round's PRs).The drift
test/sharing-coverage.test.ts:580-583, in the comment above thecrm_campaignrow of the object-label table:Measured on
origin/main@cd198f10, independently by the dev and re-run by this seat:The comment says 14. It is 21. Same class as #1188 (the "15 lookups on
sys_user" figure) and #1282 (the "eight authored records" figure) — a counted fact stated in prose with no producer and nothing checking it.#1188's integer was correct on the day it was found (15, by coincidence — #1181 removing
crm_account.renewal_ownerhappened to bring it back). #1282's was wrong by one and the file contradicted itself two hundred lines later.This one is wrong by seven and nothing in the file disagrees with it. There is no internal contradiction to trip over, so it reads as a measurement to every subsequent reader — which is exactly the failure mode the class produces. It is the strongest of the three arguments that the number itself is the defect, not its current value.
Fix direction — same ruling as #1188 and #1282: delete the numeral, do not pin it
The sentence's load-bearing claim is:
That is complete and correct without any count, and it is stronger: a universal cannot be falsified by the next page someone writes. Both halves of it have real producers — the locale pack is a file, and "the docs already use it" is checkable by grep at any time.
⛔ Do not add a guard that counts the pages and asserts the integer. That creates one more hand-maintained number and merely puts a lock on it; ADR-0049 axis ③ is against it — an author editing that integer changes nothing a user sees, and the guard would only convert silent drift into red on every new zh-Hans page.
Scope
One file, one sentence:
test/sharing-coverage.test.ts~:581, the numeral only. The table row itself, the assertions, and the#810comment below it are all out of scope.test/sharing-coverage.test.tsis not in #1307's six-file list, so it is free once that card lands. It is also the 6th-largest file in the scanned trees (66,068 B, 64.5% of the byte cap) — see the sibling card filed alongside this one; ⛔ do not grow it.Related
sys_user" figure in twoevent_attendeecomments has no guard, and had already drifted to 16 #1188 / PR docs(event-attendee): state the sys_user cascade rationale as a universal, not a count #1308 — "15 lookups onsys_user", the card whose dev found thisforecast-seeds.test.tssays "these eight authored records" where the seed holds seven — in the one file whose job is to state the seed's invariants exactly #1282 / PR test(forecast): drop the seed count from the period_label guard's prose #1309 — "eight authored records", same family, same rounddescription/docs, and file upstream cards for every hand-copied platform constraint #1184 — comment slimming; this class is a subset of what that card sweeps