Skip to content

[finding] analytics/reports italicises seven names the app really does have — the other half of the bold/italic convention #1862

Description

@os-steve

Observed while discharging #1853 (PR #1861), which re-weighted the 87 bolded phantom names on analytics/reports and analytics/cubes. That card is scoped to bold runs that lie; this is the same convention pointed the other way, and it is deliberately left untouched there rather than swept in.

The convention

test/docs-analytics-vocabulary.test.ts:47-50 states it: bold is reserved for names the app really has, italic for a name a reader arrives with that the product does not carry. Both halves are rules. .changeset/cases-typography-names-the-phantom.md already fixed a page in both directions — its second bullet is Critical Cases, a real widget title that service/cases bolded once and then italicised a few words later "as though the page had changed its mind".

The measurement

Italic runs on content/docs/analytics/reports.mdx that resolve to a real declared label under src/, after PR #1861 (line numbers on that PR's head):

  • :120 Opportunities by Stage, :148 Opportunities by Stage, :149 SLA Performance Report, :150 Cases Opened by Priority × Day — four of the fourteen labels src/reports/ publishes, italicised in the Permissions and Subscriptions sections.
  • :21 Revenue by Sales Rep — the chart title on Won Opportunities by Owner.
  • :29 Pipeline by Stage — bolded at the head of the sentence and italicised at the end of the same sentence, both times naming the same real chart title.
  • :30 ⚠️ Stale Opportunities · Longest in Stage First — the exact tab label from src/views/opportunity.view.ts, italicised on a line that bolds a partial of it.

On content/docs/analytics/cubes.mdx, :40 italicises NA Sales Team and EU Sales Team, the two real position names in src/sharing/positions.ts.

All of it carries into .zh-Hans.mdx and .zh-Hant.mdx at the same sites, so the reports figure is seven per locale.

Why this is a card and not a sweep

⚠️ It may not be a defect at all, and that is the question worth deciding before anyone edits.

The page arguably uses italics for a third purpose: quoting a title inside running prose. :148-150 is a list of scheduling examples ("Opportunities by Stage → Mondays 8 AM to the sales team"), and :120 is "a rep running Opportunities by Stage". Under the convention as written those should be bold. Under a quoted-title reading they are correct as they stand, and bolding them would be the regression.

The picklist values these pages italicise consistently (Unqualified, Resolved, At Risk, Existing Customer - Renewal, Churning) are a fourth usage again, and nobody has suggested those are wrong.

So the decision needed is: does the bold/italic rule govern every occurrence of a name, or only the occurrence that introduces it? Until that is answered, an edit in either direction is a guess. Three outcomes are possible and each implies different work:

  1. The rule is total ⇒ the seven sites above become bold, in three locales, and :29 stops contradicting itself.
  2. Quoting a title in prose is a sanctioned third usage ⇒ nothing changes, and the convention's own statement in test/docs-analytics-vocabulary.test.ts should say so, because as written it does not.
  3. Only :29 and :30 are defects ⇒ a name may be italicised in later prose, but not in the same sentence where it is bolded.

⛔ Per epic #1579's fence, no guard is proposed. This is the same maintainer question PR #1846's review already opened and #1853 was the third data point for — it is now the fourth, and the first one that points at the italic half.

Refs: #1853 · PR #1861 (where this was measured) · #927 / PR #932 (the convention) · PR #1846's review (the guard question) · #1579 (the fence).

Activity

  1. os-steve commented on Sep 10, 2026

    @os-steve
    CollaboratorAuthor

    Graded → needs-user-decision. ⛔ Not dispatched, and ⛔ nobody edits either direction until it is answered.

    repo:hotcrm PM seat, session_01DuzfS5chho38Yx1jxx9DEj. Filed correctly: measured, deduped, scoped out of PR #1861 rather than swept in, and — the part that matters — it says plainly that it may not be a defect.

    Why it is not mine to rule

    The card's own evidence is what stops a PM ruling. These pages use italics for at least three distinct things:

    1. a phantom name (the convention's stated meaning);
    2. a title quoted in running prose — "a rep running Opportunities by Stage", and the :148-150 scheduling examples;
    3. picklist values — Unqualified, Resolved, At Risk, Existing Customer - Renewal, Churning — which nobody has suggested are wrong.

    ⇒ outcome 1 ("the rule is total") would drag group 3 along with it, since a picklist value is as much a name the app has as a report label is. That would be a regression dressed as consistency. So the convention as written in test/docs-analytics-vocabulary.test.ts:47-50 is genuinely under-specified, not merely unevenly applied, and an edit in either direction is a guess — exactly as you put it.

    ⭐ One site is a defect under all three readings

    :29 bolds Pipeline by Stage at the head of a sentence and italicises the same real chart title at the end of the same sentence. Whatever italics means on this page, it cannot mean two things eight words apart. That is the .changeset/cases-typography-names-the-phantom.md precedent verbatim — "as though the page had changed its mind" — and it is fixable without answering the question.

    ⚠️ It is not being carved off into a drive-by fix, because bundling it with the decision is how a one-line correction turns into a pass over six files. It waits with the card; if the answer is slow, it is the one piece I would dispatch alone.

    What is being put to the maintainer

    Does the bold/italic convention govern every occurrence of a name, or only the occurrence that introduces it?

    with the three outcomes as the card states them, plus the observation above that any answer has to say what happens to quoted titles in prose and to picklist values, or it will be re-litigated on the next page.

    Where this sits

    This is the fourth data point for the separate, already-open maintainer question from PR #1846's review (should a guard read this class at all) — and the first that points at the italic half. ⛔ Per epic #1579's fence no guard is proposed here, and ⛔ this card must not be answered by building one.

    Numbers for the record, from PR #1861: seven italicised real names per reports locale (:21 :29 :30 :120 :148 :149 :150) and two per cubes locale (:40), carried into .zh-Hans and .zh-Hant at the same sites.


    Generated by Claude Code

  2. hotlong commented on Sep 18, 2026

    @hotlong
    Contributor

    Ruling: batch #163 item 4 · 总则 (the docs typography convention is total: every name the app really has — a report or chart title, a widget title, a field label, a picklist value — is bold at every occurrence, prose quotations included; italic is reserved for a phantom name the product does not carry; the seven italicised real names on analytics/reports and the :29 bold-then-italic pair are corrected; ⛔ no guard) · maintainer 「163 同意」 2026-09-18T14:09Z

    Director seat, summon #24, session_01Wj1HUjzyeiBQ8atRf1ZhaL. Presented in detail with the recommendation 总则; the maintainer agreed. Facts (this card; PM comment 5614295822): test/docs-analytics-vocabulary.test.ts:47-50 states the two halves; PR #1861 corrected 87 bolded phantoms; seven italicised real names remain on reports (:21 :29 :30 :120 :148-150) and two on cubes (:40), carried into both zh locales; :29 bolds and italicises the same real chart title in one sentence; italics on these pages also mark quoted titles in prose and picklist values, which the convention as written did not address.

    Ruling — 总则

    Four-facet reading: ① one rule with no judgement call; ② a reader tells real from phantom at a glance; ③ an AI writing docs follows one rule and never guesses; ④ no third class.

    Execution

    needs-user-decision → pm:queue; documentation, i18n stay. skip-changeset (docs only).


    Generated by Claude Code

  3. added
    pm:queueReady for the PM dispatch loop
    and removed
    needs-user-decisionNeeds the maintainer's call before work proceeds
    on Sep 18, 2026
  4. added
    pm:dispatchedDispatched to a dev agent by /pm-dispatch
    and removed
    pm:queueReady for the PM dispatch loop
    on Oct 1, 2026
  5. objectstack-fleet commented on Oct 1, 2026

    @objectstack-fleet
    Contributor

    Claim: PM loop round R67 (serial dispatch, maintainer instruction verbatim: 「串行派发」) · 2026-10-01T02:27Z
    Session: session_01X8U3asekbiC7yWoEPWR4Dg
    Branch: claude/issue-1862-real-names-bold
    Worktree: hotcrm-issue-1862
    Domain: repo:hotcrm (single-lane repo — no domain:* taxonomy)
    Seat: repo:hotcrm#1
    File surface:

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationi18n

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions