[objectstack-fleet]

Requested by Yibo Wang · project thread

Fixes #26847

Clause-②: no (narrowing)
Metadata-protocol: narrowed
Skills-docs: updated here — content/docs/data-modeling/analytics.mdx gains the rule and its remedy; no skills/** file teaches list-view chart bindings, so no skill changes.

维护者速读

• 改了什么：列表视图的图表如果引用了不存在的数据集，或 values 写了数据集里没有的度量（维度同理），通过视图或对象发布时直接拒绝（422），给出与 os validate 相同的结论；草稿保存不拦。
• 为什么改：Studio 或 MCP 作者拼错数据集名、或把原始字段名当度量写，以前发布返回 200，保存下来的图表是空的或坏的，没有任何提示，而 CLI 对同一份文件会报错。
• 风险与回滚：没有改任何 schema，只是让已有的 lint 规则在视图/对象发布门也运行；仓内 examples 与 platform-objects 没有视图或对象被拒（实测 2 个图表列表视图，0 条结论）。回滚即 revert 本 PR。
• 先看：packages/lint/src/validate-chart-bindings.ts（列表视图遍历新增的两种独立视图形态）、packages/lint/src/reference-integrity-suite.ts（validateChartBindings 一行的 runtimeTypes 与上方注释）、packages/rest/src/meta-view-chart-binding.test.ts 末尾的 #26847 段。
• 两分钟验证：pnpm --filter @objectstack/lint exec vitest run src/validate-chart-bindings.test.ts -t 26847，应见 24 条全绿（三种视图形态 × 未知数据集 / 未知度量 / 对照，加对象发布门与运行时门）。
• 需要你做的：无，席位落地（窄化需先过契约档复核）。

What changes

validateChartBindings (packages/lint) already gave chart-dataset-unknown, chart-dimension-unknown and chart-measure-unknown for a list-view chart under os validate, but the runtime publish door never ran it for a view or an object. Two things kept it out:

1. The suite row. reference-integrity-suite.ts declared runtimeTypes: ['flow', 'report']. It is now ['flow', 'report', 'view', 'object'], and the comment above the row is rewritten: a list-view chart resolves against stack.datasets alone, which every per-write snapshot carries, so crossing it opens no missing-collection false-positive channel. The rule's report, page and dashboard surfaces read collections a view or object snapshot does not carry, so on those writes they find nothing.
2. The walk. The list-view walk read views[].list, views[].listViews.KEY and objects[].listViews.KEY, but not the two standalone shapes PUT /api/v1/meta/view hands the suite: the flattened list overlay (viewKind: 'list', chart at the top level) and the ViewItem record (viewKind: 'list', chart inside config). Both rungs are added, recognised the way validateListViewFieldRefs recognises them. Without them, adding view to runtimeTypes would have been a no-op for those two shapes.

One guard moves with it: the rule's early return (no datasets, no reports, no views, no pages) now also looks at objects, so an object list view naming a dataset in a stack that declares none is reported instead of skipped. That is what makes the object door judge an object written into an environment with no datasets.

The verdicts are unchanged: chart-dataset-unknown at chart.dataset, chart-measure-unknown at chart.values[i], chart-dimension-unknown at chart.dimensions[i], all error, so the publish answers 422 INVALID_METADATA. A draft save is not gated.

Why

A Studio or MCP author who mistypes a dataset name, or names a measure the dataset lacks, gets a saved view whose chart renders empty or broken. Nothing says why, and the CLI would have refused the same file.

Tests

• packages/lint/src/validate-chart-bindings.test.ts, new [#26847] block (24 cases): each of the three view shapes (ViewItem config, flattened overlay, container listViews member) gives chart-dataset-unknown and chart-measure-unknown at the right path, with a clean control; a ViewItem record is walked at config only; an object list view in a stack with no datasets is reported. At the runtime door (runRuntimeAuthoringRules, the function metadata-protocol calls): a lit probe per verdict per view shape and on an object write, each with a clean control, and a pin that the row declares view and object.
• packages/rest/src/meta-view-chart-binding.test.ts, new #26847 block (9 cases) on the real composition (real RestServer route, real saveMetaItem, real ObjectQL + SQLite sys_metadata): per shape, no_such_dataset → 422 INVALID_METADATA with chart-dataset-unknown at ….chart.dataset and nothing stored; ghost_measure → 422 with chart-measure-unknown at ….chart.values[0] and nothing stored; the control → 200 and stored. The file's boot() now publishes the lead_metrics dataset its fixtures bind, through PUT /api/v1/meta/dataset: the existing spec(ui): the view write door accepts a chart list view that names no dataset (type: 'chart' with no chart block, or options.chart with only chartType); once objectui stops reading the legacy axes, such a view saves green and renders only a refusal #22491 control bound that dataset without declaring it, and is refused now that the door resolves it.
• Re-judged pins: the view and object member-surface rosters (runtime-gate.view-writes.test.ts, runtime-gate.object-writes.test.ts) gain validateChartBindings with the argument written beside them. The spec: a chart list view on object A accepts a dataset bound to another object or another package without refusal #26719 save-door probes in validate-list-view-field-refs.test.ts charted status / task_count against the person dataset, which declares neither; they now select names their dataset declares, so the foreign object stays the only thing wrong with them.

Acceptance notes

• Measured before the change, at the real door. On main 20457f6f, with the same harness as the new REST block and a declared lead_metrics dataset, all six bad PUTs answered 200 (three shapes × no_such_dataset / ghost_measure), and the three controls 200. On this branch the six answer 422 at views[0].config.chart.dataset / views[0].chart.dataset / views[0].listViews.pipeline.chart.dataset (and ….values[0] for the measure), the controls still 200. The lint dist was rebuilt from each tree before its run.
• Shipped corpus, measured at the door's snapshot shape before crossing, on 21e8217b: every view sent through runRuntimeAuthoringRules({ type: 'view' }) and every object with listViews through { type: 'object' }, each with its own stack's objects and datasets as context. examples/app-crm 3 views / 6 objects, examples/app-todo 1 / 1, examples/app-showcase 6 views / 24 objects / 4 datasets, examples/app-multi-package none, packages/platform-objects 53 objects (29 with listViews). Two list views chart (showcase task chart, project budget_chart): 0 chart findings at either door. A lit probe (the showcase chart rebound to an unknown dataset) is refused. apps/ holds only the docs site; a repo-wide search for type: 'chart' outside tests finds no other list-view chart.
• Not changed: dashboard and page writes still do not run this member; their surfaces are owned by their sibling rules.

Verification

All local, on 35d40a9e, through scripts/pm/os-verify-lock.sh (every VERDICT line command-exit 0):

• pnpm --filter @objectstack/lint test: Test Files 169 passed (169), Tests 7490 passed (7490). pnpm --filter @objectstack/lint typecheck: exit 0.
• pnpm --filter @objectstack/rest test: Test Files 328 passed (328), Tests 6522 passed, 326 skipped.
• pnpm --filter @objectstack/metadata-protocol test: Test Files 270 passed, 4 skipped (274), Tests 21666 passed, 26 skipped.
• node scripts/pm/dispatch-gates.mjs --commands (merge base 20457f6f, 6 paths): 88 derived families, 86 exit 0. check:skill-examples and check:dual-build-cjs-loads exit 3 (prerequisite: they read a full build); they re-run after pnpm build, and that reading, the full dogfood battery on the final head and the --ran reconciliation are in the os-dev report on spec(lint): the view publish door accepts a chart list view whose dataset does not exist or whose values names no measure of its dataset #26847.
• Before/after at the real REST door: see the first acceptance note.

Human Minimum

• 1. Schemas start as Zod; packages/spec holds no runtime logic.
• 2. Every name I added uses the casing for its kind.
• 3. No formatter ran; eslint --no-inline-config on the seven changed source and test files exits 0 (the repo-wide pnpm lint is CI's run).
• 4. One issue, one branch off an up-to-date main, one pull request.
• 5. A change that publishes carries a changeset, and both declaration lines are filled in here and in the changeset.
• 6. packages/spec touched: its generated artifacts are regenerated and committed. (Not touched.)
• 7. No hand edits to content/docs/references/, packages/*/CHANGELOG.md or content/docs/releases/.
• 8. Title, body and comments are in English.
• The Before Submitting list in CONTRIBUTING.md is done.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WGufziFPBpGc76tAFHbB8v

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/lint, touching 4 documentable anchor(s).

5 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/plugin-endpoints.mdx (via /api/v1/meta/view (route, a path literal in a comment on a changed line))
• content/docs/concepts/metadata-lifecycle.mdx (via /api/v1/meta/view (route, a path literal in a comment on a changed line))
• content/docs/kernel/services-checklist.mdx (via /api/v1/meta/view (route, a path literal in a comment on a changed line))
• content/docs/protocol/objectui/index.mdx (via /api/v1/meta/view (route, a path literal in a comment on a changed line))
• content/docs/ui/forms.mdx (via /api/v1/meta/view (route, a path literal in a comment on a changed line))

⛔ 1 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v17/17-6.mdx (via /api/v1/meta/view (route, a path literal in a comment on a changed line))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• the SDK route bridge reached 55 of 207 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 4 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 57820085fa1cfb522fefc1e24e12f252d8d4630e → packageMentionDocs.

Which tree this was computed on

This run read content/docs from db5554db0b387c443345867f27ff4077a05de307 — the merge of head 96844466d4db1163476073fbbe825875c0fe8d8e into base 57820085fa1cfb522fefc1e24e12f252d8d4630e, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin db5554db0b387c443345867f27ff4077a05de307 && git checkout db5554db0b387c443345867f27ff4077a05de307
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 57820085fa1cfb522fefc1e24e12f252d8d4630e 96844466d4db1163476073fbbe825875c0fe8d8e && git checkout -B drift-repro 57820085fa1cfb522fefc1e24e12f252d8d4630e && git merge --no-ff 96844466d4db1163476073fbbe825875c0fe8d8e

node scripts/docs-audit/affected-docs.mjs --json 57820085fa1cfb522fefc1e24e12f252d8d4630e

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 57820085fa1cfb522fefc1e24e12f252d8d4630e → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 35d40a9e7bf52112cbdb9bd10cbca209bcb02b21
Local-runs: none
Scope: packages/lint/src/reference-integrity-suite.ts, packages/lint/src/validate-chart-bindings.ts, packages/lint/src/validate-chart-bindings.test.ts, packages/lint/src/runtime-gate.view-writes.test.ts, packages/lint/src/runtime-gate.object-writes.test.ts, packages/lint/src/validate-list-view-field-refs.test.ts, packages/rest/src/meta-view-chart-binding.test.ts + packages/lint/src/runtime-gate.ts, packages/lint/src/validate-list-view-field-refs.ts, packages/metadata-protocol/src/runtime-authoring-gate.ts, packages/metadata-protocol/src/protocol.ts, packages/spec/src/ui/view.zod.ts, packages/cli/src/commands/validate.ts

Inputs: card #26847 (body, triage 6451024495, claim 6451805787, os-dev-report 6453550675), PR #26906 (body, 9-file list, net diff against main at merge base 20457f6f), and the 52 check-runs on the head: every required run success (Lint & Repo Gates, TypeScript Type Check, Test Core 8/8, Build Core, Test UI, Type Check UI, Build & E2E UI, Dogfood Regression Gate, Check Changeset, Governed Surface Queue Guard, PR-body guards, Spec property liveness); the skipped ones are opt-in or ui/-only shards. No governed surface in the file list; the face is the Clause-②: no (narrowing) line.

① Derived judgments

1. validateChartBindings row: runtimeTypes ['flow','report'] → ['flow','report','view','object'] (reference-integrity-suite.ts:454). Right. runtimeAuthoringRulesFor(type) filters by this list alone, so a view and an object publish (state: 'active') now run the member; dashboard and page stay out. The old comment's reason for excluding view (the snapshot carries no reports/dashboards) does not bite: on a view or object write stack.reports and stack.pages are absent, recordsOf yields [], and the report and page surfaces find nothing. The one collection the list-view surface resolves against, datasets, is a CONTEXT_STACK_KEYS member every per-write snapshot carries (runtime-gate.ts), folded live from registry plus active sys_metadata rows and the batch's pending drafts (protocol.ts The dashboard publish gate resolves widget.dataset against the boot-time stack, so a dataset saved through PUT /meta/dataset is a phantom widget-dataset-unknown until the runtime restarts #15950/The runtime authoring gate judges an OVERRIDDEN item's content from the registry copy, so an overlay that removes a measure still accepts widgets bound to it #16224, runtime-authoring-gate.ts mergePendingDeclarations). datasets are not package-closure-narrowed (only objects are, buildRuntimeWriteSnapshotSet), so a dataset declared in any package of the deployment resolves.
2. Accept-set at PUT /api/v1/meta/view: a list view whose chart.dataset names no live dataset, or whose chart.values[i] / chart.dimensions[i] names no measure / dimension of it, is refused 422 INVALID_METADATA (chart-dataset-unknown, chart-measure-unknown, chart-dimension-unknown, all error at the query position). Right: ListChartConfigSchema (view.zod.ts:2093) declares dataset as "Dataset name to bind", dimensions as "Dimension names (from the dataset)" and values as "Measure names (from the dataset)", so the refusal is the spec's own. The card asked for dataset and measure; dimension rides the same unchanged rule and is declared in the changeset and docs — right, not a scope creep.
3. Accept-set at PUT /api/v1/meta/object: an object's own listViews.KEY.chart is judged the same way on an object publish. Right, and it is what the card's "and object, for objects[].listViews" asked for.
4. The two standalone view shapes (validate-chart-bindings.ts:630-640): viewKind === 'list' with a record config → walked at views[i].config; viewKind === 'list' without one → walked at views[i] (flattened overlay). Right, and byte-for-byte the recogniser validateListViewFieldRefs uses (:1346, :1356). A form ViewItem is skipped; a ViewItem is walked at config only (pinned). Without these rungs the row change would have been a no-op for both door shapes, which is the card's fourth bullet.
5. Early return now also checks !stack.objects (:372). Right at the door (baseline and candidate both carry objects, so the guard is identical in both passes and the differential is unaffected). It is also live at os validate / os build / os lint: authoringRuleUnionStack(normalized) carries only the keys the manifest declares, so an objects-only manifest with no datasets, reports, views or pages whose listViews chart binds a dataset was previously skipped and is now reported chart-dataset-unknown. The verdict is right (the binding resolves to nothing either way) and is pinned ("refused, not skipped"); see ② for the one line of prose it affects.
6. No false-positive channel opened. On a view write the rule walks context objects[].listViews in both passes and their findings cancel in the candidate-minus-baseline differential; on an update the stored pass handles a sibling finding; nameKeyFindingPath keeps views[0]… positional (the written item is the sole member) and names objects.NAME… — both spellings are what the REST and lint pins assert. Drafts are untouched (D1 in runtime-authoring-gate.ts: state !== 'active' returns before any rule).
7. Public surface: no schema key added, removed or re-shaped; no export changes; packages/rest and packages/metadata-protocol source untouched — the door behaviour change arrives entirely through the @objectstack/lint registry row. Right.
8. Re-judged pins: the view and object member-surface rosters gain validateChartBindings with the measurement argument beside them. The spec: a chart list view on object A accepts a dataset bound to another object or another package without refusal #26719 door probes previously charted status/task_count against duly_person_metrics, which declares name/person_count (fixture at validate-list-view-field-refs.test.ts:26-48); OWN_SELECTION now selects each dataset's declared names so the foreign object stays the only defect — confirmed from the hunk. The spec(ui): the view write door accepts a chart list view that names no dataset (type: 'chart' with no chart block, or options.chart with only chartType); once objectui stops reading the legacy axes, such a view saves green and renders only a refusal #22491 REST file's boot() now PUTs the lead_metrics dataset through type: 'dataset' and throws if it is not 200, so its control resolves — confirmed from the hunk (call gained a type parameter defaulting to view).

② Semver level

• Changeset .changeset/26847-list-view-chart-binding-publish-door.md sits in the ROOT .changeset/ directory (not ui/.changeset); Check Changeset is success.
• '@objectstack/lint': minor. Correct by the repo's rule (AGENTS.md §3): the kind decides the level — Metadata-protocol: narrowed takes at least minor on the package the diff moves; the pre-1.0 question does not arise (@objectstack/lint is 18.2.0 in the fixed group), and the rule fixes minor for a narrowed kind regardless. Only @objectstack/lint publishes a change; packages/rest carries tests alone.
• Clause-②: no (narrowing) and Metadata-protocol: narrowed are present line-initial in the PR body and in the changeset body, and they agree. The triage note's Clause-②: yes (narrowing) is superseded by the claim and the PR; the PR's pair is the well-formed one.
• BREAKING banner present; ADR-0087 marker present and single: adr-0087: not-required (no-migration-prescription) with its reason; Lint & Repo Gates (which carries check:adr-0087-registration) is success. The remedy paragraph (**The remedy.**) is present.
• Clause-②: line judged: no (narrowing) — right. The diff refuses at publish what published 200 before and widens nothing.
• should-fix (prose, not level): the changeset's "os validate / os build already refused it, and still do. Nothing is widened." overstates by one shape — per ①5 the early-return change makes os validate / os build newly report an objects-only stack with no datasets whose listViews chart binds a dataset. The level and kind already cover it; one clause in the "Before" bullet should say so.

③ Boundary flags

• Dev open_questions: []. Dev out_of_scope_findings: []. Nothing to escalate.
• PR body "Not changed: dashboard and page writes still do not run this member; their surfaces are owned by their sibling rules." Answered: right. On those writes the surfaces the rule walks are the subject, validateWidgetBindings (dashboard) and validatePageVisualizationBindings (page) are the door rules, and the rewritten row comment says so. Not this card's gap.
• Claim Premise: unverified at origin/main 20457f6f — the dev re-measured through the real RestServer route on 20457f6f (6/6 bad PUTs 200) before editing; the REST block's header records it. Answered.
• Claim serial constraint (spec: the view save door silently strips unknown top-level keys from the view envelope (200, not stored) while object, page and dashboard bodies refuse them 422 unrecognized_keys #26711 / PR fix(spec)!: the view write door refuses an unknown top-level key #26851 narrows the view envelope in packages/spec): this diff touches no packages/spec file; no overlap in the file list. Answered.
• Card "measure the shipped view corpus at the door's snapshot shape before crossing": the row comment and the two roster pins carry the population (four example apps and platform-objects; two chart list views, 0 findings; lit probe refused at each door). The corpus measurement is the dev's account and cannot be re-run read-only; what the record can verify is that the two chart list views named (showcase task chart, project budget_chart) are the only type: 'chart' list views outside tests, which the PR states and the row comment pins. Accepted on the shipped pins plus the check-runs.
• Card "Pin a lit probe for each verdict at the door": done — 3 shapes × dataset/measure at runRuntimeAuthoringRules (lint) and at the real route (rest), plus the object door, each with a clean control.

④ Design judgment

The narrowing, read against the published spec on main and the cited code:

• Does it take a declared capability away at the consumer? No. The spec declares dataset, dimensions and values of a list chart as names from the dataset (view.zod.ts:2106-2116) and the renderer (ObjectView.tsx, per the rule's own docblock) hands values to the dataset query as measures, so a binding that resolves to nothing never rendered. The narrowing makes the spec's own refusal real at the door, exactly as os validate already did. No implementation gap is being papered over: there is no declared capability to bind a list chart to an undeclared dataset or measure.
• Live universe. A tenant's dataset authored through PUT /meta/dataset (env-wide or the write's own org), a code-package dataset, and a pending draft dataset in the same batch all resolve (The dashboard publish gate resolves widget.dataset against the boot-time stack, so a dataset saved through PUT /meta/dataset is a phantom widget-dataset-unknown until the runtime restarts #15950, The runtime authoring gate judges an OVERRIDDEN item's content from the registry copy, so an overlay that removes a measure still accepts widgets bound to it #16224, publishPackageDrafts validation closure omits same-batch dataset drafts: a package shipping dashboard+dataset together can never publish (widget-dataset-unknown) #10377). A draft dataset outside the batch does not — that is The metadata door accepts a dashboard widget dataset binding that names nothing — 200 on both save and publish, referential integrity enforced only at runtime #7529's standing ruling (refuse at publish so author order is free), already in force for report ([rebuild of #19474] spec(lint): wire the inert runtime-create rules for action / hook / report / skill / email_template / mapping — six types, one edit (ruling #203/4 group A+C) #19542) and for validateListViewFieldRefs at this same door (spec: a chart list view on object A accepts a dataset bound to another object or another package without refusal #26719). This PR opens no channel those two did not.
• Differential safety. Tried: a view write where a sibling context object carries a dangling listViews chart — cancels (same finding in baseline and candidate). An object update whose stored self had a dangling chart — stored pass marks sibling findings as pre-existing; findings on the written item are judged fresh, which is the intended re-judgement of a republish. A view write in a package scope whose dataset lives in another package — datasets are never closure-narrowed, resolves. A ViewItem carrying both config and a stray top-level chart — walked once at config (pinned). A form ViewItem — skipped. A list view with chart but type: 'grid' — same behaviour as os validate had on views[].list; not new.
• Verdict path spelling. views[0].config.chart.dataset / views[0].chart.dataset / views[0].listViews.KEY.chart.dataset for a view write, objects.NAME.listViews.KEY.chart… for an object write — located, and what the card's "located at chart.dataset or chart.values[i]" asked for.
• Stored rows that no longer pass. A view stored before this head with a dangling binding is served as stored and is refused only on its next publish, with the path and a hint listing declared datasets / nearest name. That is the narrowing the card ordered, with the remedy in the changeset and in analytics.mdx.
• Findings: no must-fix. One should-fix (changeset "Before" clause, ②). The code hunks hold against the code they cite and the scenario they are accepted against.

Implemented-by: claude/project-thread-rf1hg1
Reviewed-by: session_01WGufzfhobWEgUUrjz4rrbh

VERDICT: PASS

[objectstack-fleet]

席位核对 · ACCEPT · domain:spec seat 1 (#6017) · session session_01WGufzfhobWEgUUrjz4rrbh · 2026-10-27T21:51Z

Head 96844466d4db1163476073fbbe825875c0fe8d8e. Card #26847 (seat-1 filing, triage 6451024495), claim 6451805787, dev report 6453550675.

• Contract review: owed at CONTRACT_REVIEW_TIER on the narrowing face (Clause-②: no (narrowing), floor is every non-prose path). The review (6453774408) at 35d40a9e was a PASS with no must-fix. It found:
  • The narrowing makes the spec's own refusal real: ListChartConfigSchema declares dataset, dimensions and values as names from a dataset, and no declared capability is taken away.
  • Resolution reads the same live universe [rebuild of #19474] spec(lint): wire the inert runtime-create rules for action / hook / report / skill / email_template / mapping — six types, one edit (ruling #203/4 group A+C) #19542 and spec: a chart list view on object A accepts a dataset bound to another object or another package without refusal #26719 already use at this door (registry, active sys_metadata rows and the batch's pending drafts), and the candidate-minus-baseline differential cancels sibling findings on a view write. Drafts stay ungated.
  • The two standalone shape recognisers mirror validateListViewFieldRefs, and the lint and REST pins cover every shape × verdict with controls.
  • The spec(ui): the view write door accepts a chart list view that names no dataset (type: 'chart' with no chart block, or options.chart with only chartType); once objectui stops reading the legacy axes, such a view saves green and renders only a refusal #22491 REST control now publishes its lead_metrics dataset, and the spec: a chart list view on object A accepts a dataset bound to another object or another package without refusal #26719 probes select declared names, so the foreign object stays their only defect.
  • The changeset sits in the root .changeset/. minor on @objectstack/lint is what the narrowed kind takes, and the BREAKING banner and the ADR-0087 not-required (no-migration-prescription) marker are present.
• Since then: 96844466 closes the one should-fix, changeset prose only. "os validate / os build already refused it, and still do" overstated by one shape. The changeset now names the two cases the CLI newly reports: an object's listViews chart in a stack that declares no datasets, reports, views or pages, and a views[] entry in the flattened overlay or ViewItem config shape. Level and kind are unchanged. The PR body never carried that sentence, so it needs no edit.
• Shape: Fixes #26847, 9 files, +331/−23. One root changeset, @objectstack/lint minor. Clause-②: no (narrowing) and Metadata-protocol: narrowed. check-governed-merges --pr 26906: NOT governed, 354 changed lines.
• Gates: check-runs on this head are 40 success, 7 skipped and 0 red. mergeable_state is clean.
• Landing: Tier S. pr_ready + automerge_enable in this act.