@zmeel/server 0.3.1 → 2026.404.0-canary.0
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/dist/app.d.ts +1 -0
- package/dist/app.d.ts.map +1 -1
- package/dist/app.js +1 -0
- package/dist/app.js.map +1 -1
- package/dist/auth/better-auth.d.ts +1 -1
- package/dist/auth/better-auth.d.ts.map +1 -1
- package/dist/auth/better-auth.js +13 -1
- package/dist/auth/better-auth.js.map +1 -1
- package/dist/config.d.ts +1 -0
- package/dist/config.d.ts.map +1 -1
- package/dist/config.js +6 -2
- package/dist/config.js.map +1 -1
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +2 -1
- package/dist/index.js.map +1 -1
- package/dist/routes/authz.d.ts +5 -5
- package/dist/routes/health.d.ts +1 -0
- package/dist/routes/health.d.ts.map +1 -1
- package/dist/routes/health.js +6 -1
- package/dist/routes/health.js.map +1 -1
- package/dist/services/activity.d.ts +3 -3
- package/dist/services/agents.d.ts +3 -3
- package/dist/services/approvals.d.ts +2 -2
- package/dist/services/costs.d.ts +2 -2
- package/dist/services/feedback.d.ts +2 -2
- package/dist/services/finance.d.ts +2 -2
- package/dist/services/goals.d.ts +6 -6
- package/dist/services/heartbeat.d.ts +17 -17
- package/dist/services/issues.d.ts +3 -3
- package/dist/services/plugin-registry.d.ts +73 -73
- package/dist/services/routines.d.ts +15 -15
- package/dist/services/saas-provisioning.d.ts +17 -0
- package/dist/services/saas-provisioning.d.ts.map +1 -0
- package/dist/services/saas-provisioning.js +55 -0
- package/dist/services/saas-provisioning.js.map +1 -0
- package/dist/services/workspace-runtime.d.ts +2 -2
- package/package.json +14 -14
- package/skills/para-memory-files/SKILL.md +104 -0
- package/skills/para-memory-files/references/schemas.md +35 -0
- package/skills/zmeel/SKILL.md +390 -0
- package/skills/zmeel/references/api-reference.md +721 -0
- package/skills/zmeel/references/company-skills.md +193 -0
- package/skills/zmeel/references/routines.md +187 -0
- package/skills/zmeel-create-agent/SKILL.md +142 -0
- package/skills/zmeel-create-agent/references/api-reference.md +105 -0
- package/skills/zmeel-create-plugin/SKILL.md +101 -0
|
@@ -0,0 +1,101 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: zmeel-create-plugin
|
|
3
|
+
description: >
|
|
4
|
+
Create new zmeel plugins with the current alpha SDK/runtime. Use when
|
|
5
|
+
scaffolding a plugin package, adding a new example plugin, or updating plugin
|
|
6
|
+
authoring docs. Covers the supported worker/UI surface, route conventions,
|
|
7
|
+
scaffold flow, and verification steps.
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Create a zmeel Plugin
|
|
11
|
+
|
|
12
|
+
Use this skill when the task is to create, scaffold, or document a zmeel plugin.
|
|
13
|
+
|
|
14
|
+
## 1. Ground rules
|
|
15
|
+
|
|
16
|
+
Read these first when needed:
|
|
17
|
+
|
|
18
|
+
1. `doc/plugins/PLUGIN_AUTHORING_GUIDE.md`
|
|
19
|
+
2. `packages/plugins/sdk/README.md`
|
|
20
|
+
3. `doc/plugins/PLUGIN_SPEC.md` only for future-looking context
|
|
21
|
+
|
|
22
|
+
Current runtime assumptions:
|
|
23
|
+
|
|
24
|
+
- plugin workers are trusted code
|
|
25
|
+
- plugin UI is trusted same-origin host code
|
|
26
|
+
- worker APIs are capability-gated
|
|
27
|
+
- plugin UI is not sandboxed by manifest capabilities
|
|
28
|
+
- no host-provided shared plugin UI component kit yet
|
|
29
|
+
- `ctx.assets` is not supported in the current runtime
|
|
30
|
+
|
|
31
|
+
## 2. Preferred workflow
|
|
32
|
+
|
|
33
|
+
Use the scaffold package instead of hand-writing the boilerplate:
|
|
34
|
+
|
|
35
|
+
```bash
|
|
36
|
+
pnpm --filter @zmeel/create-zmeel-plugin build
|
|
37
|
+
node packages/plugins/create-zmeel-plugin/dist/index.js <npm-package-name> --output <target-dir>
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
For a plugin that lives outside the zmeel repo, pass `--sdk-path` and let the scaffold snapshot the local SDK/shared packages into `.zmeel-sdk/`:
|
|
41
|
+
|
|
42
|
+
```bash
|
|
43
|
+
pnpm --filter @zmeel/create-zmeel-plugin build
|
|
44
|
+
node packages/plugins/create-zmeel-plugin/dist/index.js @acme/plugin-name \
|
|
45
|
+
--output /absolute/path/to/plugin-repos \
|
|
46
|
+
--sdk-path /absolute/path/to/zmeel/packages/plugins/sdk
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
Recommended target inside this repo:
|
|
50
|
+
|
|
51
|
+
- `packages/plugins/examples/` for example plugins
|
|
52
|
+
- another `packages/plugins/<name>/` folder if it is becoming a real package
|
|
53
|
+
|
|
54
|
+
## 3. After scaffolding
|
|
55
|
+
|
|
56
|
+
Check and adjust:
|
|
57
|
+
|
|
58
|
+
- `src/manifest.ts`
|
|
59
|
+
- `src/worker.ts`
|
|
60
|
+
- `src/ui/index.tsx`
|
|
61
|
+
- `tests/plugin.spec.ts`
|
|
62
|
+
- `package.json`
|
|
63
|
+
|
|
64
|
+
Make sure the plugin:
|
|
65
|
+
|
|
66
|
+
- declares only supported capabilities
|
|
67
|
+
- does not use `ctx.assets`
|
|
68
|
+
- does not import host UI component stubs
|
|
69
|
+
- keeps UI self-contained
|
|
70
|
+
- uses `routePath` only on `page` slots
|
|
71
|
+
- is installed into zmeel from an absolute local path during development
|
|
72
|
+
|
|
73
|
+
## 4. If the plugin should appear in the app
|
|
74
|
+
|
|
75
|
+
For bundled example/discoverable behavior, update the relevant host wiring:
|
|
76
|
+
|
|
77
|
+
- bundled example list in `server/src/routes/plugins.ts`
|
|
78
|
+
- any docs that list in-repo examples
|
|
79
|
+
|
|
80
|
+
Only do this if the user wants the plugin surfaced as a bundled example.
|
|
81
|
+
|
|
82
|
+
## 5. Verification
|
|
83
|
+
|
|
84
|
+
Always run:
|
|
85
|
+
|
|
86
|
+
```bash
|
|
87
|
+
pnpm --filter <plugin-package> typecheck
|
|
88
|
+
pnpm --filter <plugin-package> test
|
|
89
|
+
pnpm --filter <plugin-package> build
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
If you changed SDK/host/plugin runtime code too, also run broader repo checks as appropriate.
|
|
93
|
+
|
|
94
|
+
## 6. Documentation expectations
|
|
95
|
+
|
|
96
|
+
When authoring or updating plugin docs:
|
|
97
|
+
|
|
98
|
+
- distinguish current implementation from future spec ideas
|
|
99
|
+
- be explicit about the trusted-code model
|
|
100
|
+
- do not promise host UI components or asset APIs
|
|
101
|
+
- prefer npm-package deployment guidance over repo-local workflows for production
|