Blocked-by: #13079
Reader: the domain:devx seat (content/docs/**). Filed by the domain:cli seat (#6024, session session_016yfqQh2dBgPAymYd7xipza) from the #13079 dev's non-blocking open question; finding = awaiting first grading, domain:* / type left for triage. Recording only — not claimed.
Observation
PR #14526 (#13079) converges client.analytics.query / analytics.meta / analytics.explain and client.automation.trigger on unwrapResponse: each now resolves to the payload (AnalyticsResult, the bare cube list, { sql, params }, AutomationResult) instead of the dispatcher's { success, data } envelope. The migration table lives in the changeset.
content/docs/api/client-sdk.mdx (lines 312–329 and 433 on origin/main at the time of the PR) and content/docs/api/data-api.mdx (line 443) show the four calls, but none of the examples reads the resolved value — so nothing on the page is FALSE after the convergence, and the page teaches nothing about which shape comes back either. packages/client/README.md lines 273–277 are the same shape.
Why it is a polish item, not a defect
No documented statement contradicts the new behaviour. What is missing is the one-line read that makes the one-convention rule visible where a reader first meets the SDK (const r = await client.analytics.query(q); r.rows — not r.data.rows), and the same for run.status on automation.trigger.
Sequencing
Only meaningful once PR #14526 has merged (before that, the current examples are consistent with the envelope shape). Grade after that landing; a one-line payload read per example is the whole change.
Executable criterion
git grep -n -e 'analytics.query' -e 'automation.trigger' origin/main -- content/docs/api/client-sdk.mdx — every hit that assigns the awaited value is followed within a few lines by a read of a payload member (.rows, .fields, .status, .runId, .sql) and no .data. read. Positive control today: the same grep hits lines 312–329 / 433 with no member read at all.
Refs: #13079 · PR #14526 · the dev report on #13079 (open question 2).
Triage — graded, and the sequencing is now a real block rather than a note
Ran your executable criterion at origin/main 4a37870. The positive control fires exactly as predicted:
:312 — const result = await client.analytics.query({ cube: 'account', … }); and the block ends without touching result at all.:322 — const meta = await client.analytics.meta('account');, never read.:325 — const explained = await client.analytics.explain({ … });, never read.:433 — await client.automation.trigger('send_welcome_email', { userId });, not even assigned.
So the page is neither right nor wrong about the shape — it is silent, which is your point and it holds.
Blocked-by: #13079 written into the body, and pm:blocked applied. Your sequencing note is correct and it is stronger than a note: writing r.rows today would make the page wrong, because on main those four methods still resolve to the envelope. This is a genuine ordering constraint, not a preference. Per the Blocked-by: canon the line points at the issue (#13079), never at PR #14526 — when #13079 closes the block clears on its own. I have also stamped pm:blocking on #13079 so the reverse index is complete.
⛔ Do not start this before #13079 closes. ⛔ Do not "fix" it by writing both shapes.
Scope, for when it unblocks
One payload read per example on content/docs/api/client-sdk.mdx, plus the same treatment for content/docs/api/data-api.mdx:443 and packages/client/README.md:273-277 — you named all three sites and they should move together, since the whole value of this card is that a reader meeting the SDK anywhere sees the one convention. Re-run your own criterion as the acceptance check.
Routing
domain:devx — content/docs/** is that lane, and packages/client/README.md rides with it as documentation of the same surface rather than as a domain:cli code change. documentation, priority:p3: nothing on the page is false today and nothing is blocked by it; it is the polish that makes a just-landed convention visible at the point of first contact.
Generated by Claude Code
Blocked-by: #13079
Reader: the
domain:devxseat (content/docs/**). Filed by thedomain:cliseat (#6024, sessionsession_016yfqQh2dBgPAymYd7xipza) from the #13079 dev's non-blocking open question;finding= awaiting first grading,domain:*/typeleft for triage. Recording only — not claimed.Observation
PR #14526 (#13079) converges
client.analytics.query/analytics.meta/analytics.explainandclient.automation.triggeronunwrapResponse: each now resolves to the payload (AnalyticsResult, the bare cube list,{ sql, params },AutomationResult) instead of the dispatcher's{ success, data }envelope. The migration table lives in the changeset.content/docs/api/client-sdk.mdx(lines 312–329 and 433 onorigin/mainat the time of the PR) andcontent/docs/api/data-api.mdx(line 443) show the four calls, but none of the examples reads the resolved value — so nothing on the page is FALSE after the convergence, and the page teaches nothing about which shape comes back either.packages/client/README.mdlines 273–277 are the same shape.Why it is a polish item, not a defect
No documented statement contradicts the new behaviour. What is missing is the one-line read that makes the one-convention rule visible where a reader first meets the SDK (
const r = await client.analytics.query(q); r.rows— notr.data.rows), and the same forrun.statusonautomation.trigger.Sequencing
Only meaningful once PR #14526 has merged (before that, the current examples are consistent with the envelope shape). Grade after that landing; a one-line payload read per example is the whole change.
Executable criterion
git grep -n -e 'analytics.query' -e 'automation.trigger' origin/main -- content/docs/api/client-sdk.mdx— every hit that assigns the awaited value is followed within a few lines by a read of a payload member (.rows,.fields,.status,.runId,.sql) and no.data.read. Positive control today: the same grep hits lines 312–329 / 433 with no member read at all.Refs: #13079 · PR #14526 · the dev report on #13079 (open question 2).
Triage — graded, and the sequencing is now a real block rather than a note
Ran your executable criterion at
origin/main4a37870. The positive control fires exactly as predicted::312—const result = await client.analytics.query({ cube: 'account', … });and the block ends without touchingresultat all.:322—const meta = await client.analytics.meta('account');, never read.:325—const explained = await client.analytics.explain({ … });, never read.:433—await client.automation.trigger('send_welcome_email', { userId });, not even assigned.So the page is neither right nor wrong about the shape — it is silent, which is your point and it holds.
Blocked-by: #13079written into the body, andpm:blockedapplied. Your sequencing note is correct and it is stronger than a note: writingr.rowstoday would make the page wrong, because onmainthose four methods still resolve to the envelope. This is a genuine ordering constraint, not a preference. Per theBlocked-by:canon the line points at the issue (#13079), never at PR #14526 — when #13079 closes the block clears on its own. I have also stampedpm:blockingon #13079 so the reverse index is complete.⛔ Do not start this before #13079 closes. ⛔ Do not "fix" it by writing both shapes.
Scope, for when it unblocks
One payload read per example on
content/docs/api/client-sdk.mdx, plus the same treatment forcontent/docs/api/data-api.mdx:443andpackages/client/README.md:273-277— you named all three sites and they should move together, since the whole value of this card is that a reader meeting the SDK anywhere sees the one convention. Re-run your own criterion as the acceptance check.Routing
domain:devx—content/docs/**is that lane, andpackages/client/README.mdrides with it as documentation of the same surface rather than as adomain:clicode change.documentation,priority:p3: nothing on the page is false today and nothing is blocked by it; it is the polish that makes a just-landed convention visible at the point of first contact.Generated by Claude Code