docs: the client SDK examples read the resolved payload

.changeset/client-readme-analytics-automation-payload-reads.md

@@ -0,0 +1,9 @@
+---
+"@objectstack/client": patch
+---
+
+The README's analytics and automation examples read the resolved payload.
+
+`client.analytics.query` / `analytics.meta` and `client.automation.trigger` stopped handing back the dispatcher's `{ success, data }` envelope in 17.0.0: each resolves to the payload itself. The README's namespace tour still showed all three as bare `await` calls with nothing reading the resolved value, so the package's own front page taught nothing about which shape comes back — neither wrong nor useful. Each of the three now assigns its result and reads one member of it: `report.rows` / `report.fields[0].name` (`AnalyticsResult`), `cubes[0].name` (the bare `CubeMeta[]`), `run.status` (`AutomationResult`) — the members those contracts actually declare, read off the payload rather than off a `data` wrapper.
+
+No behaviour changes; this is the README that ships inside the package. The docs site's Client SDK and Data API pages take the same treatment in the same PR.

content/docs/api/client-sdk.mdx

@@ -316,15 +316,18 @@ const result = await client.analytics.query({
   where: { status: 'active' },
   limit: 100,
 });
+console.log(result.rows.length, result.fields[0].name); // AnalyticsResult, unwrapped
 
 // Get cube metadata — all cubes, or one with meta('account')
 const meta = await client.analytics.meta('account');
+console.log(meta[0].name, meta[0].measures.length);     // the bare cube list
 
 // Dry-run a query to its generated SQL (POST /analytics/sql)
 const explained = await client.analytics.explain({
   cube: 'account',
   measures: ['revenue_sum'],
 });
+console.log(explained.sql, explained.params);           // { sql, params }
 ```
 
 ### `client.packages` — Package Management
@@ -430,7 +433,8 @@ await client.i18n.getTranslations('zh-CN');
 await client.i18n.getFieldLabels('account', 'zh-CN');
 
 // Automation — Trigger workflows and automations
-await client.automation.trigger('send_welcome_email', { userId });
+const welcome = await client.automation.trigger('send_welcome_email', { userId });
+console.log(welcome.status); // AutomationResult — the run's own outcome, unwrapped
 
 // A flow that does not run REJECTS — it does not resolve with an inner
 // `{ success: false }`. Branch on the thrown error's `code`, not on the

content/docs/api/data-api.mdx

@@ -444,7 +444,10 @@ Pass `?cube=<name>` to filter the listing to a single cube (this is what
 
 **Response**: `{ success: true, data: [...] }` where `data` is an array of cube
 definitions with measures and dimensions (time-based dimensions are `dimensions`
-entries with `type: "time"`).
+entries with `type: "time"`). That envelope is the wire shape only — the SDK
+unwraps it, so `client.analytics.meta(cube)` resolves to the cube array itself
+and a caller reads `cubes[0].name`. The same holds for the other analytics and
+automation calls; see the [Client SDK](/docs/api/client-sdk) page.
 
 ### `POST /analytics/sql`
 

packages/client/README.md

@@ -269,12 +269,15 @@ await client.i18n.getLocales();
 await client.i18n.getTranslations('zh-CN');
 await client.i18n.getFieldLabels('contact', 'zh-CN');
 
-// Analytics
-await client.analytics.query({ object: 'sales', aggregations: ['sum:amount'] });
-await client.analytics.meta('sales');
+// Analytics — every method resolves to the payload itself
+const report = await client.analytics.query({ object: 'sales', aggregations: ['sum:amount'] });
+console.log(report.rows.length, report.fields[0].name);
+const cubes = await client.analytics.meta('sales');
+console.log(cubes[0].name);
 
 // Automation
-await client.automation.trigger('send_welcome_email', { userId });
+const run = await client.automation.trigger('send_welcome_email', { userId });
+console.log(run.status);
 
 // File Storage
 await client.storage.upload(fileData, 'user');