[Decision] Does #7194's ruling B reach a compareTo scatter — a published capability it never named? The refusal currently swallows it and names a fix the author cannot act on #7402

Description

@os-project-manager

Filed by the domain:ui execution seat (PM session session_01EMrWaQw3XS5DxTHxp4yRyC) on the finding of an in-seat contract review at CONTRACT_REVIEW_TIER (claude-fable-5) of PR #7400. ⛔ Not graded and no domain:* — routing, type and priority are the triage seat's.

⭐ This is the reviewer's Q1, raised explicitly as "the maintainer's question, not the PM's or mine". The seat is not answering it, and the reviewer deliberately did not either. It is separate from #7399 (that one is the byte ceiling); this one is about ruling scope and a published capability.

The question

#7194 ruled B — a scatter with two or more series refuses. Verbatim, from the ruling (comment 5507673384):

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.

⚠️Neither the ruling nor the decision card it adopted mentions compareTo or variant.

But a compare-to scatter is a two-series scatter in the product, so the refusal swallows it.

Verified on PR #7400's head eacc559

factevidence
scatter is on the published compare-to listpackages/plugin-charts/CHANGELOG.md:1727"overlay a muted comparison-period series… Pie / donut / funnel ignore compareTo" ⇒ scatter does not
it was designed, not incidentalcomparisonStyle(s, kind) (AdvancedChartImpl.tsx:92) has a scatter-specific opacity branch, and the base scatter arm already calls comparisonStyle(s, 'scatter')
the overlay is synthesised as a second seriesObjectChart.tsx:338supportsCompareTo excludes only pie/donut/funnel; augmentedSeries (815) appends { dataKey: '…__comparison', variant: 'comparison' }
the dashboard path has no chart-type exclusion eitherDatasetWidget.tsx:759 — widget types scatter and bubble both map to chartType: 'scatter' (377)
⚠️ today's picture on that path is already wrongthe overlay reads y through the single YAxis dataKey={scatterYKey} = series[0].dataKey, so "previous period" is painted exactly on "current" — the same defect #7194 fixes

⇒ Exempting the overlay in the renderer would restore that wrong picture. The PR is right about that. The question is whether refusing is what B meant.

Why the ruling's own text does not settle it

The literal predicate ("two or more series") does reach it. But the ruling's stated premise"zero authored scatters in-repo, so the capability waits for a real caller" — was measured on chartType: 'scatter' literals. A compare-to scatter is one authored series plus one synthesised overlay from a documented product feature. It is not an authored two-series scatter, and the census that justified B cannot see it.

⚠️ The PR currently resolves that gap by itself: its pin comment reads "The ruling counts series, not variants" — the implementer's reading, not the ruling's words — and its changeset records it as settled ("This applies to a compareTo overlay too"). That is what the review requires be undone until this card rules.

⭐ A second defect on that path, independent of which way Q1 goes

Ruling B requires the refusal name "the authored fix". On the compare-to path the tile says:

Keep exactly one series: amount, amount__comparison

The author has exactly one series in their spec and never wroteamount__comparison. The named fix is not applicable, and the real fix ("remove compareTo") is unknowable at the renderer, which only sees series. ⇒ Even a confirmed refusal needs its copy or its refusal site changed on this path. A refusal that misdirects the author is worse than the wrong picture it replaces, because it costs a session to disprove.

The shapes (recorded, not recommended)

(a) Confirm — a compare-to scatter refuses. Then the copy or the refusal site must name the actual authored fix there — e.g. raise it upstream in ObjectChart / DatasetWidget where compareTo is known, or add a compare-to-aware sentence. ⚠️ Note the primary series, which drew correctly, is also lost from that tile.

(b) Exclude scatter from compareTo, exactly as pie / donut / funnel already are and as the CHANGELOG already publishes for them: the primary draws, the overlay is never synthesised, the renderer's guard is never reached in product, and the PR's pin inverts. ⚠️ Touches packages/plugin-dashboard — outside PR #7400's declared file surface — and changes a published statement.

(c) Project the overlay only — option A territory, which the ruling explicitly declined.

Reachability, stated honestly

0 in-repo instances. The reviewer widened the census beyond the PR's own regex to the dashboard-widget spelling (type: 'scatter' | 'bubble'), which the PR's pattern cannot see: still 0, with a control (type: 'bar') firing at 10 files including five examples/schema-catalog/**/plugin-dashboard/*.json. So the zero holds on a stronger basis than the PR claimed. ⚠️ But it is authorable today through both surfaces, and incidence in cloud tenant metadata is unmeasurable — the decision card for #7194 said so. ⛔ Unmeasured incidence is not low incidence.

四维分析

长期健全性 —— 一个已发布的能力(scatter 上的 compareTo,CHANGELOG 明写只有 pie/donut/funnel 忽略它,且代码里有 scatter 专属的 comparisonStyle 分支)被一条从未点名它的拒绝裁决顺带吃掉,这正是"裁决"二字被稀释的方式:下一次读这条裁决的人会以为它裁过 compareTo,而它没有。⚠️ 反向也成立:今天那条路径画的是错的图(叠加层被画在主序列的 y 上),(b) 保留能力就等于知情地继续画错。⇒ 本轴不指向某个选项,它指向"必须显式裁",而不是由实现者的一句 pin 注释代裁。

真实业务需求 —— 仓内 0 例(复审员用更强的对照重测过,对照命中 10 个文件,所以这个 0 是读数)。⚠️ 但两条产品路径今天都能写出来,云端租户元数据里的实际发生率测不到。⇒ 需求侧给不出方向,只能说明"不紧急",不能说明"可以默认"。

让 AI 写的代码不易出错 —— 这一轴最尖锐,且与 Q1 怎么裁无关:当前拒绝面对作者说「Keep exactly one series: amount, amount__comparison」,而作者的 spec 里只有一个 series,amount__comparison 是系统合成的、他从没写过。⇒ 这是一条指向不存在的写法的拒绝 —— 比它所替代的错图更贵,因为错图至少能被看出来,而错误的修复指引会把人送去改一个不存在的字段。无论 (a) 还是 (b),这一条都必须修。

创业公司范围纪律 —— (a) 最省,只动本 PR 的文案/拒绝位;(b) 要动 packages/plugin-dashboard,超出本 PR 已申报的文件面,并且要改一句已发布的 CHANGELOG 陈述;(c) 是裁决已明确不做的 option A。⇒ 本轴偏向 (a),但它是四轴里最弱的一条,⛔ 不足以单独决定一个已发布能力的去留。

Status

PR #7400 keeps needs:contract-review and stays draft. The review's verdict is PASS WITH REQUIRED AMENDMENTS; the amendment tied to this card is "do not land the compareTo behaviour as decided until Q1 is answered". #7194 is now blocked on this card in addition to #7399⚠️two independent decisions, one about bytes and one about scope; either alone does not release it.

Related

#7194 (the card and ruling B) · PR #7400 · #7399 (the other, unrelated decision blocking the same PR) · #7113 (the authoring-time zod refusal this deliberately does not pre-empt) · #7146 / #7147 / #7148 (the refusal shell precedents)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
       blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
      }
      } catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
      })();
      (function(){
      try {
      var __m = "github.com";
      var __re = new RegExp('^' + "github\\.com" + '
      
      Skip to content

      [Decision] Does #7194's ruling B reach a compareTo scatter — a published capability it never named? The refusal currently swallows it and names a fix the author cannot act on #7402

      Description

      @os-project-manager

      Filed by the domain:ui execution seat (PM session session_01EMrWaQw3XS5DxTHxp4yRyC) on the finding of an in-seat contract review at CONTRACT_REVIEW_TIER (claude-fable-5) of PR #7400. ⛔ Not graded and no domain:* — routing, type and priority are the triage seat's.

      ⭐ This is the reviewer's Q1, raised explicitly as "the maintainer's question, not the PM's or mine". The seat is not answering it, and the reviewer deliberately did not either. It is separate from #7399 (that one is the byte ceiling); this one is about ruling scope and a published capability.

      The question

      #7194 ruled B — a scatter with two or more series refuses. Verbatim, from the ruling (comment 5507673384):

      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.

      ⚠️Neither the ruling nor the decision card it adopted mentions compareTo or variant.

      But a compare-to scatter is a two-series scatter in the product, so the refusal swallows it.

      Verified on PR #7400's head eacc559

      factevidence
      scatter is on the published compare-to listpackages/plugin-charts/CHANGELOG.md:1727"overlay a muted comparison-period series… Pie / donut / funnel ignore compareTo" ⇒ scatter does not
      it was designed, not incidentalcomparisonStyle(s, kind) (AdvancedChartImpl.tsx:92) has a scatter-specific opacity branch, and the base scatter arm already calls comparisonStyle(s, 'scatter')
      the overlay is synthesised as a second seriesObjectChart.tsx:338supportsCompareTo excludes only pie/donut/funnel; augmentedSeries (815) appends { dataKey: '…__comparison', variant: 'comparison' }
      the dashboard path has no chart-type exclusion eitherDatasetWidget.tsx:759 — widget types scatter and bubble both map to chartType: 'scatter' (377)
      ⚠️ today's picture on that path is already wrongthe overlay reads y through the single YAxis dataKey={scatterYKey} = series[0].dataKey, so "previous period" is painted exactly on "current" — the same defect #7194 fixes

      ⇒ Exempting the overlay in the renderer would restore that wrong picture. The PR is right about that. The question is whether refusing is what B meant.

      Why the ruling's own text does not settle it

      The literal predicate ("two or more series") does reach it. But the ruling's stated premise"zero authored scatters in-repo, so the capability waits for a real caller" — was measured on chartType: 'scatter' literals. A compare-to scatter is one authored series plus one synthesised overlay from a documented product feature. It is not an authored two-series scatter, and the census that justified B cannot see it.

      ⚠️ The PR currently resolves that gap by itself: its pin comment reads "The ruling counts series, not variants" — the implementer's reading, not the ruling's words — and its changeset records it as settled ("This applies to a compareTo overlay too"). That is what the review requires be undone until this card rules.

      ⭐ A second defect on that path, independent of which way Q1 goes

      Ruling B requires the refusal name "the authored fix". On the compare-to path the tile says:

      Keep exactly one series: amount, amount__comparison

      The author has exactly one series in their spec and never wroteamount__comparison. The named fix is not applicable, and the real fix ("remove compareTo") is unknowable at the renderer, which only sees series. ⇒ Even a confirmed refusal needs its copy or its refusal site changed on this path. A refusal that misdirects the author is worse than the wrong picture it replaces, because it costs a session to disprove.

      The shapes (recorded, not recommended)

      (a) Confirm — a compare-to scatter refuses. Then the copy or the refusal site must name the actual authored fix there — e.g. raise it upstream in ObjectChart / DatasetWidget where compareTo is known, or add a compare-to-aware sentence. ⚠️ Note the primary series, which drew correctly, is also lost from that tile.

      (b) Exclude scatter from compareTo, exactly as pie / donut / funnel already are and as the CHANGELOG already publishes for them: the primary draws, the overlay is never synthesised, the renderer's guard is never reached in product, and the PR's pin inverts. ⚠️ Touches packages/plugin-dashboard — outside PR #7400's declared file surface — and changes a published statement.

      (c) Project the overlay only — option A territory, which the ruling explicitly declined.

      Reachability, stated honestly

      0 in-repo instances. The reviewer widened the census beyond the PR's own regex to the dashboard-widget spelling (type: 'scatter' | 'bubble'), which the PR's pattern cannot see: still 0, with a control (type: 'bar') firing at 10 files including five examples/schema-catalog/**/plugin-dashboard/*.json. So the zero holds on a stronger basis than the PR claimed. ⚠️ But it is authorable today through both surfaces, and incidence in cloud tenant metadata is unmeasurable — the decision card for #7194 said so. ⛔ Unmeasured incidence is not low incidence.

      四维分析

      长期健全性 —— 一个已发布的能力(scatter 上的 compareTo,CHANGELOG 明写只有 pie/donut/funnel 忽略它,且代码里有 scatter 专属的 comparisonStyle 分支)被一条从未点名它的拒绝裁决顺带吃掉,这正是"裁决"二字被稀释的方式:下一次读这条裁决的人会以为它裁过 compareTo,而它没有。⚠️ 反向也成立:今天那条路径画的是错的图(叠加层被画在主序列的 y 上),(b) 保留能力就等于知情地继续画错。⇒ 本轴不指向某个选项,它指向"必须显式裁",而不是由实现者的一句 pin 注释代裁。

      真实业务需求 —— 仓内 0 例(复审员用更强的对照重测过,对照命中 10 个文件,所以这个 0 是读数)。⚠️ 但两条产品路径今天都能写出来,云端租户元数据里的实际发生率测不到。⇒ 需求侧给不出方向,只能说明"不紧急",不能说明"可以默认"。

      让 AI 写的代码不易出错 —— 这一轴最尖锐,且与 Q1 怎么裁无关:当前拒绝面对作者说「Keep exactly one series: amount, amount__comparison」,而作者的 spec 里只有一个 series,amount__comparison 是系统合成的、他从没写过。⇒ 这是一条指向不存在的写法的拒绝 —— 比它所替代的错图更贵,因为错图至少能被看出来,而错误的修复指引会把人送去改一个不存在的字段。无论 (a) 还是 (b),这一条都必须修。

      创业公司范围纪律 —— (a) 最省,只动本 PR 的文案/拒绝位;(b) 要动 packages/plugin-dashboard,超出本 PR 已申报的文件面,并且要改一句已发布的 CHANGELOG 陈述;(c) 是裁决已明确不做的 option A。⇒ 本轴偏向 (a),但它是四轴里最弱的一条,⛔ 不足以单独决定一个已发布能力的去留。

      Status

      PR #7400 keeps needs:contract-review and stays draft. The review's verdict is PASS WITH REQUIRED AMENDMENTS; the amendment tied to this card is "do not land the compareTo behaviour as decided until Q1 is answered". #7194 is now blocked on this card in addition to #7399⚠️two independent decisions, one about bytes and one about scope; either alone does not release it.

      Related

      #7194 (the card and ruling B) · PR #7400 · #7399 (the other, unrelated decision blocking the same PR) · #7113 (the authoring-time zod refusal this deliberately does not pre-empt) · #7146 / #7147 / #7148 (the refusal shell precedents)

      Metadata

      Metadata

      Assignees

      No one assigned

        Type

        No type

        Projects

        No projects

          Milestone

          No milestone

          Relationships

          None yet

          Development

          No branches or pull requests

          Issue actions

          , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
          Skip to content

          [Decision] Does #7194's ruling B reach a compareTo scatter — a published capability it never named? The refusal currently swallows it and names a fix the author cannot act on #7402

          Description

          @os-project-manager

          Filed by the domain:ui execution seat (PM session session_01EMrWaQw3XS5DxTHxp4yRyC) on the finding of an in-seat contract review at CONTRACT_REVIEW_TIER (claude-fable-5) of PR #7400. ⛔ Not graded and no domain:* — routing, type and priority are the triage seat's.

          ⭐ This is the reviewer's Q1, raised explicitly as "the maintainer's question, not the PM's or mine". The seat is not answering it, and the reviewer deliberately did not either. It is separate from #7399 (that one is the byte ceiling); this one is about ruling scope and a published capability.

          The question

          #7194 ruled B — a scatter with two or more series refuses. Verbatim, from the ruling (comment 5507673384):

          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.

          ⚠️Neither the ruling nor the decision card it adopted mentions compareTo or variant.

          But a compare-to scatter is a two-series scatter in the product, so the refusal swallows it.

          Verified on PR #7400's head eacc559

          factevidence
          scatter is on the published compare-to listpackages/plugin-charts/CHANGELOG.md:1727"overlay a muted comparison-period series… Pie / donut / funnel ignore compareTo" ⇒ scatter does not
          it was designed, not incidentalcomparisonStyle(s, kind) (AdvancedChartImpl.tsx:92) has a scatter-specific opacity branch, and the base scatter arm already calls comparisonStyle(s, 'scatter')
          the overlay is synthesised as a second seriesObjectChart.tsx:338supportsCompareTo excludes only pie/donut/funnel; augmentedSeries (815) appends { dataKey: '…__comparison', variant: 'comparison' }
          the dashboard path has no chart-type exclusion eitherDatasetWidget.tsx:759 — widget types scatter and bubble both map to chartType: 'scatter' (377)
          ⚠️ today's picture on that path is already wrongthe overlay reads y through the single YAxis dataKey={scatterYKey} = series[0].dataKey, so "previous period" is painted exactly on "current" — the same defect #7194 fixes

          ⇒ Exempting the overlay in the renderer would restore that wrong picture. The PR is right about that. The question is whether refusing is what B meant.

          Why the ruling's own text does not settle it

          The literal predicate ("two or more series") does reach it. But the ruling's stated premise"zero authored scatters in-repo, so the capability waits for a real caller" — was measured on chartType: 'scatter' literals. A compare-to scatter is one authored series plus one synthesised overlay from a documented product feature. It is not an authored two-series scatter, and the census that justified B cannot see it.

          ⚠️ The PR currently resolves that gap by itself: its pin comment reads "The ruling counts series, not variants" — the implementer's reading, not the ruling's words — and its changeset records it as settled ("This applies to a compareTo overlay too"). That is what the review requires be undone until this card rules.

          ⭐ A second defect on that path, independent of which way Q1 goes

          Ruling B requires the refusal name "the authored fix". On the compare-to path the tile says:

          Keep exactly one series: amount, amount__comparison

          The author has exactly one series in their spec and never wroteamount__comparison. The named fix is not applicable, and the real fix ("remove compareTo") is unknowable at the renderer, which only sees series. ⇒ Even a confirmed refusal needs its copy or its refusal site changed on this path. A refusal that misdirects the author is worse than the wrong picture it replaces, because it costs a session to disprove.

          The shapes (recorded, not recommended)

          (a) Confirm — a compare-to scatter refuses. Then the copy or the refusal site must name the actual authored fix there — e.g. raise it upstream in ObjectChart / DatasetWidget where compareTo is known, or add a compare-to-aware sentence. ⚠️ Note the primary series, which drew correctly, is also lost from that tile.

          (b) Exclude scatter from compareTo, exactly as pie / donut / funnel already are and as the CHANGELOG already publishes for them: the primary draws, the overlay is never synthesised, the renderer's guard is never reached in product, and the PR's pin inverts. ⚠️ Touches packages/plugin-dashboard — outside PR #7400's declared file surface — and changes a published statement.

          (c) Project the overlay only — option A territory, which the ruling explicitly declined.

          Reachability, stated honestly

          0 in-repo instances. The reviewer widened the census beyond the PR's own regex to the dashboard-widget spelling (type: 'scatter' | 'bubble'), which the PR's pattern cannot see: still 0, with a control (type: 'bar') firing at 10 files including five examples/schema-catalog/**/plugin-dashboard/*.json. So the zero holds on a stronger basis than the PR claimed. ⚠️ But it is authorable today through both surfaces, and incidence in cloud tenant metadata is unmeasurable — the decision card for #7194 said so. ⛔ Unmeasured incidence is not low incidence.

          四维分析

          长期健全性 —— 一个已发布的能力(scatter 上的 compareTo,CHANGELOG 明写只有 pie/donut/funnel 忽略它,且代码里有 scatter 专属的 comparisonStyle 分支)被一条从未点名它的拒绝裁决顺带吃掉,这正是"裁决"二字被稀释的方式:下一次读这条裁决的人会以为它裁过 compareTo,而它没有。⚠️ 反向也成立:今天那条路径画的是错的图(叠加层被画在主序列的 y 上),(b) 保留能力就等于知情地继续画错。⇒ 本轴不指向某个选项,它指向"必须显式裁",而不是由实现者的一句 pin 注释代裁。

          真实业务需求 —— 仓内 0 例(复审员用更强的对照重测过,对照命中 10 个文件,所以这个 0 是读数)。⚠️ 但两条产品路径今天都能写出来,云端租户元数据里的实际发生率测不到。⇒ 需求侧给不出方向,只能说明"不紧急",不能说明"可以默认"。

          让 AI 写的代码不易出错 —— 这一轴最尖锐,且与 Q1 怎么裁无关:当前拒绝面对作者说「Keep exactly one series: amount, amount__comparison」,而作者的 spec 里只有一个 series,amount__comparison 是系统合成的、他从没写过。⇒ 这是一条指向不存在的写法的拒绝 —— 比它所替代的错图更贵,因为错图至少能被看出来,而错误的修复指引会把人送去改一个不存在的字段。无论 (a) 还是 (b),这一条都必须修。

          创业公司范围纪律 —— (a) 最省,只动本 PR 的文案/拒绝位;(b) 要动 packages/plugin-dashboard,超出本 PR 已申报的文件面,并且要改一句已发布的 CHANGELOG 陈述;(c) 是裁决已明确不做的 option A。⇒ 本轴偏向 (a),但它是四轴里最弱的一条,⛔ 不足以单独决定一个已发布能力的去留。

          Status

          PR #7400 keeps needs:contract-review and stays draft. The review's verdict is PASS WITH REQUIRED AMENDMENTS; the amendment tied to this card is "do not land the compareTo behaviour as decided until Q1 is answered". #7194 is now blocked on this card in addition to #7399⚠️two independent decisions, one about bytes and one about scope; either alone does not release it.

          Related

          #7194 (the card and ruling B) · PR #7400 · #7399 (the other, unrelated decision blocking the same PR) · #7113 (the authoring-time zod refusal this deliberately does not pre-empt) · #7146 / #7147 / #7148 (the refusal shell precedents)

          Metadata

          Metadata

          Assignees

          No one assigned

            Type

            No type

            Projects

            No projects

              Milestone

              No milestone

              Relationships

              None yet

              Development

              No branches or pull requests

              Issue actions

              , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
              Skip to content

              [Decision] Does #7194's ruling B reach a compareTo scatter — a published capability it never named? The refusal currently swallows it and names a fix the author cannot act on #7402

              Description

              @os-project-manager

              Filed by the domain:ui execution seat (PM session session_01EMrWaQw3XS5DxTHxp4yRyC) on the finding of an in-seat contract review at CONTRACT_REVIEW_TIER (claude-fable-5) of PR #7400. ⛔ Not graded and no domain:* — routing, type and priority are the triage seat's.

              ⭐ This is the reviewer's Q1, raised explicitly as "the maintainer's question, not the PM's or mine". The seat is not answering it, and the reviewer deliberately did not either. It is separate from #7399 (that one is the byte ceiling); this one is about ruling scope and a published capability.

              The question

              #7194 ruled B — a scatter with two or more series refuses. Verbatim, from the ruling (comment 5507673384):

              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.

              ⚠️Neither the ruling nor the decision card it adopted mentions compareTo or variant.

              But a compare-to scatter is a two-series scatter in the product, so the refusal swallows it.

              Verified on PR #7400's head eacc559

              factevidence
              scatter is on the published compare-to listpackages/plugin-charts/CHANGELOG.md:1727"overlay a muted comparison-period series… Pie / donut / funnel ignore compareTo" ⇒ scatter does not
              it was designed, not incidentalcomparisonStyle(s, kind) (AdvancedChartImpl.tsx:92) has a scatter-specific opacity branch, and the base scatter arm already calls comparisonStyle(s, 'scatter')
              the overlay is synthesised as a second seriesObjectChart.tsx:338supportsCompareTo excludes only pie/donut/funnel; augmentedSeries (815) appends { dataKey: '…__comparison', variant: 'comparison' }
              the dashboard path has no chart-type exclusion eitherDatasetWidget.tsx:759 — widget types scatter and bubble both map to chartType: 'scatter' (377)
              ⚠️ today's picture on that path is already wrongthe overlay reads y through the single YAxis dataKey={scatterYKey} = series[0].dataKey, so "previous period" is painted exactly on "current" — the same defect #7194 fixes

              ⇒ Exempting the overlay in the renderer would restore that wrong picture. The PR is right about that. The question is whether refusing is what B meant.

              Why the ruling's own text does not settle it

              The literal predicate ("two or more series") does reach it. But the ruling's stated premise"zero authored scatters in-repo, so the capability waits for a real caller" — was measured on chartType: 'scatter' literals. A compare-to scatter is one authored series plus one synthesised overlay from a documented product feature. It is not an authored two-series scatter, and the census that justified B cannot see it.

              ⚠️ The PR currently resolves that gap by itself: its pin comment reads "The ruling counts series, not variants" — the implementer's reading, not the ruling's words — and its changeset records it as settled ("This applies to a compareTo overlay too"). That is what the review requires be undone until this card rules.

              ⭐ A second defect on that path, independent of which way Q1 goes

              Ruling B requires the refusal name "the authored fix". On the compare-to path the tile says:

              Keep exactly one series: amount, amount__comparison

              The author has exactly one series in their spec and never wroteamount__comparison. The named fix is not applicable, and the real fix ("remove compareTo") is unknowable at the renderer, which only sees series. ⇒ Even a confirmed refusal needs its copy or its refusal site changed on this path. A refusal that misdirects the author is worse than the wrong picture it replaces, because it costs a session to disprove.

              The shapes (recorded, not recommended)

              (a) Confirm — a compare-to scatter refuses. Then the copy or the refusal site must name the actual authored fix there — e.g. raise it upstream in ObjectChart / DatasetWidget where compareTo is known, or add a compare-to-aware sentence. ⚠️ Note the primary series, which drew correctly, is also lost from that tile.

              (b) Exclude scatter from compareTo, exactly as pie / donut / funnel already are and as the CHANGELOG already publishes for them: the primary draws, the overlay is never synthesised, the renderer's guard is never reached in product, and the PR's pin inverts. ⚠️ Touches packages/plugin-dashboard — outside PR #7400's declared file surface — and changes a published statement.

              (c) Project the overlay only — option A territory, which the ruling explicitly declined.

              Reachability, stated honestly

              0 in-repo instances. The reviewer widened the census beyond the PR's own regex to the dashboard-widget spelling (type: 'scatter' | 'bubble'), which the PR's pattern cannot see: still 0, with a control (type: 'bar') firing at 10 files including five examples/schema-catalog/**/plugin-dashboard/*.json. So the zero holds on a stronger basis than the PR claimed. ⚠️ But it is authorable today through both surfaces, and incidence in cloud tenant metadata is unmeasurable — the decision card for #7194 said so. ⛔ Unmeasured incidence is not low incidence.

              四维分析

              长期健全性 —— 一个已发布的能力(scatter 上的 compareTo,CHANGELOG 明写只有 pie/donut/funnel 忽略它,且代码里有 scatter 专属的 comparisonStyle 分支)被一条从未点名它的拒绝裁决顺带吃掉,这正是"裁决"二字被稀释的方式:下一次读这条裁决的人会以为它裁过 compareTo,而它没有。⚠️ 反向也成立:今天那条路径画的是错的图(叠加层被画在主序列的 y 上),(b) 保留能力就等于知情地继续画错。⇒ 本轴不指向某个选项,它指向"必须显式裁",而不是由实现者的一句 pin 注释代裁。

              真实业务需求 —— 仓内 0 例(复审员用更强的对照重测过,对照命中 10 个文件,所以这个 0 是读数)。⚠️ 但两条产品路径今天都能写出来,云端租户元数据里的实际发生率测不到。⇒ 需求侧给不出方向,只能说明"不紧急",不能说明"可以默认"。

              让 AI 写的代码不易出错 —— 这一轴最尖锐,且与 Q1 怎么裁无关:当前拒绝面对作者说「Keep exactly one series: amount, amount__comparison」,而作者的 spec 里只有一个 series,amount__comparison 是系统合成的、他从没写过。⇒ 这是一条指向不存在的写法的拒绝 —— 比它所替代的错图更贵,因为错图至少能被看出来,而错误的修复指引会把人送去改一个不存在的字段。无论 (a) 还是 (b),这一条都必须修。

              创业公司范围纪律 —— (a) 最省,只动本 PR 的文案/拒绝位;(b) 要动 packages/plugin-dashboard,超出本 PR 已申报的文件面,并且要改一句已发布的 CHANGELOG 陈述;(c) 是裁决已明确不做的 option A。⇒ 本轴偏向 (a),但它是四轴里最弱的一条,⛔ 不足以单独决定一个已发布能力的去留。

              Status

              PR #7400 keeps needs:contract-review and stays draft. The review's verdict is PASS WITH REQUIRED AMENDMENTS; the amendment tied to this card is "do not land the compareTo behaviour as decided until Q1 is answered". #7194 is now blocked on this card in addition to #7399⚠️two independent decisions, one about bytes and one about scope; either alone does not release it.

              Related

              #7194 (the card and ruling B) · PR #7400 · #7399 (the other, unrelated decision blocking the same PR) · #7113 (the authoring-time zod refusal this deliberately does not pre-empt) · #7146 / #7147 / #7148 (the refusal shell precedents)

              Metadata

              Metadata

              Assignees

              No one assigned

                Type

                No type

                Projects

                No projects

                  Milestone

                  No milestone

                  Relationships

                  None yet

                  Development

                  No branches or pull requests

                  Issue actions

                  , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
                  Skip to content

                  [Decision] Does #7194's ruling B reach a compareTo scatter — a published capability it never named? The refusal currently swallows it and names a fix the author cannot act on #7402

                  Description

                  @os-project-manager

                  Filed by the domain:ui execution seat (PM session session_01EMrWaQw3XS5DxTHxp4yRyC) on the finding of an in-seat contract review at CONTRACT_REVIEW_TIER (claude-fable-5) of PR #7400. ⛔ Not graded and no domain:* — routing, type and priority are the triage seat's.

                  ⭐ This is the reviewer's Q1, raised explicitly as "the maintainer's question, not the PM's or mine". The seat is not answering it, and the reviewer deliberately did not either. It is separate from #7399 (that one is the byte ceiling); this one is about ruling scope and a published capability.

                  The question

                  #7194 ruled B — a scatter with two or more series refuses. Verbatim, from the ruling (comment 5507673384):

                  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.

                  ⚠️Neither the ruling nor the decision card it adopted mentions compareTo or variant.

                  But a compare-to scatter is a two-series scatter in the product, so the refusal swallows it.

                  Verified on PR #7400's head eacc559

                  factevidence
                  scatter is on the published compare-to listpackages/plugin-charts/CHANGELOG.md:1727"overlay a muted comparison-period series… Pie / donut / funnel ignore compareTo" ⇒ scatter does not
                  it was designed, not incidentalcomparisonStyle(s, kind) (AdvancedChartImpl.tsx:92) has a scatter-specific opacity branch, and the base scatter arm already calls comparisonStyle(s, 'scatter')
                  the overlay is synthesised as a second seriesObjectChart.tsx:338supportsCompareTo excludes only pie/donut/funnel; augmentedSeries (815) appends { dataKey: '…__comparison', variant: 'comparison' }
                  the dashboard path has no chart-type exclusion eitherDatasetWidget.tsx:759 — widget types scatter and bubble both map to chartType: 'scatter' (377)
                  ⚠️ today's picture on that path is already wrongthe overlay reads y through the single YAxis dataKey={scatterYKey} = series[0].dataKey, so "previous period" is painted exactly on "current" — the same defect #7194 fixes

                  ⇒ Exempting the overlay in the renderer would restore that wrong picture. The PR is right about that. The question is whether refusing is what B meant.

                  Why the ruling's own text does not settle it

                  The literal predicate ("two or more series") does reach it. But the ruling's stated premise"zero authored scatters in-repo, so the capability waits for a real caller" — was measured on chartType: 'scatter' literals. A compare-to scatter is one authored series plus one synthesised overlay from a documented product feature. It is not an authored two-series scatter, and the census that justified B cannot see it.

                  ⚠️ The PR currently resolves that gap by itself: its pin comment reads "The ruling counts series, not variants" — the implementer's reading, not the ruling's words — and its changeset records it as settled ("This applies to a compareTo overlay too"). That is what the review requires be undone until this card rules.

                  ⭐ A second defect on that path, independent of which way Q1 goes

                  Ruling B requires the refusal name "the authored fix". On the compare-to path the tile says:

                  Keep exactly one series: amount, amount__comparison

                  The author has exactly one series in their spec and never wroteamount__comparison. The named fix is not applicable, and the real fix ("remove compareTo") is unknowable at the renderer, which only sees series. ⇒ Even a confirmed refusal needs its copy or its refusal site changed on this path. A refusal that misdirects the author is worse than the wrong picture it replaces, because it costs a session to disprove.

                  The shapes (recorded, not recommended)

                  (a) Confirm — a compare-to scatter refuses. Then the copy or the refusal site must name the actual authored fix there — e.g. raise it upstream in ObjectChart / DatasetWidget where compareTo is known, or add a compare-to-aware sentence. ⚠️ Note the primary series, which drew correctly, is also lost from that tile.

                  (b) Exclude scatter from compareTo, exactly as pie / donut / funnel already are and as the CHANGELOG already publishes for them: the primary draws, the overlay is never synthesised, the renderer's guard is never reached in product, and the PR's pin inverts. ⚠️ Touches packages/plugin-dashboard — outside PR #7400's declared file surface — and changes a published statement.

                  (c) Project the overlay only — option A territory, which the ruling explicitly declined.

                  Reachability, stated honestly

                  0 in-repo instances. The reviewer widened the census beyond the PR's own regex to the dashboard-widget spelling (type: 'scatter' | 'bubble'), which the PR's pattern cannot see: still 0, with a control (type: 'bar') firing at 10 files including five examples/schema-catalog/**/plugin-dashboard/*.json. So the zero holds on a stronger basis than the PR claimed. ⚠️ But it is authorable today through both surfaces, and incidence in cloud tenant metadata is unmeasurable — the decision card for #7194 said so. ⛔ Unmeasured incidence is not low incidence.

                  四维分析

                  长期健全性 —— 一个已发布的能力(scatter 上的 compareTo,CHANGELOG 明写只有 pie/donut/funnel 忽略它,且代码里有 scatter 专属的 comparisonStyle 分支)被一条从未点名它的拒绝裁决顺带吃掉,这正是"裁决"二字被稀释的方式:下一次读这条裁决的人会以为它裁过 compareTo,而它没有。⚠️ 反向也成立:今天那条路径画的是错的图(叠加层被画在主序列的 y 上),(b) 保留能力就等于知情地继续画错。⇒ 本轴不指向某个选项,它指向"必须显式裁",而不是由实现者的一句 pin 注释代裁。

                  真实业务需求 —— 仓内 0 例(复审员用更强的对照重测过,对照命中 10 个文件,所以这个 0 是读数)。⚠️ 但两条产品路径今天都能写出来,云端租户元数据里的实际发生率测不到。⇒ 需求侧给不出方向,只能说明"不紧急",不能说明"可以默认"。

                  让 AI 写的代码不易出错 —— 这一轴最尖锐,且与 Q1 怎么裁无关:当前拒绝面对作者说「Keep exactly one series: amount, amount__comparison」,而作者的 spec 里只有一个 series,amount__comparison 是系统合成的、他从没写过。⇒ 这是一条指向不存在的写法的拒绝 —— 比它所替代的错图更贵,因为错图至少能被看出来,而错误的修复指引会把人送去改一个不存在的字段。无论 (a) 还是 (b),这一条都必须修。

                  创业公司范围纪律 —— (a) 最省,只动本 PR 的文案/拒绝位;(b) 要动 packages/plugin-dashboard,超出本 PR 已申报的文件面,并且要改一句已发布的 CHANGELOG 陈述;(c) 是裁决已明确不做的 option A。⇒ 本轴偏向 (a),但它是四轴里最弱的一条,⛔ 不足以单独决定一个已发布能力的去留。

                  Status

                  PR #7400 keeps needs:contract-review and stays draft. The review's verdict is PASS WITH REQUIRED AMENDMENTS; the amendment tied to this card is "do not land the compareTo behaviour as decided until Q1 is answered". #7194 is now blocked on this card in addition to #7399⚠️two independent decisions, one about bytes and one about scope; either alone does not release it.

                  Related

                  #7194 (the card and ruling B) · PR #7400 · #7399 (the other, unrelated decision blocking the same PR) · #7113 (the authoring-time zod refusal this deliberately does not pre-empt) · #7146 / #7147 / #7148 (the refusal shell precedents)

                  Metadata

                  Metadata

                  Assignees

                  No one assigned

                    Type

                    No type

                    Projects

                    No projects

                      Milestone

                      No milestone

                      Relationships

                      None yet

                      Development

                      No branches or pull requests

                      Issue actions

                      , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
                      Skip to content

                      [Decision] Does #7194's ruling B reach a compareTo scatter — a published capability it never named? The refusal currently swallows it and names a fix the author cannot act on #7402

                      Description

                      @os-project-manager

                      Filed by the domain:ui execution seat (PM session session_01EMrWaQw3XS5DxTHxp4yRyC) on the finding of an in-seat contract review at CONTRACT_REVIEW_TIER (claude-fable-5) of PR #7400. ⛔ Not graded and no domain:* — routing, type and priority are the triage seat's.

                      ⭐ This is the reviewer's Q1, raised explicitly as "the maintainer's question, not the PM's or mine". The seat is not answering it, and the reviewer deliberately did not either. It is separate from #7399 (that one is the byte ceiling); this one is about ruling scope and a published capability.

                      The question

                      #7194 ruled B — a scatter with two or more series refuses. Verbatim, from the ruling (comment 5507673384):

                      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.

                      ⚠️Neither the ruling nor the decision card it adopted mentions compareTo or variant.

                      But a compare-to scatter is a two-series scatter in the product, so the refusal swallows it.

                      Verified on PR #7400's head eacc559

                      factevidence
                      scatter is on the published compare-to listpackages/plugin-charts/CHANGELOG.md:1727"overlay a muted comparison-period series… Pie / donut / funnel ignore compareTo" ⇒ scatter does not
                      it was designed, not incidentalcomparisonStyle(s, kind) (AdvancedChartImpl.tsx:92) has a scatter-specific opacity branch, and the base scatter arm already calls comparisonStyle(s, 'scatter')
                      the overlay is synthesised as a second seriesObjectChart.tsx:338supportsCompareTo excludes only pie/donut/funnel; augmentedSeries (815) appends { dataKey: '…__comparison', variant: 'comparison' }
                      the dashboard path has no chart-type exclusion eitherDatasetWidget.tsx:759 — widget types scatter and bubble both map to chartType: 'scatter' (377)
                      ⚠️ today's picture on that path is already wrongthe overlay reads y through the single YAxis dataKey={scatterYKey} = series[0].dataKey, so "previous period" is painted exactly on "current" — the same defect #7194 fixes

                      ⇒ Exempting the overlay in the renderer would restore that wrong picture. The PR is right about that. The question is whether refusing is what B meant.

                      Why the ruling's own text does not settle it

                      The literal predicate ("two or more series") does reach it. But the ruling's stated premise"zero authored scatters in-repo, so the capability waits for a real caller" — was measured on chartType: 'scatter' literals. A compare-to scatter is one authored series plus one synthesised overlay from a documented product feature. It is not an authored two-series scatter, and the census that justified B cannot see it.

                      ⚠️ The PR currently resolves that gap by itself: its pin comment reads "The ruling counts series, not variants" — the implementer's reading, not the ruling's words — and its changeset records it as settled ("This applies to a compareTo overlay too"). That is what the review requires be undone until this card rules.

                      ⭐ A second defect on that path, independent of which way Q1 goes

                      Ruling B requires the refusal name "the authored fix". On the compare-to path the tile says:

                      Keep exactly one series: amount, amount__comparison

                      The author has exactly one series in their spec and never wroteamount__comparison. The named fix is not applicable, and the real fix ("remove compareTo") is unknowable at the renderer, which only sees series. ⇒ Even a confirmed refusal needs its copy or its refusal site changed on this path. A refusal that misdirects the author is worse than the wrong picture it replaces, because it costs a session to disprove.

                      The shapes (recorded, not recommended)

                      (a) Confirm — a compare-to scatter refuses. Then the copy or the refusal site must name the actual authored fix there — e.g. raise it upstream in ObjectChart / DatasetWidget where compareTo is known, or add a compare-to-aware sentence. ⚠️ Note the primary series, which drew correctly, is also lost from that tile.

                      (b) Exclude scatter from compareTo, exactly as pie / donut / funnel already are and as the CHANGELOG already publishes for them: the primary draws, the overlay is never synthesised, the renderer's guard is never reached in product, and the PR's pin inverts. ⚠️ Touches packages/plugin-dashboard — outside PR #7400's declared file surface — and changes a published statement.

                      (c) Project the overlay only — option A territory, which the ruling explicitly declined.

                      Reachability, stated honestly

                      0 in-repo instances. The reviewer widened the census beyond the PR's own regex to the dashboard-widget spelling (type: 'scatter' | 'bubble'), which the PR's pattern cannot see: still 0, with a control (type: 'bar') firing at 10 files including five examples/schema-catalog/**/plugin-dashboard/*.json. So the zero holds on a stronger basis than the PR claimed. ⚠️ But it is authorable today through both surfaces, and incidence in cloud tenant metadata is unmeasurable — the decision card for #7194 said so. ⛔ Unmeasured incidence is not low incidence.

                      四维分析

                      长期健全性 —— 一个已发布的能力(scatter 上的 compareTo,CHANGELOG 明写只有 pie/donut/funnel 忽略它,且代码里有 scatter 专属的 comparisonStyle 分支)被一条从未点名它的拒绝裁决顺带吃掉,这正是"裁决"二字被稀释的方式:下一次读这条裁决的人会以为它裁过 compareTo,而它没有。⚠️ 反向也成立:今天那条路径画的是错的图(叠加层被画在主序列的 y 上),(b) 保留能力就等于知情地继续画错。⇒ 本轴不指向某个选项,它指向"必须显式裁",而不是由实现者的一句 pin 注释代裁。

                      真实业务需求 —— 仓内 0 例(复审员用更强的对照重测过,对照命中 10 个文件,所以这个 0 是读数)。⚠️ 但两条产品路径今天都能写出来,云端租户元数据里的实际发生率测不到。⇒ 需求侧给不出方向,只能说明"不紧急",不能说明"可以默认"。

                      让 AI 写的代码不易出错 —— 这一轴最尖锐,且与 Q1 怎么裁无关:当前拒绝面对作者说「Keep exactly one series: amount, amount__comparison」,而作者的 spec 里只有一个 series,amount__comparison 是系统合成的、他从没写过。⇒ 这是一条指向不存在的写法的拒绝 —— 比它所替代的错图更贵,因为错图至少能被看出来,而错误的修复指引会把人送去改一个不存在的字段。无论 (a) 还是 (b),这一条都必须修。

                      创业公司范围纪律 —— (a) 最省,只动本 PR 的文案/拒绝位;(b) 要动 packages/plugin-dashboard,超出本 PR 已申报的文件面,并且要改一句已发布的 CHANGELOG 陈述;(c) 是裁决已明确不做的 option A。⇒ 本轴偏向 (a),但它是四轴里最弱的一条,⛔ 不足以单独决定一个已发布能力的去留。

                      Status

                      PR #7400 keeps needs:contract-review and stays draft. The review's verdict is PASS WITH REQUIRED AMENDMENTS; the amendment tied to this card is "do not land the compareTo behaviour as decided until Q1 is answered". #7194 is now blocked on this card in addition to #7399⚠️two independent decisions, one about bytes and one about scope; either alone does not release it.

                      Related

                      #7194 (the card and ruling B) · PR #7400 · #7399 (the other, unrelated decision blocking the same PR) · #7113 (the authoring-time zod refusal this deliberately does not pre-empt) · #7146 / #7147 / #7148 (the refusal shell precedents)

                      Metadata

                      Metadata

                      Assignees

                      No one assigned

                        Type

                        No type

                        Projects

                        No projects

                          Milestone

                          No milestone

                          Relationships

                          None yet

                          Development

                          No branches or pull requests

                          Issue actions

                          , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
                          Skip to content

                          [Decision] Does #7194's ruling B reach a compareTo scatter — a published capability it never named? The refusal currently swallows it and names a fix the author cannot act on #7402

                          Description

                          @os-project-manager

                          Filed by the domain:ui execution seat (PM session session_01EMrWaQw3XS5DxTHxp4yRyC) on the finding of an in-seat contract review at CONTRACT_REVIEW_TIER (claude-fable-5) of PR #7400. ⛔ Not graded and no domain:* — routing, type and priority are the triage seat's.

                          ⭐ This is the reviewer's Q1, raised explicitly as "the maintainer's question, not the PM's or mine". The seat is not answering it, and the reviewer deliberately did not either. It is separate from #7399 (that one is the byte ceiling); this one is about ruling scope and a published capability.

                          The question

                          #7194 ruled B — a scatter with two or more series refuses. Verbatim, from the ruling (comment 5507673384):

                          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.

                          ⚠️Neither the ruling nor the decision card it adopted mentions compareTo or variant.

                          But a compare-to scatter is a two-series scatter in the product, so the refusal swallows it.

                          Verified on PR #7400's head eacc559

                          factevidence
                          scatter is on the published compare-to listpackages/plugin-charts/CHANGELOG.md:1727"overlay a muted comparison-period series… Pie / donut / funnel ignore compareTo" ⇒ scatter does not
                          it was designed, not incidentalcomparisonStyle(s, kind) (AdvancedChartImpl.tsx:92) has a scatter-specific opacity branch, and the base scatter arm already calls comparisonStyle(s, 'scatter')
                          the overlay is synthesised as a second seriesObjectChart.tsx:338supportsCompareTo excludes only pie/donut/funnel; augmentedSeries (815) appends { dataKey: '…__comparison', variant: 'comparison' }
                          the dashboard path has no chart-type exclusion eitherDatasetWidget.tsx:759 — widget types scatter and bubble both map to chartType: 'scatter' (377)
                          ⚠️ today's picture on that path is already wrongthe overlay reads y through the single YAxis dataKey={scatterYKey} = series[0].dataKey, so "previous period" is painted exactly on "current" — the same defect #7194 fixes

                          ⇒ Exempting the overlay in the renderer would restore that wrong picture. The PR is right about that. The question is whether refusing is what B meant.

                          Why the ruling's own text does not settle it

                          The literal predicate ("two or more series") does reach it. But the ruling's stated premise"zero authored scatters in-repo, so the capability waits for a real caller" — was measured on chartType: 'scatter' literals. A compare-to scatter is one authored series plus one synthesised overlay from a documented product feature. It is not an authored two-series scatter, and the census that justified B cannot see it.

                          ⚠️ The PR currently resolves that gap by itself: its pin comment reads "The ruling counts series, not variants" — the implementer's reading, not the ruling's words — and its changeset records it as settled ("This applies to a compareTo overlay too"). That is what the review requires be undone until this card rules.

                          ⭐ A second defect on that path, independent of which way Q1 goes

                          Ruling B requires the refusal name "the authored fix". On the compare-to path the tile says:

                          Keep exactly one series: amount, amount__comparison

                          The author has exactly one series in their spec and never wroteamount__comparison. The named fix is not applicable, and the real fix ("remove compareTo") is unknowable at the renderer, which only sees series. ⇒ Even a confirmed refusal needs its copy or its refusal site changed on this path. A refusal that misdirects the author is worse than the wrong picture it replaces, because it costs a session to disprove.

                          The shapes (recorded, not recommended)

                          (a) Confirm — a compare-to scatter refuses. Then the copy or the refusal site must name the actual authored fix there — e.g. raise it upstream in ObjectChart / DatasetWidget where compareTo is known, or add a compare-to-aware sentence. ⚠️ Note the primary series, which drew correctly, is also lost from that tile.

                          (b) Exclude scatter from compareTo, exactly as pie / donut / funnel already are and as the CHANGELOG already publishes for them: the primary draws, the overlay is never synthesised, the renderer's guard is never reached in product, and the PR's pin inverts. ⚠️ Touches packages/plugin-dashboard — outside PR #7400's declared file surface — and changes a published statement.

                          (c) Project the overlay only — option A territory, which the ruling explicitly declined.

                          Reachability, stated honestly

                          0 in-repo instances. The reviewer widened the census beyond the PR's own regex to the dashboard-widget spelling (type: 'scatter' | 'bubble'), which the PR's pattern cannot see: still 0, with a control (type: 'bar') firing at 10 files including five examples/schema-catalog/**/plugin-dashboard/*.json. So the zero holds on a stronger basis than the PR claimed. ⚠️ But it is authorable today through both surfaces, and incidence in cloud tenant metadata is unmeasurable — the decision card for #7194 said so. ⛔ Unmeasured incidence is not low incidence.

                          四维分析

                          长期健全性 —— 一个已发布的能力(scatter 上的 compareTo,CHANGELOG 明写只有 pie/donut/funnel 忽略它,且代码里有 scatter 专属的 comparisonStyle 分支)被一条从未点名它的拒绝裁决顺带吃掉,这正是"裁决"二字被稀释的方式:下一次读这条裁决的人会以为它裁过 compareTo,而它没有。⚠️ 反向也成立:今天那条路径画的是错的图(叠加层被画在主序列的 y 上),(b) 保留能力就等于知情地继续画错。⇒ 本轴不指向某个选项,它指向"必须显式裁",而不是由实现者的一句 pin 注释代裁。

                          真实业务需求 —— 仓内 0 例(复审员用更强的对照重测过,对照命中 10 个文件,所以这个 0 是读数)。⚠️ 但两条产品路径今天都能写出来,云端租户元数据里的实际发生率测不到。⇒ 需求侧给不出方向,只能说明"不紧急",不能说明"可以默认"。

                          让 AI 写的代码不易出错 —— 这一轴最尖锐,且与 Q1 怎么裁无关:当前拒绝面对作者说「Keep exactly one series: amount, amount__comparison」,而作者的 spec 里只有一个 series,amount__comparison 是系统合成的、他从没写过。⇒ 这是一条指向不存在的写法的拒绝 —— 比它所替代的错图更贵,因为错图至少能被看出来,而错误的修复指引会把人送去改一个不存在的字段。无论 (a) 还是 (b),这一条都必须修。

                          创业公司范围纪律 —— (a) 最省,只动本 PR 的文案/拒绝位;(b) 要动 packages/plugin-dashboard,超出本 PR 已申报的文件面,并且要改一句已发布的 CHANGELOG 陈述;(c) 是裁决已明确不做的 option A。⇒ 本轴偏向 (a),但它是四轴里最弱的一条,⛔ 不足以单独决定一个已发布能力的去留。

                          Status

                          PR #7400 keeps needs:contract-review and stays draft. The review's verdict is PASS WITH REQUIRED AMENDMENTS; the amendment tied to this card is "do not land the compareTo behaviour as decided until Q1 is answered". #7194 is now blocked on this card in addition to #7399⚠️two independent decisions, one about bytes and one about scope; either alone does not release it.

                          Related

                          #7194 (the card and ruling B) · PR #7400 · #7399 (the other, unrelated decision blocking the same PR) · #7113 (the authoring-time zod refusal this deliberately does not pre-empt) · #7146 / #7147 / #7148 (the refusal shell precedents)

                          Metadata

                          Metadata

                          Assignees

                          No one assigned

                            Type

                            No type

                            Projects

                            No projects

                              Milestone

                              No milestone

                              Relationships

                              None yet

                              Development

                              No branches or pull requests

                              Issue actions

                              , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
                              Skip to content

                              [Decision] Does #7194's ruling B reach a compareTo scatter — a published capability it never named? The refusal currently swallows it and names a fix the author cannot act on #7402

                              Description

                              @os-project-manager

                              Filed by the domain:ui execution seat (PM session session_01EMrWaQw3XS5DxTHxp4yRyC) on the finding of an in-seat contract review at CONTRACT_REVIEW_TIER (claude-fable-5) of PR #7400. ⛔ Not graded and no domain:* — routing, type and priority are the triage seat's.

                              ⭐ This is the reviewer's Q1, raised explicitly as "the maintainer's question, not the PM's or mine". The seat is not answering it, and the reviewer deliberately did not either. It is separate from #7399 (that one is the byte ceiling); this one is about ruling scope and a published capability.

                              The question

                              #7194 ruled B — a scatter with two or more series refuses. Verbatim, from the ruling (comment 5507673384):

                              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.

                              ⚠️Neither the ruling nor the decision card it adopted mentions compareTo or variant.

                              But a compare-to scatter is a two-series scatter in the product, so the refusal swallows it.

                              Verified on PR #7400's head eacc559

                              factevidence
                              scatter is on the published compare-to listpackages/plugin-charts/CHANGELOG.md:1727"overlay a muted comparison-period series… Pie / donut / funnel ignore compareTo" ⇒ scatter does not
                              it was designed, not incidentalcomparisonStyle(s, kind) (AdvancedChartImpl.tsx:92) has a scatter-specific opacity branch, and the base scatter arm already calls comparisonStyle(s, 'scatter')
                              the overlay is synthesised as a second seriesObjectChart.tsx:338supportsCompareTo excludes only pie/donut/funnel; augmentedSeries (815) appends { dataKey: '…__comparison', variant: 'comparison' }
                              the dashboard path has no chart-type exclusion eitherDatasetWidget.tsx:759 — widget types scatter and bubble both map to chartType: 'scatter' (377)
                              ⚠️ today's picture on that path is already wrongthe overlay reads y through the single YAxis dataKey={scatterYKey} = series[0].dataKey, so "previous period" is painted exactly on "current" — the same defect #7194 fixes

                              ⇒ Exempting the overlay in the renderer would restore that wrong picture. The PR is right about that. The question is whether refusing is what B meant.

                              Why the ruling's own text does not settle it

                              The literal predicate ("two or more series") does reach it. But the ruling's stated premise"zero authored scatters in-repo, so the capability waits for a real caller" — was measured on chartType: 'scatter' literals. A compare-to scatter is one authored series plus one synthesised overlay from a documented product feature. It is not an authored two-series scatter, and the census that justified B cannot see it.

                              ⚠️ The PR currently resolves that gap by itself: its pin comment reads "The ruling counts series, not variants" — the implementer's reading, not the ruling's words — and its changeset records it as settled ("This applies to a compareTo overlay too"). That is what the review requires be undone until this card rules.

                              ⭐ A second defect on that path, independent of which way Q1 goes

                              Ruling B requires the refusal name "the authored fix". On the compare-to path the tile says:

                              Keep exactly one series: amount, amount__comparison

                              The author has exactly one series in their spec and never wroteamount__comparison. The named fix is not applicable, and the real fix ("remove compareTo") is unknowable at the renderer, which only sees series. ⇒ Even a confirmed refusal needs its copy or its refusal site changed on this path. A refusal that misdirects the author is worse than the wrong picture it replaces, because it costs a session to disprove.

                              The shapes (recorded, not recommended)

                              (a) Confirm — a compare-to scatter refuses. Then the copy or the refusal site must name the actual authored fix there — e.g. raise it upstream in ObjectChart / DatasetWidget where compareTo is known, or add a compare-to-aware sentence. ⚠️ Note the primary series, which drew correctly, is also lost from that tile.

                              (b) Exclude scatter from compareTo, exactly as pie / donut / funnel already are and as the CHANGELOG already publishes for them: the primary draws, the overlay is never synthesised, the renderer's guard is never reached in product, and the PR's pin inverts. ⚠️ Touches packages/plugin-dashboard — outside PR #7400's declared file surface — and changes a published statement.

                              (c) Project the overlay only — option A territory, which the ruling explicitly declined.

                              Reachability, stated honestly

                              0 in-repo instances. The reviewer widened the census beyond the PR's own regex to the dashboard-widget spelling (type: 'scatter' | 'bubble'), which the PR's pattern cannot see: still 0, with a control (type: 'bar') firing at 10 files including five examples/schema-catalog/**/plugin-dashboard/*.json. So the zero holds on a stronger basis than the PR claimed. ⚠️ But it is authorable today through both surfaces, and incidence in cloud tenant metadata is unmeasurable — the decision card for #7194 said so. ⛔ Unmeasured incidence is not low incidence.

                              四维分析

                              长期健全性 —— 一个已发布的能力(scatter 上的 compareTo,CHANGELOG 明写只有 pie/donut/funnel 忽略它,且代码里有 scatter 专属的 comparisonStyle 分支)被一条从未点名它的拒绝裁决顺带吃掉,这正是"裁决"二字被稀释的方式:下一次读这条裁决的人会以为它裁过 compareTo,而它没有。⚠️ 反向也成立:今天那条路径画的是错的图(叠加层被画在主序列的 y 上),(b) 保留能力就等于知情地继续画错。⇒ 本轴不指向某个选项,它指向"必须显式裁",而不是由实现者的一句 pin 注释代裁。

                              真实业务需求 —— 仓内 0 例(复审员用更强的对照重测过,对照命中 10 个文件,所以这个 0 是读数)。⚠️ 但两条产品路径今天都能写出来,云端租户元数据里的实际发生率测不到。⇒ 需求侧给不出方向,只能说明"不紧急",不能说明"可以默认"。

                              让 AI 写的代码不易出错 —— 这一轴最尖锐,且与 Q1 怎么裁无关:当前拒绝面对作者说「Keep exactly one series: amount, amount__comparison」,而作者的 spec 里只有一个 series,amount__comparison 是系统合成的、他从没写过。⇒ 这是一条指向不存在的写法的拒绝 —— 比它所替代的错图更贵,因为错图至少能被看出来,而错误的修复指引会把人送去改一个不存在的字段。无论 (a) 还是 (b),这一条都必须修。

                              创业公司范围纪律 —— (a) 最省,只动本 PR 的文案/拒绝位;(b) 要动 packages/plugin-dashboard,超出本 PR 已申报的文件面,并且要改一句已发布的 CHANGELOG 陈述;(c) 是裁决已明确不做的 option A。⇒ 本轴偏向 (a),但它是四轴里最弱的一条,⛔ 不足以单独决定一个已发布能力的去留。

                              Status

                              PR #7400 keeps needs:contract-review and stays draft. The review's verdict is PASS WITH REQUIRED AMENDMENTS; the amendment tied to this card is "do not land the compareTo behaviour as decided until Q1 is answered". #7194 is now blocked on this card in addition to #7399⚠️two independent decisions, one about bytes and one about scope; either alone does not release it.

                              Related

                              #7194 (the card and ruling B) · PR #7400 · #7399 (the other, unrelated decision blocking the same PR) · #7113 (the authoring-time zod refusal this deliberately does not pre-empt) · #7146 / #7147 / #7148 (the refusal shell precedents)

                              Metadata

                              Metadata

                              Assignees

                              No one assigned

                                Type

                                No type

                                Projects

                                No projects

                                  Milestone

                                  No milestone

                                  Relationships

                                  None yet

                                  Development

                                  No branches or pull requests

                                  Issue actions