@ekanos/cli 0.1.3 → 0.1.4
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.
- package/package.json +2 -2
- package/templates/AGENTS.md.tmpl +23 -1
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@ekanos/cli",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.4",
|
|
4
4
|
"type": "module",
|
|
5
5
|
"description": "The Ekanos partner toolchain CLI: scaffold, validate, and test a Fusion integration against the published @ekanos packages. Agent-native — every verb speaks JSON with a stable exit-code taxonomy.",
|
|
6
6
|
"license": "MIT",
|
|
@@ -32,7 +32,7 @@
|
|
|
32
32
|
"access": "public"
|
|
33
33
|
},
|
|
34
34
|
"dependencies": {
|
|
35
|
-
"@ekanos/integration-schema": "0.1.
|
|
35
|
+
"@ekanos/integration-schema": "0.1.4",
|
|
36
36
|
"esbuild": "0.28.1"
|
|
37
37
|
},
|
|
38
38
|
"peerDependencies": {
|
package/templates/AGENTS.md.tmpl
CHANGED
|
@@ -29,6 +29,7 @@ export const integration = defineIntegration<MyStorage>({
|
|
|
29
29
|
tools: [ /* assistant-callable functions */ ],
|
|
30
30
|
webhooks: [ /* inbound deliveries */ ],
|
|
31
31
|
schedules: [ /* cron runs */ ],
|
|
32
|
+
onActivate: async (ctx) => { /* seed caches, sanity-check credentials */ },
|
|
32
33
|
storage: { account: { /* key → zod schema */ } },
|
|
33
34
|
egress: ['https://api.example.com'],
|
|
34
35
|
});
|
|
@@ -45,7 +46,7 @@ lives in both files; `ekanos validate` reports a finding if they disagree.
|
|
|
45
46
|
## The capability context (`ctx`) — the ONLY platform surface
|
|
46
47
|
|
|
47
48
|
Every server-side handler (tool `run`, webhook `handler`, schedule `handler`,
|
|
48
|
-
`oauth.onTokens`) receives one `ctx` object, already scoped to
|
|
49
|
+
`oauth.onTokens`, `onActivate`) receives one `ctx` object, already scoped to
|
|
49
50
|
`{account, integration}` before your code runs.
|
|
50
51
|
|
|
51
52
|
**Hard rule: NEVER use global `fetch`, `process.env`, or `node:fs` in
|
|
@@ -148,6 +149,27 @@ failure). Schedule results: `{ status: 'completed' }` / `{ status: 'skipped' }`
|
|
|
148
149
|
(`invocation.trigger` distinguishes them). Cron is 5-field numeric only — no
|
|
149
150
|
names, no `@daily`, no seconds.
|
|
150
151
|
|
|
152
|
+
### `onActivate`
|
|
153
|
+
|
|
154
|
+
Runs once after an activation is first persisted, and again after
|
|
155
|
+
activationData is updated — **seed the cache in `onActivate`; the schedule
|
|
156
|
+
keeps it fresh.** Without it, a cache-backed widget is empty until the first
|
|
157
|
+
schedule tick. v1 errors are non-fatal: a throw is logged as a warning and the
|
|
158
|
+
activation stays connected, so this is for cache seeding and eager
|
|
159
|
+
validation, never a connect gate. Seed BEST-EFFORT: catch transient upstream
|
|
160
|
+
failures (timeouts, 5xx), log, and return — a throw surfaces a scary warning
|
|
161
|
+
on a brand-new connection that the schedule will heal within one tick anyway.
|
|
162
|
+
Reserve the throw for misconfiguration the user can actually fix.
|
|
163
|
+
|
|
164
|
+
A cache invalidated only by age still serves the *previous* activation's data
|
|
165
|
+
for a while even with `onActivate` wired up. Close that gap with a
|
|
166
|
+
fingerprint: store a hash of the activation fields a cached value's **values**
|
|
167
|
+
depended on (not just the ones that pick which data to fetch — currency, units
|
|
168
|
+
and locale change the numbers without changing the cache key) alongside the
|
|
169
|
+
value, and treat a mismatch or an absent fingerprint on read as a miss.
|
|
170
|
+
Declare that field `.optional()` on the storage schema, or every pre-existing
|
|
171
|
+
row throws `StorageValidationError` on read.
|
|
172
|
+
|
|
151
173
|
## Widgets
|
|
152
174
|
|
|
153
175
|
Dashboard widgets are client components (`'use client'`) declared at
|