finding(plugin-charts): after objectui#7681 the renderer honours series[].type on a dataKey entry, but ChartRendererProps' TS union still declares it only on the name arm — declared < enforced

Ruled: 5809905710 · letter align (TS union declares what the schema accepts) · 2026-09-24T07:41Z

Filed unassigned and ungraded by the domain:ui execution seat (session_01YBWFb5YgMU5dw8p2VKj16S) at 2026-09-06, while reviewing PR #8080. ⛔ This seat produces no domain:* or grade; triage owns routing.

Filed because PR #8080 deliberately declined to fix it, and declining was the right call — but a docblock note is not a tracked card.

The gap

objectui#7681 / PR #8080 routes every series array through the one normalization layer, so ChartDataSeries.type (the declared per-series family override, maintainer ruling 2026-08-25 on objectui#6121) is now honoured on the internal dataKey binding as well as the name binding. That was the fix, and it is correct.

ChartRendererProps.series in packages/plugin-charts/src/ChartRenderer.tsx still declares a two-arm union where:

the dataKey arm has chartType but no type
the name arm has type but no chartType

⇒ At runtime a dataKey-shaped entry now accepts type. In TypeScript it does not. The new regression pin in ChartRenderer.specSeries.test.tsx has to write as any to express the very case the card exists to fix — which is the symptom worth reading: a test that must escape the type system to describe supported behaviour is reporting a declaration gap.

This is declared < enforced — the mirror of the more familiar direction. It is not dangerous the way declared > enforced is (nothing silently fails), but it is still a published surface that under-describes what it accepts, and a TS consumer cannot write the supported thing without an escape hatch.

⛔ Why PR #8080 correctly left it alone

Quoting the docblock that PR added:

This TS union stays as declared … at RUNTIME type is honoured on a dataKey-shaped entry too (objectui#7681, both keys are independently optional on ChartDataSeriesSchema), because JSON metadata never goes through this TS type. Widening the arm to match is a separate, public-face decision this fix does not make.

⭐ That reasoning is right and should not be re-argued: widening the arm enlarges a published type's accept set, which is the mechanical boundary test for Clause-② and would have needed contract-review tier. Smuggling it into a bug fix would have been the wrong shape. ⛔ Whoever takes this card should expect it to be contract-review work, not a tidy.

⚠️ Note the live governance question: whether Clause-② is directional is itself unsettled and filed as objectstack-ai/objectstack#16349. This card is on the uncontroversial side of that — widening a published type's accept set triggers Clause-② under either reading. ⇒ ⛔ Do not wait on #16349 to route this one.

The options, not chosen here

Widen the dataKey arm with type?: ... so the declaration matches what the renderer accepts. Simplest, and matches ChartDataSeriesSchema, where both keys are independently optional.
Collapse the two arms into one shape carrying both dataKey? and name?. Closer to what the schema actually says, but a larger public-face change with more consumer breakage risk.
Deliberately keep the union narrow and document type-on-dataKey as metadata-only (JSON never goes through this TS type). ⚠️ Costs the TS consumer the ability to express it, and leaves the test's as any as the standing evidence of the gap.

⛔ This card does not choose — the accept-set direction makes it a decision, not a repair.

Dedup

Adjacent and checked: objectui#7681 (the fix that produced this), objectui#6121 (the ruling that declared ChartDataSeries.type), objectui#2945 (the fast path #7681 removed), objectui#7682 (series variant carrying three different unions across declarations and readers — the nearest neighbour, and ⛔ a different key), objectui#7690 (the undeclared axis-config dialect). ⚠️ Bounded reading, ⛔ not an exhaustive state=all sweep.

Triage routing

Labels plugin package: plugin-charts finding domain:ui needs:contract-review pm:queue priority:p3 · Type Task

Lane — domain:ui. The declaration is ChartRendererProps in packages/plugin-charts/src/ChartRenderer.tsx — a published objectui library's own type, not a @objectstack/spec mirror row. ⛔ Not domain:spec.

needs:contract-review is a carrier, not a state. The card is right that this is contract-review work rather than a tidy, so the carrier goes on and the state stays pm:queue. ⛔ This seat does not adjudicate it — this session is claude-opus-5 and CONTRACT_REVIEW_TIER requires fable.

Re-measured on 83d4fda16 — confirmed, including the symptom the card leans on.

ChartRenderer.tsx:72 — the dataKey arm: { dataKey: string; label?; variant?; opacity?; dashArray?; chartType?: 'bar' | 'line' | 'area'; stack?; yAxis?; color? }. chartType present, type absent.
:64-66 — the docblock PR fix(plugin-charts): honour series[].type override on a dataKey-shaped series too #8080 added, verbatim as quoted: "This TS union stays as declared (the dataKey arm has no type, the name arm has no chartType): at RUNTIME type is honoured on a dataKey-shaped entry too (objectui#7681, both keys are independently optional …)".
ChartRenderer.specSeries.test.tsx — two as any escapes, at :133 and :165, with :122 naming why: "ChartRendererProps TS union (as any matches the schema's own …)". The card mentions one; there are two.

⭐ The card's own diagnostic is the strongest thing on it and I am promoting it to the grading rationale: a test that must escape the type system to describe supported behaviour is reporting a declaration gap. Two as any in a regression pin, both written to express the case the card exists to fix, is not incidental — it is the defect leaving a mark in the one place that was trying to nail the behaviour down.

Admission — class (b), violation of a declared contract, in the declared < enforced direction. The card is right that this is the less dangerous mirror: nothing silently fails, nothing is dropped. What it costs is that a TypeScript consumer cannot write a supported thing without an escape hatch, on a published surface that under-describes what it accepts.

Grade p3. No runtime defect, no silent loss, and JSON metadata never traverses this type at all — so the affected population is TS consumers of ChartRendererProps specifically. Re-grade to p2 if a consumer (in-repo or a dependent app) is found carrying an as any for this reason outside the test, which would show the gap is being paid for in product code rather than only in a pin.

⛔ Three fences, all from the card, all binding.

⛔ PR fix(plugin-charts): honour series[].type override on a dataKey-shaped series too #8080's decision not to fix this must not be re-argued. Widening the arm enlarges a published type's accept set, which is the mechanical boundary test for Clause-②. Smuggling it into a bug fix would have been the wrong shape, and declining was correct. Whoever takes this should expect contract-review work, not a tidy.
⛔ Do not wait on objectstack#16349. Whether Clause-② is directional is genuinely unsettled and filed there — but this card sits on the uncontroversial side of that question: widening a published type's accept set triggers Clause-② under either reading. Routing and claiming are unblocked; only the ruling is gated.
⛔ Not a defect in objectui#7681 / PR fix(plugin-charts): honour series[].type override on a dataKey-shaped series too #8080. That fix — routing every series array through one normalization layer so ChartDataSeries.type is honoured on the dataKey binding — is correct and stays. This card is its consequence, not its complaint.

On the three options. ⛔ Not choosing — the accept-set direction makes this a ruling, not a repair. One observation for whoever does rule: option 1 (widen the dataKey arm with type?) is the one that matches ChartDataSeriesSchema, where both keys are independently optional — so it aligns the TS face with a schema face that already says this. Option 3 (keep the union narrow, document type-on-dataKey as metadata-only) is a defensible answer but leaves the two as any standing as permanent evidence of a gap the repo has decided not to close; if it wins, say so in the test, so the escapes read as deliberate rather than as debt.

Dedup accepted as filed, and correctly self-limited (⚠️ bounded reading, ⛔ not an exhaustive state=all sweep). Adjacent cards checked and distinct: #7681, #6121, #2945, #7682 (⛔ a different key — series variant), #7690.

Triage seat only — no claim, no dispatch, no code, ⛔ no adjudication.

Generated by Claude Code

needs:contract-review retired from this card — director seat, summon #18 (session_017Js5kTpTtxieBjPyScgxJ3), 2026-09-09T00:52Z.

Reading before the write (00:45Z): no assignee, no Claim: comment, no PR referencing this card (closed_by_pull_requests 0). The label was applied by the triage comment 5583247287 (2026-09-08T10:00Z) with nothing to review. Ruling A on objectstack-ai/objectstack#16625 (comment 5572349104, maintainer 「同意」, 2026-09-07), as restated by objectstack PR #16698: the carrier is hung only with a reviewable increment — a draft PR, or the card in the same stroke as a Clause-②: yes claim — and a triage verdict records the clause-② direction in prose. Triage's direction (widening a published type's accept set ⇒ Clause-②: yes, contract-review tier) stays on this thread; the claim that takes this card re-hangs the carrier and the PR carries the second half.

⛔ State, priority, type and every other label untouched; labels read back after the write.

Generated by Claude Code

Tier notice — the contract-review-tier requirement on this issue is lifted (skills seat, session session_01MoTv7pn338AZ71owsp19gQ, 2026-09-10T03:14Z; record and rule-text change in flight: objectstack-ai/objectstack#17285).

Maintainer ruling, verbatim: 「现有的卡片如果写了要求fable的，也要让相关的项目经理知道，opus就够了。」 Under the same ruling set (quoted in full on objectstack-ai/objectstack#17285), the contract-review tier is reserved for the skills seat (protocol files + the published skills/**), the spec seat's clause-② review, and the maintainer-summoned director; triage and every other seat run the default tier.

For this card: the contract-review-tier build or review its thread asks for is no longer required. The lane seat's own default-tier review, plus the gates (widening tells, pin tests, dispatch-gates --tier), is the review of record, and the build stays at the default tier. Unchanged: the Clause-② declaration itself, the manual floor for widenings under 代裁, and the routing rule that a diff touching packages/spec goes to the spec seat, where the contract-review-tier review still applies. This comment changes no label, assignee or claim.

Generated by Claude Code

Ruling: UI closure batch 4 item 7 · letter align (the TS union declares what the schema and the renderer accept) · maintainer 「同意」 (chat, director seat summon #29, session_01EcrTi7s5oDYPHS4Pi7h31d) 2026-09-24T07:38Z

Thread re-read to its last comment (5612088841) in this act. Read on objectui origin/main 62597c5: packages/plugin-charts/src/ChartRenderer.tsx:73 has a dataKey arm with chartType but no type, and the name arm at :74 carries type. ChartDataSeriesSchema declares both keys independently optional, and the renderer honours type on a dataKey entry (objectui#7681).

Ruled: align. Add type to the dataKey arm, with the same member type as the name arm, so the published TS face states what the contract and the renderer accept. Drop the as any escapes in ChartRenderer.specSeries.test.tsx, and replace the docblock that PR #8080 added ("this TS union stays as declared…") with the aligned statement. ⛔ No other arm changes.

Execution: pm:queue · priority:p3 · domain:ui stand; a published type widens to its contract ⇒ Clause-②: yes.

Generated by Claude Code

Claim: PM loop round 4 — domain:ui execution seat 2
Session: session_014mXUNuFomfj24w7s1pZzhN
Branch: claude/issue-8086-chart-series-type-arm
Worktree: objectui-issue-8086
Domain: domain:ui
Seat: domain:ui#2
File surface: packages/plugin-charts/src/ChartRenderer.tsx (the series union's dataKey arm gains type, and its docblock is restated; no other arm or member), ChartRenderer.specSeries.test.tsx (the as any escapes the ruling names) with a type pin beside it, and one .changeset/8086-…md. Added by the seat after the dev report, because the change made their text false (prose only, no type change): a body comment in ChartRenderer.tsx (the normalizeSeries round-trip sentence), and the ObjectChartSchema.series docblock in packages/types/src/objectql.ts (near :4351). That region is hunk-disjoint from every open objectql.ts editor (stop on breach; explain in the report)
Container & model: S, mode:subagent, model: opus — dispatch-gates --tier: 「no path-derived mandate … floor sonnet · default opus · ceiling fable」; executes ruling 5809905710 (align)
Clause-②: yes
Thread-read: 5809905710
Serial constraints cleared: open-PR file lists read 2026-09-25T07:49Z: no open PR touches packages/plugin-charts/src/ (objectui#8941 and the release PR touch only package.json / CHANGELOG.md). Live pm:dispatched claims of seats 1, 3, 4 and 5 name no plugin-charts source file.

Clause-②: yes — a published TS union widens to what the schema and the renderer already accept (ruling).

Generated by Claude Code

os-dev-report

{
  "issue": 8086,
  "status": "done",
  "branch": "claude/issue-8086-chart-series-type-arm",
  "pr": "https://github.com/objectstack-ai/objectui/pull/10554",
  "session": "session_014mXUNuFomfj24w7s1pZzhN (mode:subagent, the dispatching seat's id)",
  "premise_still_valid": true,
  "summary": "Ruling 5809905710 (align) is done. The dataKey arm of ChartRendererProps.schema.series gains `type?: string`, the same member type the name arm has. No other member of either arm changes. The docblock PR #8080 added is replaced by the aligned statement, the specSeries case loses its `as any`, and a compile-time pin file sits next to it (ChartRenderer.seriesTypeArm-8086.test.ts). Hypotheses: H1 confirmed on origin/main d461b0de8. H2 done. H3 partly false: on the base declaration the `{ dataKey, type }` literal already compiled without the cast, because the union has no literal discriminant and TS checks excess properties against the whole union (type is known to the name arm). The cast is dropped anyway. The second `as any` covers `categories` (TS2353 without it), not series, so it stays with a comment saying why. H4: ChartRendererProps is not re-exported by name from the package entry. In the published 17.6.0 dist it is declared in dist/ChartRenderer.d.ts and used by the registry map type in dist/index.d.ts, and its dataKey arm has no type. The runtime half (objectui#7681) is still a pending changeset, so both ship in the same release. H5 is false at the union level: a pin written against the whole union passes on base, and a `{ name, chartType }` literal type-checks against the union on both base and head. The pins were therefore moved to each arm (the Extract of the union on its binding key). They are red on base and green on head, and the arm-level control holds on both sides. PR assignee is NOT set: the permission classifier refused label-write (see deviations). The seat needs to set it.",
  "tests": "HEAD ff726c28c. RED ON BASE (leg A): node ../objectstack/scripts/ablation-replace.mjs removed only `type?: string; ` from the dataKey arm in ChartRenderer.tsx (anchor 1 to 0, blob e0dac80c6e03 to ad7bb3165aac; restored: blob == HEAD e0dac80c6e03 and `git diff HEAD` empty; whole-tree `git status --porcelain` empty afterwards). Then `tsc -p tsconfig.test.json --listFiles` in packages/plugin-charts; the file list includes ChartRenderer.tsx, ChartRenderer.seriesTypeArm-8086.test.ts and ChartRenderer.specSeries.test.tsx. Output: 4 errors, all in ChartRenderer.seriesTypeArm-8086.test.ts: TS2339 `Property 'type' does not exist on type '{ dataKey: string; ... }'` (Equal pin), TS2353 `'type' does not exist in type '{ dataKey: string; ... }'` (value typed as the arm), TS2339 (reading it back), TS2339 (read after narrowing with 'dataKey' in e); TSC_EXIT=2. Zero errors in specSeries.test.tsx with the cast already removed (the H3 measurement). No TS2578 on the control @ts-expect-error. GREEN ON HEAD: plugin-charts `pnpm run type-check` (tsc --noEmit && tsc -p tsconfig.test.json) printed `VERDICT command-exit 0`. LEG B (the kept cast): removing the `categories` case's `as any` at HEAD gives TS2353 `'categories' does not exist in type '{ type: string; ... }'`, TSC_EXIT=2; restored, blob == HEAD 51ca5a85cd21. TESTS (repo-root form, run under os-verify-lock): `pnpm exec vitest run --maxWorkers=2 packages/plugin-charts/` gave `Test Files 73 passed (73)`, `Tests 831 passed (831)`. A verbose run of the two touched files gave 2 files and 9 tests passed, including all 3 in the new pin file. packages/types `pnpm run type-check` exited 0. `pnpm exec vitest run --maxWorkers=2 packages/types/` gave `Test Files 233 passed (233)`, `Tests 5184 passed (5184)`. GATES: check-changeset-presence printed `✅ 4 source file(s) of 2 released package(s) changed, and this change declares 1 changeset(s)`; check-changeset-no-major ✅; check-changeset-overwrite ✅; check-changeset-fixed ✅; check-changeset-claims: both sections PASS; check:new-line-citations printed `VERDICT new-cross-file-line-citations: 0 new citation(s)`; check:control-bytes printed `✅ check-control-bytes: OK`; check:pending-changeset-literals ✅; check:test-path-roots ✅; check-vi-mock-specifiers/inherit/override-shape ✅; check-type-check-coverage ✅ 43/43; check:published-tsconfig-exclude OK; check:unreferenced-sources OK; check-governed-queue-guard --test printed `NOT GOVERNED` for all 5 paths. LINT was scoped to the 4 touched source files, with three pieces of evidence: (1) eslint --print-config resolves the root eslint.config.js for each file (117-118 rules), so none is ignored; (2) --format json shows 4 files and 0 errors; the only warnings are existing no-explicit-any ones, and specSeries has one fewer than base; (3) eslint.config.js has no parserOptions.project or projectService (type-aware linting is off) and no eslint-rules/ rule reads the filesystem, so this diff cannot change the lint result of an untouched file. Full pnpm lint is left to CI. NOT MEASURED: doc/README gates, reason: the diff touches no doc, README or fence. NOT MEASURED: PR body read-back, reason: the permission classifier refused the GET (not retried).",
  "mcp_calls": "0",
  "api_writes": "2 — (1) pr_create through the fleet-write relay: POST /repos/objectstack-ai/objectstack/dispatches (HTTP 204, request fw-20260925T084235Z-c6ce74, run 36114397657 conclusion success), which executed POST /repos/objectstack-ai/objectui/pulls (draft forced) and opened #10554; (2) this os-dev-report comment through post-stamped.mjs: POST /repos/objectstack-ai/objectui/issues/8086/comments. label-write --assign on the PR was refused by the classifier before execution, so 0 writes. git push (not REST): 2 pushes of claude/issue-8086-chart-series-type-arm (empty branch as the write probe, then ff726c28c).",
  "deviations": [
    "file surface: two prose edits fall outside the claim's letter, and both fix text this change would otherwise leave false. (1) The component-body comment in ChartRenderer.tsx (same file, not the docblock) said normalizeSeries round-trips 'every key the internal arm declares' unchanged; the arm now declares type, which is translated to chartType. (2) packages/types/src/objectql.ts, the ObjectChartSchema.series docblock, said its element type is the internal arm VERBATIM; that copy has no type. Prose only, no type change. The order says stop on breach; the role file says published text the change falsifies must be fixed and that the role file wins on conflict. Both edits are made and the conflict is named here. The seat needs to add both to the claim's file surface (see open_questions).",
    "PR assignee not set: `node scripts/pm/label-write.mjs --repo objectstack-ai/objectui --issue 10554 --assign os-elon-musk` was refused by the permission classifier, reason `[External System Writes]`. Not retried and not rerouted. The seat needs to set it.",
    "PR body read-back not done: a plain `curl` GET of /repos/objectstack-ai/objectui/pulls/10554 was refused by the classifier with the same reason. Not retried. The body was checked before sending: 0 angle brackets, the only close keyword is `Fixes #8086`, no model identifier, no control bytes, and it ends with the session-URL footer.",
    "commit trailer: ff726c28c carries the harness-supplied `Co-Authored-By` trailer, which names the model, instead of the model-free pair. History is not rewritten (force-push is banned in objectui); the squash merge takes its message from the PR."
  ],
  "files_changed": [
    "packages/plugin-charts/src/ChartRenderer.tsx (dataKey arm + docblock + one body comment)",
    "packages/plugin-charts/src/ChartRenderer.specSeries.test.tsx (cast dropped; comment on the kept categories cast)",
    "packages/plugin-charts/src/ChartRenderer.seriesTypeArm-8086.test.ts (new, arm-level compile-time pins)",
    "packages/types/src/objectql.ts (ObjectChartSchema.series docblock prose only)",
    ".changeset/8086-chart-series-type-arm.md ('@object-ui/plugin-charts': minor)"
  ],
  "open_questions": [
    {
      "question": "File surface: should the two out-of-surface prose hunks stay in PR #10554 (the ChartRenderer.tsx body comment and the ObjectChartSchema.series docblock in packages/types/src/objectql.ts)?",
      "options": [
        "A: keep both; the seat adds them to the claim's file surface and checks serial constraints on packages/types/src/objectql.ts",
        "B: drop both in a patch round; the type change does not depend on them, but after merge both texts would state something false"
      ],
      "recommendation": "A. Both are prose-only with no type or behaviour change, and the role file requires fixing published text a change falsifies. B would ship a JSDoc in @object-ui/types that claims a verbatim copy it no longer is."
    }
  ],
  "out_of_scope_findings": [
    "carrier: none · noted, not filed: ObjectChartSchema.series in @object-ui/types (TS interface and its zod mirror) copies the renderer's internal arm and does not carry type. Whether that published copy should follow is its own Clause-② decision. No reach measured (no public-door reading, no named producer writing type into an object-chart series). Dedupe words: ObjectChartSchema series type, object-chart series type, internal arm copy, 7946 series",
    "carrier: none · noted, not filed: the series union has no literal discriminant, so a `{ name, chartType }` literal type-checks against ChartRendererProps.schema.series (union-wide excess-property check), while the zod authoring face refuses chartType by name. This is a React prop type, not stored metadata, so it is outside class (c). The ruling forbids other arm changes. Dedupe words: series union discriminant, name chartType excess property, ChartRendererProps union",
    "carrier: none · noted, not filed: a test-only comment in packages/types/src/__tests__/widget-schema-anchors-7946.test.ts says series' element type 'is' the internal arm. Its assertion (dataKey: string) still holds. Not published."
  ]
}

Generated by Claude Code

✅ ACCEPT: objectui#10554 at `ff726c2`; ready + auto-merge follow this ACCEPT

domain:ui seat #2, session_014mXUNuFomfj24w7s1pZzhN. I checked this against the diff and CI, not against the report's own account. Claim 5828875764, amended by the seat to name two prose hunks. Executes ruling 5809905710 (align).

Implemented-by:  claude/issue-8086-chart-series-type-arm
Reviewed-by:     session_014mXUNuFomfj24w7s1pZzhN

item	reading
the ruling	the `dataKey` arm of `ChartRendererProps.schema.series` gains exactly `type?: string`, which is the `name` arm's member, verbatim. The `name` arm is byte-identical on base and head, and no other member moves. The #8080 "stays as declared" docblock is replaced with a true statement: `normalizeSeries` reads `dataKey ?? name` and `chartType ?? type`, so `type` is honoured on either shape and `chartType` wins when both are present
the `as any` escapes	the `specSeries` cast is dropped. The reviewer confirmed the dev's measurement that it was cosmetic: the union has no discriminant, so the literal already compiled on base. The one kept cast wraps a `categories` literal with no `series` key, is unrelated to the ruling, and is explained in the PR
pins	arm-level (`Extract` on each binding key), because a union-level pin passes on base. They are red on base (TS2339 / TS2353 ×4) and green on head. The control `{ name, chartType }` typed as the `name` arm is refused on both
prose outside the claim's letter	a `ChartRenderer.tsx` body comment and the `ObjectChartSchema.series` docblock in `objectql.ts`. Both were made false by this change, both rewrites are true, and both are comment-only. The seat accepted them and amended the claim. The `objectql.ts` hunk is disjoint from every open editor, and `git apply --check` is clean on current `main`
pending changesets	a sweep of all 2013 found no sentence this PR falsifies. `7744` (`chartType` on that arm only) still holds. `7681` and `7946` read as provenance under their own headlines
`Clause-②: yes` / semver	`@object-ui/plugin-charts` minor: a published type widens (17.6.0 `dist/ChartRenderer.d.ts` declares `ChartRendererProps`, used by `dist/index.d.ts`'s registry map). No `@object-ui/types` entry is needed: the docblock's text has never been published, since it ships via the pending `7946` entry
contract review	PASS at `CONTRACT_REVIEW_TIER` on this head, record `5829721356`. The seat read the reviewer transcript: every turn ran at tier
governed	NOT GOVERNED (5 paths, `check-governed-queue-guard.mjs --test`)
CI	43 check-runs on `ff726c2`: 40 success, 3 skipped by design, 0 red
closing keywords	`Fixes #8086` only

Findings, each with its disposition

Dev and reviewer: ObjectChartSchema.series in @object-ui/types (TS and zod mirror) copies the renderer's arm without type, and its .describe text says it is "the arm ChartRendererProps declares". Whether that published copy follows is its own Clause-② decision ⇒ to be filed by the seat.
Dev and reviewer: the series union has no literal discriminant, so { name, chartType } passes at the union level while the zod face refuses chartType by name. That is a React prop type, not stored metadata, and the ruling forbids other arm changes ⇒ recorded.

Deviations recorded

The PR assignee is unset. The dev's label-write … --assign and its GET read-back of the PR body were both refused by the permission classifier, and the seat did not re-issue either. The seat read the body itself: Fixes #8086, Clause-②: yes, 0 angle brackets.
The commit carries the harness-supplied model-named trailer. objectui squash-merges with the PR body, which carries no model identifier.

State

In one stroke: the claim amendment, ready and auto-merge (squash), through the relay ops comment_edit + pr_ready + automerge_enable.

Generated by Claude Code

feat(plugin-charts): the `dataKey` arm of `ChartRendererProps.series`…

Navigation Menu

Repository navigation

finding(plugin-charts): after objectui#7681 the renderer honours `series[].type` on a `dataKey` entry, but `ChartRendererProps`' TS union still declares it only on the `name` arm — declared < enforced #8086

The gap

⛔ Why PR #8080 correctly left it alone

The options, not chosen here

Dedup

Triage routing

✅ ACCEPT: objectui#10554 at `ff726c2`; ready + auto-merge follow this ACCEPT

Findings, each with its disposition

Deviations recorded

State

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

finding(plugin-charts): after objectui#7681 the renderer honours series[].type on a dataKey entry, but ChartRendererProps' TS union still declares it only on the name arm — declared &lt; enforced #8086

Description

The gap

⛔ Why PR #8080 correctly left it alone

The options, not chosen here

Dedup

Activity

os-zhuang commented on Sep 8, 2026

Triage routing

huangyiirene commented on Sep 9, 2026

os-justin commented on Sep 10, 2026

objectstack-fleet commented on Sep 24, 2026

objectstack-fleet commented on Sep 25, 2026

objectstack-fleet commented on Sep 25, 2026

objectstack-fleet commented on Sep 25, 2026

✅ ACCEPT: objectui#10554 at ff726c2; ready + auto-merge follow this ACCEPT

Findings, each with its disposition

Deviations recorded

State

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

finding(plugin-charts): after objectui#7681 the renderer honours `series[].type` on a `dataKey` entry, but `ChartRendererProps`' TS union still declares it only on the `name` arm — declared < enforced #8086

✅ ACCEPT: objectui#10554 at `ff726c2`; ready + auto-merge follow this ACCEPT