@mindstudio-ai/remy 0.1.309 → 0.1.310
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -125,7 +125,7 @@ analytics.track('checkout_completed', { itemCount: 3, total: 47.99 });
|
|
|
125
125
|
|
|
126
126
|
- **Apps can also READ their own analytics from backend methods** — the agent SDK's `analytics` namespace (lifetime per-page metrics, live visitor count, traffic sources, event stats), so an admin view can show real traffic next to the app's own data. Consult `askMindStudioSdk` for the query API when building one.
|
|
127
127
|
|
|
128
|
-
- **Live UI updates come from the events namespace, not polling** — backend code publishes to named channels (`events.publish`, agent SDK) and the page receives them instantly via `events.connect` (interface SDK). Live dashboards, notifications, chat, multi-tab sync. Load the `
|
|
128
|
+
- **Live UI updates come from the events namespace, not polling** — backend code publishes to named channels (`events.publish`, agent SDK) and the page receives them instantly via `events.connect` (interface SDK). Live dashboards, notifications, chat, multi-tab sync. Load the `realtimeEvents` skill before designing with it.
|
|
129
129
|
|
|
130
130
|
Analytics is **cookie-banner-free by design**: per-app scoping, IP discarded after geo lookup, country-level only, query strings server-scrubbed except for a UTM whitelist (`utm_*`, `ref`, `source`, `gclid`, `fbclid`, `msclkid`), no fingerprinting, no third-party scripts. If a user asks about GDPR cookie consent for analytics, you can explain why it is not needed.
|
|
131
131
|
|
|
@@ -157,4 +157,4 @@ For multi-step tasks where the model needs to autonomously compose actions (rese
|
|
|
157
157
|
|
|
158
158
|
### Realtime Events
|
|
159
159
|
|
|
160
|
-
Server→client push, no polling: `events.publish(channels, data)` from any method/cron/webhook reaches connected clients instantly; `events.grant(channels)` in a method (after your auth checks) mints the subscribe token the frontend's `events.connect` consumes. This is how live dashboards, notifications, chat, and multi-tab sync work — whenever you're about to write a frontend polling loop against your own backend, reach for this instead. Load the `
|
|
160
|
+
Server→client push, no polling: `events.publish(channels, data)` from any method/cron/webhook reaches connected clients instantly; `events.grant(channels)` in a method (after your auth checks) mints the subscribe token the frontend's `events.connect` consumes. This is how live dashboards, notifications, chat, and multi-tab sync work — whenever you're about to write a frontend polling loop against your own backend, reach for this instead. Load the `realtimeEvents` skill before designing with it: channel shape (per-user fan-out vs broadcast) is the decision that matters, and the skill carries it.
|
package/package.json
CHANGED
|
File without changes
|