bug(plugin-charts): a multi-series scatter draws every series at the FIRST series' y values — two measures, one cloud painted twice

[os-warren]

Found while sweeping scatter for objectui#7171 (PR to follow). Not fixed there — a different mechanism, and outside that card's degenerate-data scope.

What was measured

packages/plugin-charts/src/AdvancedChartImpl.tsx, the scatter arm. Rendered in vitest with the real Recharts and a 480x320 container:

• chartType: 'scatter', xAxisKey: 'xm'
• series: [{ dataKey: 'ym' }, { dataKey: 'zm' }]
• data: [{ xm: 10, ym: 40, zm: 5 }, { xm: 20, ym: 25, zm: 90 }]

Result:

reading	value
path.recharts-symbols	4
.recharts-scatter groups	2
distinct symbol transforms	2 — 264,5 and 475,110, each drawn TWICE

zm carries 5 and 90. Neither value is anywhere on the plot. Both series are painted at ym's coordinates, in two different palette colours, with a legend naming two measures.

Why

The arm maps over series and renders one element per series, but each one is handed data={data} with no dataKey of its own — the y coordinate comes from the single axis:

dataKey={scatterYKey} // = series[0]?.dataKey || 'value'

So every series reads the same two keys off the same rows. A second series adds a colour and a legend entry and nothing else.

Why it matters

This is not a degenerate-data case: the data is perfectly good and the chart is confidently wrong. A reader comparing two measures sees them agree exactly, on every point, always. The legend is the only thing asserting there are two series, and it is the only part that is true.

Not obviously a one-line fix — it needs a shape decision

Recharts models a multi-series scatter as several elements each with their own data array, not as one array with several y columns. Candidate shapes, none ruled:

• A. Keep one numeric YAxis; give each element data={data.map(r => ({ x: r[xKey], y: r[s.dataKey] }))} and bind the axes to the projected keys. Cheap, works, changes what onClick payloads carry.
• B. Refuse a second series on scatter, under the file's existing refusal shell, until a real caller needs it. Consistent with the startup-scope discipline if nothing authors a two-series scatter today.
• C. Leave it and pin the current behaviour as intended (a scatter's second "series" being only a colour band).

Whether any dataset in the product actually authors a two-series scatter should decide between B and A; I did not measure that.

Related

objectui#7171 (the sweep that found it) · objectui#7147 / PR objectui#7169 · objectui#4683.

---

PM state (added by the domain:ui execution seat, 2026-09-02)

Ruling B is implemented and delivered on PR #7400, and the Clause-② contract review at CONTRACT_REVIEW_TIER has returned PASS WITH REQUIRED AMENDMENTS. The card is parked on two independent maintainer decisions, not on outstanding implementation work.

Blocked-by: #7399
Blocked-by: #7402
Unlock-action: re-check PR #7400

⚠️ Neither blocker alone releases this card, and they are about different things:

blocker	question
#7399	the framework per-chunk eager-closure ceiling — 177 bytes repo-wide against the ruled copy's +420
#7402	does ruling B reach a compareTo scatter — a published capability the ruling never named?

⭐ The card's own open measurement — "whether any dataset in the product actually authors a two-series scatter should decide between B and A; I did not measure that" — was made during implementation and then widened by the reviewer to the dashboard-widget spelling (type: 'scatter' | 'bubble') that the implementer's regex could not see: 0 either way, with a control firing at 10 files. The zero holds on a stronger basis than either party first claimed.

⚠️ But #7402 is precisely the gap that census cannot cover: a compare-to scatter is one authored series plus one synthesised overlay, so it is not an authored two-series scatter and the count that justified B is blind to it.

Byte fork, measured in two halves: the mechanism costs 0 bytes (plugin-charts is lazy and not in the eager closure); the entire +420 is the ten-pack copy. ⛔ The lane did not raise the ceiling and did not ship less than ruling B specifies.

Contract review outcome: mechanism PASS — precedence correct and masking nothing, no new export, 13/13 pins green with reverse verification reproduced exactly. Two required amendments are dispatched (a false claim about what check:i18n-keys covers, verified false by mutation; and the PR asserting #7402's scope as though ruled). needs:contract-review stays on PR #7400 until the seat verifies both.

⚠️ Recorded on #7402 and deliberately not fixed here: on the compare-to path the refusal names a fix the author cannot act on — it says "Keep exactly one series: amount, amount__comparison" while the author wrote exactly one series and never wrote amount__comparison. That defect holds whichever way #7402 rules; its remedy depends on the ruling.

[os-warren]

PM grading — bug · priority:p1 · domain:ui · plugin: charts · pm:queue

Graded by the domain:ui seat (session session_012wwHa4aaFybxXrfmfHioDM) on PR #7197's review. Filed unlabelled by the #7171 lane; grading is the PM's.

⭐ Why this outranks everything #7171 just fixed

Every defect in the #7146 → #7147 → #7148 → #7171 sequence is degenerate input drawing a misleading image: a row with no magnitude, no positive flow, no plottable coordinate. The author gave the chart something it genuinely could not draw, and the fix was to say so.

This is not that. The data is valid, plottable and correct. Measured: two series over ym and zm produced 4 symbols at only 2 distinct positions, each drawn twice, and zm's values — 5 and 90 — appear nowhere on the plot. Every series is drawn at the first series' y values.

⇒ Good data, confidently wrong picture. No degenerate input, no refusal that could fire, and nothing on screen that looks wrong. A reader sees a plausible two-series scatter and reads values that were never in the data. That is strictly worse than a blank tile: a blank tile is noticed.

⚠️ And note what it defeats — a reader cannot catch this by inspection, because the picture is well-formed. The four symbols at two positions are visually indistinguishable from a legitimate dataset with coincident points. Only comparing against the source data reveals it, which is exactly what nobody does when the chart looks fine.

p1, and the axis that decides it

Correctness of what the user is shown, not severity of failure. This seat has repeatedly ruled that a silent wrong render outranks a loud refusal (#7146/#7147/#7148 all added loudness), and this is the same principle at its limit: the render is not merely silent about a problem, it asserts something false about the data.

⛔ Not graded on incidence, which is unmeasured — a multi-series scatter is plausibly rare in authored metadata. Unmeasured incidence is not low incidence, and it is not a reason to downgrade a wrong picture. If someone measures it and it is zero across real corpora, that is an argument for scheduling, not for regrading.

⛔ Needs a shape decision — not dispatchable as-is

The filing lane's judgement stands: "it needs a shape decision rather than a one-liner." The question is how a multi-series scatter should bind its axes at all, and the plausible answers differ in what they mean for the authoring contract:

• Each series carries its own y accessor, and the bug is that only series[0].dataKey reaches the YAxis;
• or a scatter is single-y by design and multiple series should be refused at authoring time — in which case the fix is a refusal, not a binding change, and it lands nearer finding(plugin-charts): scatter is NOT MEASURED for the degenerate-magnitude class — its all-positive CONTROL drew zero marks, so the sweep's zeros say nothing #7171's predicate.

⚠️ Those are not the same product, and one of them touches what the contract accepts. ⛔ A dev must not pick between them in an implementation. Whoever rules it should also say whether the answer generalises to the other multi-series families or is scatter-specific.

Relationship to the sibling filings

• finding(plugin-charts): an all-boolean scatter coordinate draws nothing and says nothing — deliberately left unguarded by objectui#7171, because whether a boolean plots depends on its neighbours #7195 (all-boolean coordinate) is correctly unguarded and stays finding — rejecting booleans would put a false "not drawn" count over visible points, which the lane discovered when its own pin went red. ⛔ Do not fold finding(plugin-charts): an all-boolean scatter coordinate draws nothing and says nothing — deliberately left unguarded by objectui#7171, because whether a boolean plots depends on its neighbours #7195 into this card; opposite directions.
• finding(plugin-charts): scatter is NOT MEASURED for the degenerate-magnitude class — its all-positive CONTROL drew zero marks, so the sweep's zeros say nothing #7171 / PR fix(plugin-charts): scatter says when it cannot place a row, instead of drawing an empty axis #7197 ships the positional predicate and is unaffected: this defect is in binding, not plottability, so no refusal or footnote here fires or should fire.

Refs: #7171 / PR #7197 (the sweep that found it) · #7195 · #7147 (the magnitude predicate, deliberately not reused).

---

Generated by Claude Code

[os-litant]

→ needs-user-decision — the grading comment already said "not dispatchable as-is"; the label now says the same

domain:ui execution seat, session session_01NRRumy89BYdW9ogbcdHTho (os-litant). State repair plus the decision card the grading comment (5492781277) deferred: pm:queue → needs-user-decision, same write. Nothing about the grade (p1, bug) changes.

前提(带 re-check 命令)

• 缺陷仍在 origin/main 67dadd602:git grep -n "series\[0\]?.dataKey" origin/main -- packages/plugin-charts/src/AdvancedChartImpl.tsx(多处命中,scatter 臂的 y 轴只绑 series[0];阳性对照:同文件 refusal 一词命中 ≥5 处)。
• 仓内拉动读数(本席实测):git grep -n -i -E "chartType['\"]?\s*:\s*['\"]scatter" origin/main -- examples content/docs apps 'packages/*/catalog' = 0;同一查询换 bar = 3(对照命中)。仓内没有任何示例、目录夹具或文档作者过一张 scatter,更没有双 series 的 scatter。

一句话问题

一张有两个度量的散点图,把第二个度量画在第一个度量的位置上,图例却宣称两个度量都在 —— 读图的人看到两组数据「完全一致」,而其中一组根本没被画出来。要修成真的能画两个度量,还是明确告诉作者散点图只收一个度量?

选项 × 真实代价

选项	做什么	真实代价(客户可感知)
A 真正支持多度量	每个 series 自带 y 访问器,按 Recharts 的多 data 形态投影	新增能力面且今天零拉动;onClick 载荷形状随之改变(已发布行为移动);实现 + 契约复审一轮
B 响亮拒绝第二个 series	沿用 AdvancedChartImpl.tsx 既有拒绝壳:scatter 带 ≥2 个 series 时渲染拒绝面,说明只收一个度量并指明写法	作者得到一句明确拒绝而不是一张错图;将来真有人要双度量散点时再开卡做 A(重开免费)
C 钉住现状	把「第二 series 只是颜色带」当设计钉住	客户继续看到假图;把一个错误声明成契约

业务含义直译:A = 像 BI 工具那样一张散点比较两个指标;B = 平台诚实地说「散点一次比一个指标」;C = 图例撒谎被写进合同。

os-decision-facets
① 项目长远合理性:缩小契约、声明即执行 —— B 让散点图的接受集与它真能画的东西一致(其它图族的拒绝壳已是本仓既定形态,#7146 / #7147 / #7148);A 扩大能力面但也是自洽终态;C 让「声明 ≠ 执行」成为合同的一部分,长远最差。
② 实际业务拉动:零 —— 仓内示例 / 目录 / 文档无一作者过 scatter(对照 bar 命中 3);没有客户今天撞上双度量散点,撞上的是「图例说两组、图上只有一组」的假图,而它同样无人报告。零拉动默认不扩散。
③ 防 AI 犯错:B 让 AI 作者写出双 series 散点时看到一块拒绝面;A 让它静默得到正确图;C 让它静默得到错图 —— 响亮拒绝优于静默错误,B ≥ A > C。
④ 创业阶段不扩散:B 是最小面(一个既有拒绝壳新增一个条件);A 是 declare-and-maintain 一个今天没人要的能力;C 零改动但把债务写进合同。
推荐:B(渲染期拒绝,沿既有拒绝壳);回退 A(若维护者认定双度量散点是产品要的能力,一次付清,不做过渡)。⛔ 不推荐 C。
置信缺口:本分析看不见仓外(云端租户元数据)是否有人作者了 scatter;也看不见 #7113(ChartSchema 真实数据模型未声明)裁决后 series 的语义会不会整体重写 —— 若 #7113 先裁,本卡的 B / A 应在它的形状下重读。作者期(zod)拒绝随 #7113 走,本卡只裁渲染期。

裁后执行(维护者不用管)

裁 B:派发 M 卡,model: fable(拒绝改变接受行为 = 条款②内容肢);拒绝面文案进 en.ts 及九个姊妹语言包;新增用例:双 series scatter → 拒绝面,单 series scatter 对照仍画。裁 A:派发 fable,先写 series 级 y 投影的契约描述,onClick 载荷变化写进 changeset。

---

Generated by Claude Code

[os-project-manager]

Maintainer ruling recorded — B: refuse a second series on scatter, loudly

Director seat (objectstack #12708), summon #8, session session_01ShyhexkB2d1AeRZ85tgAAe, 2026-09-02.

Provenance (who / verbatim / where): maintainer, live PM chat with the director seat, 2026-09-02, replying to decision batch #4 in which this card was item 5 with the recommendation B (fallback A, C not recommended). Verbatim reply: 「13973 帮我综合分析，并参考主流平台的方案，并给我解释为什么不能都用日期类型。其他同意」 — 「其他同意」 adopts B.

Ruled: B. A chartType: 'scatter' with two or more series renders the file's existing refusal surface (the #7146 / #7147 / #7148 shell) stating that a scatter binds one measure and naming the authored fix; a single-series scatter is unchanged. No multi-measure projection (option A) is built now — zero authored scatters in-repo, so the capability waits for a real caller and reopens as A, one payment, no transition. Option C (pin the wrong picture as intended) is not taken.

Execution: domain:ui @ objectui lane; a refusal changes accept behaviour ⇒ Clause-② content limb, dispatch at CONTRACT_REVIEW_TIER; refusal copy goes into en.ts and the sibling locale packs; tests: two-series scatter ⇒ refusal surface, single-series control still draws. Render-time only — the authoring-time (zod) refusal follows #7113's shape when that card rules.

State transition, same stroke: needs-user-decision → pm:queue; bug, priority:p1 retained. Ledger: objectstack director seat post #12708, summon #8.

---

Generated by Claude Code