Two follow-ups in `docs-view-rosters.test.ts` after #1347: `entryCount()` counts a prose bullet as a roster entry (a latent false red), and the docstring still lists the #1318 defect as a shape to tolerate

[os-trump]

Filed by the repo:hotcrm PM seat on behalf of the #1326 dev. Both were correctly left untouched there — that card's rule was "this card only adds", and its PR is literally 154 insertions, 0 deletions. Dedupe search run: no existing card.

⛔ Do not start before PR #1347 merges — same file. Two items, one card, because they are the same file: filing two would force a serial constraint on one small file for no benefit. ⚠️ They are not a family — different defect forms, different fixes — so each has its own ruling and its own acceptance below.

---

Item 1 — entryCount() counts a prose bullet as a roster entry (latent false red)

The structural rule requires each translated face to carry the same number of roster entries as its English page. entryCount() counts bolded top-level bullets as entries alongside table rows.

On content/docs/sales/accounts.mdx the roster section runs past a ### subsection whose bullet reads:

- **Health Score** is maintained by hand by whoever owns the relationship

⇒ That is a prose explanation, not a roster entry, and it is counted. entryCount is 7 (6 table rows + 1 prose bullet) on the English face — and 7 on .zh-Hans and .zh-Hant too.

⚠️ Why it is a defect even though it is green

It passes only because all three faces happen to word that sentence in parallel. A translator who rewords it so it no longer opens with a bold turns the structural guard red — with a message reading "6 roster entr(y|ies), but … has 7", blaming roster drift for a prose edit.

⇒ A guard that goes red for a reason it does not name is worse than one that misses: it sends the next person to look for a roster problem that does not exist. ⚠️ And it is latent — nothing goes red today, so nothing will surface it until a translator touches an unrelated sentence.

Ruling (⛔ not re-litigable): bound the count to actual roster entries. Two routes, ⛔ no ruling between them — decide on the real code and say which and why:

1. Bound entryCount() to the section body up to the first ### heading.
2. Count table rows only.

⚠️ Route 2 is simpler but changes what the rule covers on any page that legitimately expresses a roster as a bullet list. Check for such a page before choosing it — service/knowledge-base was a bullet-list roster in #1324's surface, so this is not hypothetical.

Acceptance for item 1

⭐ Reverse-verify the false red, since that is the whole defect: reword the accounts.mdx English bullet so it no longer opens with a bold, confirm the structural rule goes red on main today, then confirm it stays green under the fix. ⛔ A green run after the fix proves nothing on its own — it is green now.

Prove the mutation on disk by blob hash before reading any verdict; restore with git checkout HEAD -- PATH (⛔ the bare form restores from the index), proved by an empty git diff HEAD.

---

Item 2 — the docstring still presents the #1318 defect as a shape to tolerate

:48's tolerance list reads, unqualified, as though "TAB labels in the first column where the view name is in a later one" is a legitimate roster shape.

It is not — it was the #1318 defect, and PR #1347's new rule now rejects exactly that shape.

⭐ The #1326 dev added a qualifying section beneath it rather than rewriting the paragraph, because its card forbade anything but additions. ⇒ Correct then, and it leaves the original list intact — so a reader who stops at the original list is still being told to step over the defect.

Ruling: reword the original tolerance entry so it names that shape as the defect PR #1347 now catches, rather than as something to accommodate. ⛔ Do not delete the tolerance list — the other entries are real and load-bearing. ⛔ Do not weaken the new rule to match the old prose.

Acceptance for item 2

The :48 list no longer presents the TAB-label shape as tolerable, and the qualifying section added by #1347 is folded in rather than left as a contradicting addendum. ⚠️ Read both before editing — the point is that the file stops saying two different things about one shape.

---

⛔ Scope

test/docs-view-rosters.test.ts only. ⛔ Do not touch content/docs/** — if either item surfaces a genuine docs defect, report it; that is a card, not a rider. ⛔ Do not extend anything to the translated faces' view-label column — that is open decision card #1329.

Related

• No gate can see a docs roster whose name column is entirely invented — docs-view-rosters runs 4/4 green against the full #1318 defect, by construction #1326 / PR test(docs): hold the roster name column to the view labels the app ships #1347 — the name-column rule; both items are its declared leftovers
• #760 published to customers: six docs pages print a "Tab" column of strings the console never renders, and one asserts the false model in prose before tabulating it eight times #1318 / PR docs: print the view label a tab actually shows, not the inert tabs[].name #1322 · #760 is still published on six more pages: the same non-existent tab names survive in service/index, sla-and-escalation, knowledge-base, quick-tour, reports and accounts — one of them as a bullet list no table search can reach #1324 / PR docs(tabs): name each tab by the view label it actually renders #1330 — the defect the tolerance entry describes
• [Decision] Should a Chinese docs page spell a view name in English or in its zh-CN translation? Five pages split two ways today, and no guard can be written until this is settled #1329 — [Decision] the translated faces' label language, ⛔ still open