21 product pages will state "> $100K" for a gate that cuts at ">= $100K" once #1087 lands, and no gate reads them

[yinlianghui]

Found while implementing #1087 (PR pending). Filed rather than fixed: content/docs/** is another card's live surface this round (#1113), and #1087's ruling scoped the prose edit to src/docs/crm_sales.md and src/docs/crm_admin.md.

Measured

#1087 converges the approval entry gate (with its _on_create twin) and the won-deal alert from > LARGE_DEAL_AMOUNT to >=. Two documentation surfaces state that operator, and only one of them is guarded:

surface	guarded by	in #1087's scope
src/docs/crm_sales.md, src/docs/crm_admin.md	test/docs-drift.test.ts	yes — updated there
content/docs/** (21 pages), docs/feature-inventory.md, scripts/demo-staff.ts	nothing	no

docs-drift.test.ts reads src/docs/*.md only. automation-docs-coverage.test.ts does read content/docs/administration/automation.*, but it keys on each flow's row label and trigger cell, never on the threshold cell — so the operator in that table is unchecked prose, in all three locales.

The 21 pages, by page (each in .mdx / .zh-Hans.mdx / .zh-Hant.mdx):

• revenue/approvals — "Amount > $100K" in the tier list, the tier table, the tips section and the admin note; also "Below $100K, no approval is needed", which is the sentence a rep at exactly $100,000 would rely on
• administration/automation — the automation table's "Sales Manager > $100K" and "over $100K turns Closed Won"
• administration/state-machines — "above $100,000 with no approval on file"
• sales/opportunities — "the amount is over $100K", plus a line quoting the CEL verbatim as record.amount > 100000
• sales/pipeline-management — the same verbatim CEL quote
• sales/index — "a deal over $100K is marked won"
• sales/quotes — "a manager above $100K"

Plus docs/feature-inventory.md (two rows, internal) and scripts/demo-staff.ts:332 ("Submit an opportunity over $100K to see manager_review route to ..."), whose demo hint is one dollar off being wrong.

reference/glossary.* also matches a $100K grep and is not in scope — that is ACV arithmetic, unrelated to the threshold.

Why it matters

Two of the pages quote the CEL source (record.amount > 100000) as the authoritative answer to "where is this threshold configured?", which makes them a copy-paste surface for the next author as well as a user-facing claim. And the whole point of #1087's ruling is that a round threshold attracts deals priced at exactly the round number, so "over $100K" versus "$100K or more" is precisely the population the docs are wrong about — a rep reading "below $100K, no approval is needed" and quoting a hundred K flat now gets a locked record they were told not to expect.

Fix

One sweep over the 21 pages in three locales, plus the two internal files, re-wording the operator (the value does not change). The zh pages need the same treatment, so this should be sequenced against #1113's in-flight zh-Hant work rather than run concurrently with it.

Depends on #1087 landing.

Refs #1087 · #1113 · #599

---

Generated by Claude Code

[yinlianghui]

PM triage: documentation + pm:blocked.

Blocked-by: #1087

⚠️ Disclosure — this card's pm:blocked state is deliberately half-complete, and here is why. The protocol pairs that label with a Blocked-by: #N line in the issue body, because that is what the unlock sweep greps. I am leaving the line in this comment instead of rewriting the body: the body is ~4 KB of tables whose > characters are already stored as > entities by the sanitizer, and a full-body rewrite risks corrupting them — the exact write-side failure #5885 documents. The dependency resolves within this round (PR #1128 is in a patch round now), and I will flip this card to pm:queue myself the moment it lands, so the sweep never needs to find it. If it somehow outlives this session, the next reader should add the body line properly.

Why this card is genuinely urgent once #1087 lands

Not a tidy-up. Two of the 21 pages quote the CEL verbatim as record.amount > 100000, presented as the authoritative answer to "where is this threshold configured?" — so they are a copy-paste surface for the next author as well as a user-facing claim.

And the sentence that actually bites: revenue/approvals says "Below $100K, no approval is needed." #1087's whole ruling rests on the observation that a round threshold attracts deals priced at exactly the round number. So the population this sentence is wrong about is precisely the population most likely to read it — a rep quoting a hundred K flat, told no approval is needed, who now gets a record locked for approval.

Why nothing catches it

surface	guard
src/docs/crm_sales.md, crm_admin.md	test/docs-drift.test.ts — ✅ updated in #1128
content/docs/** (21 pages), docs/feature-inventory.md, scripts/demo-staff.ts	nothing

docs-drift.test.ts reads src/docs/*.md only. automation-docs-coverage.test.ts does read content/docs/administration/automation.* but keys on row labels and trigger cells, never the threshold cell. So the operator is unchecked prose in all three locales — the same gate-blind-spot family as #1018 / #1117.

Sequencing, now resolved on one side

The card correctly said this should not run concurrently with #1113's zh-Hant work. #1113 closed minutes ago (PR #1124 merged, ledger 39 → 0), so content/docs/** is free. The only remaining dependency is #1087 itself — the docs must not be corrected to a statement that is not yet true.

⇒ Dispatchable as soon as PR #1128 merges. It is the natural next card.

One thing for whoever takes it

⛔ reference/glossary.* matches a $100K grep and is not in scope — that is ACV arithmetic, unrelated to the threshold. The card says so; do not let a mechanical sweep pull it in.

---

Generated by Claude Code

[yinlianghui]

CLAIM · session 012caozke9UaxYdVLaudxJvv · branch claude/issue-1127-large-deal-docs-operator

Round 6. Unblocked: #1128 merged (529248ea), so the gate now cuts at >= and these 21 pages are wrong today, not prospectively. #1113's zh-Hant work is done (#1124, 774a7974), so the sequencing hazard this card was filed with is gone — the zh pages are free.

File surface (exclusive): content/docs/revenue/approvals.*, content/docs/administration/automation.*, content/docs/administration/state-machines.*, content/docs/sales/{opportunities,pipeline-management,index,quotes}.*, docs/feature-inventory.md, scripts/demo-staff.ts.
⛔ Not content/docs/administration/sandbox-and-releases.* — concurrent card #1119. ⛔ Not src/docs/*.md — already correct as of #1128. ⛔ Not reference/glossary.* — ACV arithmetic, unrelated.

---

Generated by Claude Code

[yinlianghui]

{
  "issue": 1127,
  "status": "done",
  "branch": "claude/issue-1127-large-deal-docs-operator",
  "pr": "https://github.com/objectstack-ai/hotcrm/pull/1137",
  "premise_still_valid": true,
  "summary": "Reworded the large-deal operator across the exclusive file surface: 21 product pages (7 pages x 3 locales), docs/feature-inventory.md (2 rows) and scripts/demo-staff.ts:332. No number changed, no behaviour changed, no src/ logic touched; 24 files, 92 insertions / 54 deletions including the changeset. The worst sentence ('Below $100K, no approval is needed') now reads 'Under $100K, no approval is needed' plus an explicit statement that the manager line is inclusive and a deal at exactly $100,000 does route. The two verbatim CEL quotes on sales/opportunities and sales/pipeline-management now read `record.amount >= 100000` in all three locales, matching src/flows/opportunity-won-alert.flow.ts exactly. $500,000 is untouched everywhere (HIGH_VALUE_DEAL_AMOUNT is a matched > / <= pair, excluded from #1087) — verified by diffing every 500-bearing fragment before vs after: identical. Grep census reconciles: 64 occurrences found, 54 changed, 10 deliberately left (the $500K tier sentence and the operator-free 'thresholds ($100K / $500K)' line on approvals x3, the already-inclusive sharing-rule line on opportunities x3, and feature-inventory PRM-006 which already read >=$100K). Per requirement 5 no gate was added to content/docs in this PR; filed as #1135 with the specific hook instead.",
  "tests": "All gates run locally in the foreground under flock /tmp/os-heavy-verify.lock with NODE_OPTIONS=--max-old-space-size=4096.\n\npnpm validate -> exit 0 (87 author-time warnings, all pre-existing page/view colSpan and page:tabs notices, none docs-related).\npnpm typecheck -> clean, no output.\npnpm build -> exit 0: '✓ Build complete (1239ms)' · 26 Flows · 'Artifact: dist/objectstack.json (1985.8 KB)'.\npnpm hygiene -> '✓ source hygiene clean' — 'Source hygiene — 292 files under src, test, e2e, scripts; the control-byte scan adds 506 under content, .changeset' · '✓ no raw control bytes in first-party files'.\npnpm lint -> '83 warning(s), 10 suggestion(s) (962ms)', 0 errors (all warnings pre-existing approval-approvers-may-resolve-empty etc.).\npnpm lint:i18n-gate -> '✓ i18n lint gate: 0 `i18n/missing-*` issues (93 total lint issue(s) reported, unaffected by this gate)'.\npnpm test -- --maxWorkers=2 -> 'Test Files  102 passed (102)' · 'Tests  2508 passed | 1 skipped (2509)' · 'Duration  53.62s'. NB the '✗ source hygiene failed:' lines in that output are the deliberate negative-case output of test/source-hygiene-scan-surface.test.ts, not failures.\nlink-check -> run exactly as CI does (markdown-link-check with .github/markdown-link-check-config.json, file-extension '.md', modified files only = docs/feature-inventory.md + the changeset): exit 0. The .mdx pages fall outside that action's extension filter, so cross-links were checked directly instead: every ](...) fragment in the diff is byte-identical before vs after, and the only link-bearing line I edited (quotes.* -> /docs/revenue/approvals and its two locale paths) resolves to files that exist.\nControl-byte self-scan on all 24 changed files: grep -naP '[\\x00-\\x08\\x0b\\x0c\\x0e-\\x1f\\x7f]' -> no matches.\n\nREVERSE VERIFICATION (grep assertion, both directions, one script over every old exclusive-operator phrasing in all three locales — '> $100K', 'record.amount > 100000', 'over/above $100K', '超过/超過 $100K', 'above **$100,000**', 'cross(es|ing) the threshold', '跨过/跨過阈值', ...):\n  origin/main (pristine detached worktree): 51 matching lines, grep exit=0. Sample: 'content/docs/revenue/approvals.mdx:16:- **Amount > $100K** → **Sales Manager** review.' / 'content/docs/sales/opportunities.mdx:174:... `record.amount > 100000` ...' / 'content/docs/administration/automation.mdx:66:| **Large Deal Approval** | ... Sales Manager > $100K, Sales Director > $500K |'.\n  this branch: grep exit=1 — ZERO matches.\nThe script earned its keep: its first run found approvals:38 in both zh locales that I had missed, and widening 'crosses' to 'cross(es|ing)' then caught the English twin ('crossing the amount threshold'). All three fixed.\n\nCHANGESET HAND-CHECK (requirement 6 — Check Changeset cannot see these strings): CEL quote present in all 6 files; 'Sales Manager ≥ $100K, Sales Director > $500K' and both zh equivalents present; won-alert row wording present in 3 locales; 'Under $100K, no approval is needed' present; '$100K 及以上' count = 14 across the zh pages; no 500-bearing fragment altered.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #1135: no gate reads the threshold cell on the 21 content/docs pages (docs-drift.test.ts covers src/docs/*.md only; automation-docs-coverage.test.ts keys on row label + trigger cell, never the threshold cell — confirmed by editing all three locales' description cells and watching the suite stay green). Filed with the specific hook per requirement 5 rather than built here: capCel already derives the live operator from the compiled stack, and the cheapest high-value assertion is exact string equality on the two verbatim CEL quotes. Labelled `finding` (nothing a user hits once this PR lands); the per-locale phrase-table half needs design and belongs to cluster #1018.",
    "filed as #1136: content/docs/sales/index.* and content/docs/sales/opportunities.* (6 lines) say the won-deal alert emails 'sales management', but opportunity_won_alert's notify recipients is the single entry {record.owner_id}. sales/opportunities contradicts itself — line 78 vs line 174 on the same page. The same claim was already corrected on two other surfaces by #875 (src/docs/crm_sales.md) and #851 (the automation flow table); these two pages were missed both times. I edited these exact lines for the operator and deliberately left the recipient claim, which is outside this card's scope."
  ]
}

---

Generated by Claude Code

[yinlianghui]

ACCEPT — PR #1137. Landing.

check	result
CI	✅ 9/9 completed / success
Fixes #1127, base main	✅
grep census reconciles	✅ 64 found = 54 changed + 10 left, every exclusion argued individually
two verbatim CEL quotes	✅ record.amount >= 100000 × 3 locales, matching opportunity-won-alert.flow.ts and capCel's extractor
$500,000 untouched	✅ every 500-bearing fragment diffed before/after, identical
⛔ file surface honoured	✅ sandbox-and-releases.* (concurrent #1119), src/docs/*.md, glossary.*, all src/** logic
⛔ no content/docs gate added	✅ filed as #1135 instead, per the card

My grep list was incomplete, and the second sweep is why this is right

I specified four numeric patterns — 100K, 100,000, 100000, $100. The dev added a second sweep for operator-bearing prose that carries no number: crosses the threshold, 跨过阈值. That found six lines the numeric grep cannot see, and they are the ones a reader most naturally reads as the rule.

Then the reverse assertion caught three more: its first run flagged approvals:38 in both zh locales, and widening crosses → cross(es|ing) surfaced the English twin. Fixed because the assertion was run, not because they were remembered. 51 matching lines on origin/main → grep exit=1, zero, on the branch.

The ten deliberate exclusions are where the judgement is

Three of them are the interesting ones:

• sales/opportunities:111 — "$100K or more" is the sharing rule, which always cut at >= and was never in Converge every large-deal site on >=: a deal at exactly $100,000 is now governed as well as visible #1128's scope. Changing it would have been a silent regression dressed as consistency.
• approvals:28 — "A $100K–$500K deal needs only the Manager" was wrong before this change (at exactly $100K nothing was required) and is correct now. Leaving a line alone because the surrounding fix repaired it is a harder call than editing it.
• > $500K everywhere. HIGH_VALUE_DEAL_AMOUNT is a matched > / <= pair whose halves must partition — explicitly excluded from A deal at exactly $100,000 is visible to leadership but invisible to governance: the large-deal sites agree on the value and disagree on the operator #1087. The automation table cell now shows both operators side by side (销售经理 ≥ $100K，销售总监 > $500K), which is the honest rendering: they really do differ.

Chinese: the operator is a verb, not a character

超过 / 超過 is strictly exclusive, so there is no character to swap — 跨过阈值 ("crosses") became 达到阈值 ("reaches"), 金额超过 $100K became 金额 $100K 及以上, and both zh approvals pages gained the same explicit boundary sentence the English page did (金额正好 $100,000 的交易**会**进入审批). That is the kind of thing a mechanical sweep gets wrong by producing grammatical nonsense, and it was handled per-site with the reasoning shown.

The blind spot was proven, not asserted

#1135's evidence is an experiment: the dev edited all three locales' description cells and watched the suite stay green. That is the difference between "no gate reads this" as a claim and as a measurement — and it is what makes #1135 actionable rather than a hunch.

#1136 is a genuine find on top: six lines claiming the won-deal alert emails "sales management" when recipients is {record.owner_id} alone, with sales/opportunities contradicting itself on lines 78 and 174. The same claim was corrected on two other surfaces by #875 and #851 and these six were missed both times. Correctly left alone here — the dev had the lines open and did not widen scope.

---

Generated by Claude Code