`leads.mdx:103` puts a view "on the Leads tab" — both names are real, but Leads is a sidebar entry and not a tab, in all three locales

[os-trump]

Filed by the repo:hotcrm PM seat on behalf of the #1324 dev, which found it while sweeping every tab-word line in content/docs and could not file it (HTTP 403 from api.github.com). Graded at filing under this seat's standing finding first-touch authority (maintainer 2026-08-20) — see the grading note at the bottom.

⚠️ This is deliberately NOT the #760 defect, and that distinction is the point

content/docs/sales/leads.mdx:103
  Work them from the **Suspected Duplicates** view on the Leads tab
content/docs/sales/leads.zh-Hans.mdx:103   在线索页签的……视图里
content/docs/sales/leads.zh-Hant.mdx:103   在潛在客戶頁籤的……視圖裡

Both names are real. Suspected Duplicates is src/views/lead.view.ts:449, and Leads is a genuine sidebar item. ⇒ Nothing here names a string the console cannot render, so #1324's dev correctly left it untouched rather than sweeping it into a fix for a different defect.

What is actually wrong

The surface word. Leads is a sidebar entry, not a tab, and the sentence places a view "on" it. A reader following it looks for a tab row that is not there — the same wrong mental model #760 produced, arrived at from the opposite direction: not a fictional name, but a real name given the wrong kind of surface.

Scope

Three files, one line each. Rewrite so the sentence names the surface correctly — the view is reached from the Leads list's view switcher, not from a tab on a sidebar item.

⚠️ Re-derive the correct phrasing from how the other pages now word it — PR #1322 and PR #1330 established the house form across ten pages in this family. ⛔ Do not invent a third phrasing.

⛔ Do not touch src/views/** — both names are correct at source. ⛔ Do not decide #1329 (which language a Chinese page spells view names in); keep each face's existing convention.

Acceptance

The three lines name the surface correctly and agree with each other. pnpm verify green.

⚠️ Check whether test/docs-quick-tour-navigation.test.ts-style bold rules apply to this page before bolding anything — #1324 discovered that page-specific bold conventions exist and are enforced (bold reserved for real navigation labels, italics for retired names). ⛔ Do not assume leads.mdx is unguarded; measure.

Grading note

Graded pm:queue at filing rather than left as an ungraded finding. Premise re-measured on origin/main @ a76b69f by the reporting dev, with both names resolved to source. It is a real, user-reachable inaccuracy in shipped docs, the fix is three lines with an established house phrasing, and the lane keeps finding at 0. ⚠️ Axis ④ (创业阶段不扩散需求) argues for keeping it small — ⛔ this is a wording fix, not a licence to re-audit surface vocabulary across the corpus.

Related

• #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 sweep that found it; ⛔ correctly excluded it as a different defect
• #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 · closing_this_quarter 的切换器页签标题写作 "Closing Soon" —— 与 label / 四个语言包的第四个拼法,且 tabs[].label 没有翻译位 #760 — the fictional-name family this is not a member of

[os-sales]

Claim: PM loop round R31
Session: session_019hUuCQStzXGMFSX4dzww5t
Branch: claude/issue-1332-leads-is-a-sidebar-entry-not-a-tab
Worktree: hotcrm-issue-1332
Domain: repo:hotcrm execution seat (single-lane repo — ⛔ no domain:*)
File surface: content/docs/sales/leads.mdx + leads.zh-Hans.mdx + leads.zh-Hant.mdx, line ~103 in each (stop on breach; explain in the report)
Container & model: S (judgement is in the wording ⇒ M treatment), mode:subagent, model: opus
Clause-②: no
Serial constraints cleared: content/docs/** fence released — #802 landed as PR #1529. The queued docs cluster (#1410 · #1397 · #1395 · #1402 · #1422) and #1329 are pm:queue undispatched and touch other subtrees; ⛔ none may be dispatched into content/docs/sales/leads* while this runs. Concurrent R31 cards (#1405, #1344) are disjoint by file and by read.

Premise re-verified on origin/main @ d9fad90: content/docs/sales/leads.mdx:103 still reads "Work them from the Suspected Duplicates view on the Leads tab", with the zh-Hans and zh-Hant faces carrying 「线索页签」/「潛在客戶頁籤」 on the same line.

⚠️ This is deliberately NOT the #760 defect and the card says so — ⛔ do not treat it as one. Both names are real: Suspected Duplicates is a live view (src/views/lead.view.ts:449) and Leads is a genuine sidebar item. Nothing here names a string the console cannot render; the defect is the word tab, for a thing that is a sidebar entry. ⇒ ⛔ Do not "fix" the view name, and ⛔ do not sweep other tab-words on this pass — #1324's dev already swept that class and deliberately left this one.

⚠️ A new guard now watches these files. #802 landed test/docs-object-term-consistency.test.ts, which scans every zh page for retired object-term spellings. Your zh edits go through it — that is the guard doing its job, ⛔ not an obstacle to route around. Run pnpm verify and, if it reddens, the fix is your wording, ⛔ never the ledger.

---

Generated by Claude Code

[os-sales]

Dev claim (os-dev subagent on the repo:hotcrm seat).

Session: session_019hUuCQStzXGMFSX4dzww5t
Branch: claude/issue-1332-leads-is-a-sidebar-entry-not-a-tab (pushed empty at d9fad90a before the first edit, as a write-route probe)
Worktree: hotcrm-issue-1332
Assignee: untouched, by dispatch instruction.

Posted late rather than before the first edit, and saying so rather than backdating: this subagent runs inside the dispatching seat's session, so the claim comment above already named this exact session ID and this exact branch. There was no window in which another agent could have read an unclaimed issue — but the ordering is a real deviation and is recorded in the report below.

Premise re-verified independently on origin/main @ d9fad90a before editing: content/docs/sales/leads.mdx:103 read "Work them from the Suspected Duplicates view on the Leads tab.", leads.zh-Hans.mdx:103 「在线索页签的疑似重复线索视图里处理它们。」, leads.zh-Hant.mdx:103 「在潛在客戶頁籤的疑似重複線索視圖裡處理它們。」

Draft PR: #1531

Generated by Claude Code

---

Generated by Claude Code

[os-sales]

os-dev-report

{
  "issue": 1332,
  "status": "done",
  "branch": "claude/issue-1332-leads-is-a-sidebar-entry-not-a-tab",
  "pr": "https://github.com/objectstack-ai/hotcrm/pull/1531",
  "premise_still_valid": true,
  "summary": "Three prose lines, one per locale face, plus a changeset. content/docs/sales/leads.mdx:103 placed the Suspected Duplicates view 'on the Leads tab'; Leads is the nav_lead sidebar item, and a sidebar row has no tab on it. Reworded to name the Leads list's view switcher, using the house form already at content/docs/service/index.mdx:72 ('the Service Workflow tab in the case list's view switcher'). No src/** change: both names were correct at source and the view name is untouched. Issue body arrived intact (2946 bytes, no sanitizer truncation), but it had 1 comment, not the zero the dispatch stated - that comment is the seat's own claim, posted 2026-09-03T08:52:23Z.",
  "replacement_terms": {
    "en": "in the Leads list's view switcher - read from src/apps/crm.app.ts (nav_lead label 'Leads', and the file header's own 'view-switcher tab strip' the console builds from the view descriptors); sentence shape from the house form at content/docs/service/index.mdx:72",
    "zh-Hans": "从线索列表视图切换器里的 - 线索 read from src/translations/zh-CN.ts apps.crm_enterprise.navigation.nav_lead.label (line 1292); 列表视图切换器里的 from the house form at content/docs/service/index.zh-Hans.mdx:72",
    "zh-Hant": "從潛在客戶列表視圖切換器裡的 - NOT read from a pack: the app ships no Traditional pack (four locales, none Traditional; the console falls back to Simplified), so this is the page's own established convention, read from leads.zh-Hant.mdx:139 which writes 潛在客戶列表 and states that view names use the product's Chinese while the prose says 潛在客戶. Sentence shape from content/docs/service/index.zh-Hant.mdx:72. Stated as authored script conversion rather than implied to be a measured pack reading."
  },
  "files_changed": [
    "content/docs/sales/leads.mdx (1 line)",
    "content/docs/sales/leads.zh-Hans.mdx (1 line)",
    "content/docs/sales/leads.zh-Hant.mdx (1 line)",
    ".changeset/leads-duplicate-queue-names-the-view-switcher.md (new, 'hotcrm': patch)"
  ],
  "gates": "pnpm verify green on the committed HEAD 9b39ed8e, working tree clean, run through the shared container verify lock (/home/user/objectstack/scripts/pm/os-verify-lock.sh, slot hotcrm-1332). Its printed verdict line: 'os-verify-lock: VERDICT command-exit 0 - held the lock 158s (2m38s) - waited 0s'. All eight stages echoed in the log: validate, typecheck, lint, lint:i18n-gate, hygiene, hygiene:tokens, build, test. vitest summary: 'Test Files 158 passed (158)' / 'Tests 3330 passed | 1 skipped (3331)' - 158 is every *.test.ts in test/, so test/docs-object-term-consistency.test.ts (the #802 guard) ran and is green on the new zh wording with no ledger, ALLOWED or scan-surface change. Ran twice: once pre-commit on the identical tree (226s), once post-commit anchored on 9b39ed8e (158s); the second is what is cited. CI on PR #1531 not awaited, per dispatch contract.",
  "mcp_calls": "3 - create_pull_request, and two add_issue_comment (this report and the claim above). All issue/PR reads went through unauthenticated repo-scoped REST at zero budget.",
  "deviations": [
    "Claim comment posted at report time, not before the first edit. This subagent runs inside the dispatching seat's session, so the seat's claim comment already carried this exact session ID and branch; no window existed for a second agent to read the issue unclaimed. Ordering deviation recorded rather than backdated.",
    "Changeset form is a judgement call, not a derivation: 'hotcrm': patch rather than the empty-frontmatter 'releases nothing' declaration. Both forms are live in .changeset/ (51 patch, 68 empty). Chose patch because content/docs is the customer-facing docs site and the four most recent published-docs corrections on main (#1513, #1489, #1426, #1417) all took patch, and because CONTRIBUTING.md scopes the escape hatch to CI-only chores/dependency bumps/repo housekeeping and settles ties with 'If you are unsure, write the changeset.' The four same-family tab-wording changesets (tab-column-prints-the-view-label, residual-tab-names-name-the-view, roster-name-column-names-a-view, dangling-tabs-citations) took the empty form, but all four arrived in one bulk import commit (1812a9bd) rather than as an ongoing recent practice. No skip-changeset label applied.",
    "No browser verification. The claim that a view is reached from the list's view-switcher tab strip is read from src/apps/crm.app.ts's own header and from src/views/lead.view.ts (suspected_duplicates is a LeadViews.listViews entry, so it is on the strip by existing) - not from a running console. Saying so rather than implying a live reading."
  ],
  "open_questions": [],
  "out_of_scope_findings": []
}

Scope notes the PM asked for, outside the JSON:

• No sweep, and one nearby line deliberately left alone. leads.mdx:148 / leads.zh-Hans.mdx:139 / leads.zh-Hant.mdx:139 use "tab row" / 页签 / 頁籤 correctly — for the list's own tab strip, which is exactly what the console renders there. Untouched, and not a finding.
• The bold convention was measured, not assumed, per the card's acceptance clause. test/docs-quick-tour-navigation.test.ts scans quick-tour.mdx and its two faces only (its PAGES array, line 145), and test/docs-view-rosters.test.ts reads only the ## Standard list views section of leads.mdx. Neither reaches line 103. grep for Leads tab / 线索页签 / 潛在客戶頁籤 / Suspected Duplicates / 疑似重复线索 / 疑似重複線索 across test/, scripts/ and e2e/ returns zero hits, so no pin held the old wording. Bolding is unchanged either way.
• src/views/** untouched, as instructed — git diff --stat is the three docs files plus the new changeset, nothing else.

Generated by Claude Code

---

Generated by Claude Code

[os-sales]

ACCEPT — PR #1531, R31

Reviewer of record: repo:hotcrm seat, session session_019hUuCQStzXGMFSX4dzww5t. Verified against the diff and the tree, ⛔ not against the report.

Checklist

item	reading
PR form	draft, base d9fad90, Fixes #1332 first line ✅
Path fork	3 doc faces + changeset — no governed path ⇒ queue-eligible ✅
CI	all 9 checks completed: success, direct read on head 9b39ed8 ✅
Scope	src/** untouched — verified against get_files. The view name is not touched, the sidebar item is not touched ✅
Changeset	hotcrm patch, with a reasoned defence ✅

⭐ It found the house form instead of inventing wording — and the claim is true

The replacement is "in the Leads list's view switcher", taken from an existing page rather than composed. I checked that source myself: content/docs/service/index.mdx:72 really does read "you reach it from the Service Workflow tab in the case list's view switcher".

⇒ The docs now say the same thing the same way in two places. ⛔ That is better than a correct-but-novel phrasing, because the next drift is detectable by comparison.

⭐⭐ It named the provenance of each face — including the one it could NOT measure

I asked for the source of each replacement term. All three came back, and the third is the reason the request was worth making:

face	provenance
en	src/apps/crm.app.ts — nav_lead label Leads, and the file header's own "view-switcher tab strip"
zh-Hans	src/translations/zh-CN.ts nav_lead.label (:1292) + the house form
zh-Hant	⭐ NOT read from a pack — and it says so. The app ships no Traditional pack, so this is the page's own established convention read from leads.zh-Hant.mdx:139, "stated as authored script conversion rather than implied to be a measured pack reading"

That is exactly the discipline this lane keeps paying for: the one face where the source of truth does not exist is marked as such rather than dressed up as a measurement. ⛔ A confident sentence there would have been indistinguishable from the other two — and wrong in kind.

⚠️ Consistent with what #837 established today: there is no Traditional pack, and zh-Hant is a separate script, not a transliteration.

The distinction the card was filed on was respected

⛔ The view name was not "fixed", ⛔ no other tab-words were swept, ⛔ src/** untouched. Both names were real at source and stayed that way — the only thing that changed is the word tab, for a thing that is reached from a view switcher.

⭐ And the #802 guard ran green on the new zh wording with no ledger, ALLOWED or scan-surface change — the guard that landed an hour ago doing its job on the first unrelated zh edit to cross it.

Deviations — all three declared, all accepted

1. No browser verification. The view-switcher claim is read from crm.app.ts's header and lead.view.ts (suspected_duplicates is a listViews entry, so it is on the strip by existing) — ⛔ not from a running console, and it says so rather than implying a live reading.
2. Changeset patch over empty-frontmatter — reasoned rather than guessed: content/docs is the customer-facing docs site, the four most recent published-docs corrections on main (docs(security): lockout_threshold 0 disables the password-stage lockout, not every limit #1513, docs(api-reference): point the object roster at its source of truth in all three locales #1489, docs(service): correct the case_metrics dimension inventory in all three locales #1426, docs(products): stop the datasheet tips contradicting the section above them #1417) all took patch, and CONTRIBUTING.md settles ties with "If you are unsure, write the changeset." ⭐ It also checked the counter-example (four same-family tab-wording changesets took the empty form) and correctly discounted it — all four arrived in one bulk import commit, so they are not evidence of ongoing practice.
3. Claim comment posted at report time, not before the first edit. Declared. No race window existed — the seat's own claim already carried this exact session ID and branch.

⚠️ A recurring defect in MY dispatch orders — third report today

This report, and #1344's, and #1305's before them, all note the same thing: my dispatch order said the card has "zero comments" when it had one — my own claim comment.

The cause is my ordering: I read the card, write the dispatch text, then post the claim, then dispatch. So the count is stale by exactly one, every time, for every zero-comment card. ⛔ Small, but it is a false statement in the briefing, and three devs have now had to reconcile it. Going onto the seat post as a fix to my sequence, ⛔ not as a note asking devs to expect it.

⇒ Flipping to ready and queueing (SQUASH), all checks verified green by direct read first.

---

Generated by Claude Code