[finding] `skills/objectui/guides/data-integration.md` teaches a `QueryResult` shape that does not exist — the declared sketch omits `data`, so the wrong example is consistent with it

[os-warren]

Filed by the domain:devx @ objectui seat (#5748), round R3, on behalf of the #5458 dev, which measured this and correctly did not touch it: skills/** is a published skill package, evaluated as a whole package against its own line budget, so it is not a rider on a lint-rule PR. Filed unassigned and with no domain:* — the triage seat is the single producer of routing labels and this one is a genuine judgement call (see below).

What was measured

While fixing #5458 (query options spelled without their $), the dev checked the published guide the card had flagged in passing. It is worse than #5458 recorded, and the interesting part is why it stayed wrong.

line	claim	reality
:275	return result.records;	QueryResult has no records member. Real shape: { data, total, page, pageSize, hasMore, cursor, metadata }
same snippet	passes filter:, sort:, limit: 20	all three are dropped — convertQueryParams copies only $-prefixed keys. This is exactly the #5458 class, published to skill consumers
:78	the guide's own QueryResult sketch declares records?: T[] and pageNumber?, omitting data entirely	this is the root cause

⚠️ The root cause is :78, not :275. The example is not a typo against a correct declaration — it is consistent with a type declaration on the same page that is itself wrong. Fixing the return line alone would leave the snippet contradicting the sketch above it, and the next reader would "fix" it back. Whoever takes this must fix the declaration first and the usage second.

Note the card that prompted #5458 said the offending line was at :268; it is now :275. Re-derive rather than trusting either number.

Why it matters more than an ordinary docs defect

This is a published skills surface — the guide an agent loads to learn how to read data from this platform. A wrong QueryResult shape here does not mislead one reader once; it teaches every consuming agent to write result.records, which resolves to undefined against every real adapter and degrades to an empty list rather than an error.

That is not hypothetical. #5458 found the identical misread live in three places in this repo's own source (sdui-workbench-preview .records, DashboardFilterBar .items, and the asArray helpers in #5945), and in DashboardFilterBar it meant a dashboard filter offered no options at all against a real data source. The guide is the plausible common ancestor of that family.

Routing is a real question, so it is left to triage

Under objectui's three-stream split this does not sit cleanly:

• the subject is the data contract (QueryResult), which argues domain:spec;
• the file is a published skill package, which is neither the engineering surface nor an app;
• ⛔ it is not domain:devx just because Four live adapter.find calls pass an unprefixed query option — and no-query-params-under-options gates only the sibling half of the class #5458 surfaced it.

Constraints for whoever takes it

• Published skills packages are evaluated whole-package (maintainer, 2026-08-21: 「对外发布的 skills 是整个平台的最大价值,尤其要整体考虑和评估。」). Any dispatch for this needs a PM-set net-line budget, and ⛔ the dev may not raise it — that is a maintainer ruling.
• Fix :78 (the declaration) before :275 (the usage), or the two will disagree again.
• The three dropped query options in the same snippet are the Four live adapter.find calls pass an unprefixed query option — and no-query-params-under-options gates only the sibling half of the class #5458 class; object-ui/no-unprefixed-query-params now rejects that shape in source, but ⛔ no gate reaches a fenced snippet inside skills/** — related: check-doc-snippet-types 的扫描面不含 skills/ —— agent 复制进用户仓的代码样例,没有任何 typechecker 编译过 #5465 (the doc-snippet gate's scan surface excludes skills/).

Evidence: #5458 (and PR #5946), #5945, #5944, #5465.