@jskit-ai/agent-docs 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.
Files changed (42) hide show
  1. package/DISTR_AGENT.md +11 -1
  2. package/guide/agent/app-extras/assistant.md +1 -1
  3. package/guide/agent/app-extras/realtime.md +1 -1
  4. package/guide/agent/app-setup/a-more-interesting-shell.md +1 -1
  5. package/guide/agent/app-setup/authentication.md +9 -1
  6. package/guide/agent/app-setup/console.md +1 -1
  7. package/guide/agent/app-setup/database-layer.md +1 -1
  8. package/guide/agent/app-setup/initial-scaffolding.md +1 -1
  9. package/guide/agent/app-setup/multi-homing.md +3 -1
  10. package/guide/agent/app-setup/users.md +1 -1
  11. package/guide/agent/app-setup/working-with-the-jskit-cli.md +1 -1
  12. package/guide/agent/generators/advanced-cruds.md +163 -1
  13. package/guide/agent/generators/crud-generators.md +30 -1
  14. package/guide/agent/generators/intro.md +1 -1
  15. package/guide/agent/generators/ui-generators.md +1 -1
  16. package/guide/agent/index.md +1 -1
  17. package/package.json +1 -1
  18. package/reference/autogen/packages/agent-docs.md +18 -0
  19. package/skills/jskit-review/SKILL.md +12 -2
  20. package/templates/APP_BLUEPRINT.md +9 -0
  21. package/templates/WORKBOARD.md +3 -3
  22. package/templates/app/AGENTS.md +15 -3
  23. package/workflow/bootstrap.md +17 -2
  24. package/workflow/feature-delivery.md +19 -3
  25. package/workflow/review.md +9 -3
  26. package/workflow/scoping.md +10 -1
  27. package/workflow/workboard.md +1 -1
  28. package/guide/human/app-extras/assistant.md +0 -693
  29. package/guide/human/app-extras/realtime.md +0 -268
  30. package/guide/human/app-setup/a-more-interesting-shell.md +0 -732
  31. package/guide/human/app-setup/authentication.md +0 -961
  32. package/guide/human/app-setup/console.md +0 -350
  33. package/guide/human/app-setup/database-layer.md +0 -820
  34. package/guide/human/app-setup/initial-scaffolding.md +0 -753
  35. package/guide/human/app-setup/multi-homing.md +0 -793
  36. package/guide/human/app-setup/users.md +0 -402
  37. package/guide/human/app-setup/working-with-the-jskit-cli.md +0 -1047
  38. package/guide/human/generators/advanced-cruds.md +0 -921
  39. package/guide/human/generators/crud-generators.md +0 -554
  40. package/guide/human/generators/intro.md +0 -107
  41. package/guide/human/generators/ui-generators.md +0 -663
  42. package/guide/human/index.md +0 -37
@@ -1,268 +0,0 @@
1
- # Realtime
2
-
3
- At the end of the previous chapter, the app already had a real shell, authenticated users, operator tooling, and workspace-aware routing. What it still did not have was a live transport for pushing updates into that shell.
4
-
5
- This chapter installs `realtime`, which adds JSKIT's socket.io runtime, Vite websocket proxy wiring, and a small connection indicator in the shell.
6
-
7
- This package is a good example of an "extra" rather than a new structural layer. It does not create new surfaces and it does not generate new pages. Instead, it plugs live behavior into things the guide has already scaffolded.
8
-
9
- ## Recap from previous chapters
10
-
11
- To get back to the same starting point as the end of the previous chapter, run:
12
-
13
- ```bash
14
- SUPABASE_URL=...
15
- SUPABASE_KEY=...
16
- DB_HOST=127.0.0.1
17
- DB_PORT=3306
18
- DB_NAME=exampleapp
19
- DB_USER=exampleapp
20
- DB_PASSWORD=secret
21
-
22
- npx @jskit-ai/create-app exampleapp --tenancy-mode personal
23
- cd exampleapp
24
- npm install
25
-
26
- npx jskit add package shell-web
27
- npx jskit add package auth-provider-supabase-core \
28
- --auth-supabase-url "$SUPABASE_URL" \
29
- --auth-supabase-publishable-key "$SUPABASE_KEY" \
30
- --app-public-url "http://localhost:5173"
31
- npx jskit add bundle auth-base
32
- npx jskit add package database-runtime-mysql \
33
- --db-host "$DB_HOST" \
34
- --db-port "$DB_PORT" \
35
- --db-name "$DB_NAME" \
36
- --db-user "$DB_USER" \
37
- --db-password "$DB_PASSWORD"
38
- npx jskit add package users-web
39
- npx jskit add package console-web
40
- npx jskit add package workspaces-core
41
- npx jskit add package workspaces-web
42
- npm install
43
- npm run db:migrate
44
- ```
45
-
46
- If you are already continuing from the previous chapter, you are already in the right place and can skip that setup.
47
-
48
- <DocsTerminalTip label="Redis" title="Empty Is Fine Locally">
49
- `realtime` writes `REALTIME_REDIS_URL` into `.env`, but leaving it empty is a perfectly normal local setup.
50
-
51
- With no Redis URL, the package uses the in-memory socket adapter inside your single local Node process. That is enough for local development and for small single-instance deployments.
52
-
53
- You only need to set `REALTIME_REDIS_URL` when you want several server instances to share socket events through Redis.
54
- </DocsTerminalTip>
55
-
56
- ## Installing `realtime`
57
-
58
- From inside `exampleapp`, run:
59
-
60
- ```bash
61
- npx jskit add package realtime
62
- npm install
63
- ```
64
-
65
- The first command records the runtime package in the app and updates the existing scaffold. The second command downloads the new dependencies, especially `socket.io`, `socket.io-client`, and the optional Redis adapter pieces.
66
-
67
- Unlike the database, users, console, and workspace chapters, this one does **not** need `npm run db:migrate`. `realtime` does not add schema files. It is transport infrastructure, not persistence.
68
-
69
- ## What changes now
70
-
71
- Installing `realtime` changes the app in three important ways.
72
-
73
- ### The app gets a realtime transport
74
-
75
- The server now mounts a socket.io runtime on the same Fastify server that already serves your JSKIT surfaces. The browser gets a matching socket.io client runtime through the normal client boot process.
76
-
77
- That means later modules, or your own app code, can stop thinking only in terms of request/response HTTP flows. They can start publishing live events and listening for them in Vue.
78
-
79
- ### The shell gets a connection indicator
80
-
81
- The package also uses the shell scaffolding that already exists.
82
-
83
- `realtime` appends a placement entry into `src/placement.js` that targets `shell-layout:top-right`, so the shell starts showing a small status dot without you having to create a new page for it.
84
-
85
- That dot is:
86
-
87
- - green when the realtime socket is connected
88
- - red when the socket is disconnected or still reconnecting
89
-
90
- So the first visible value of the package is not a whole new screen. It is a tiny live status element plugged straight into the existing shell.
91
-
92
- ### Vite starts proxying websocket traffic too
93
-
94
- The app already had a browser dev server on `5173` and a backend runtime on `3000`.
95
-
96
- `realtime` extends that setup by writing a websocket proxy entry into `.jskit/vite.dev.proxy.json` for `/socket.io`. That matters because the browser should still talk to the frontend dev server on `5173`, while Vite quietly forwards websocket traffic to the backend runtime on `3000`.
97
-
98
- So one of the main values of this package is that you do **not** have to hand-edit Vite config just to make socket.io work in local development.
99
-
100
- ### There are still no new pages
101
-
102
- This is worth saying clearly because it can otherwise feel surprising.
103
-
104
- After installing `realtime`:
105
-
106
- - there is still no `/realtime` page
107
- - there is still no new surface
108
- - there is still no app-owned `src/pages/...` scaffold
109
-
110
- That is intentional. `realtime` is infrastructure. It makes the existing shell and later runtime packages live-capable instead of giving the app a new section of its own.
111
-
112
- ## What to look at in the browser
113
-
114
- Start both processes again:
115
-
116
- ```bash
117
- npm run dev
118
- npm run server
119
- ```
120
-
121
- Then open `http://localhost:5173/home`.
122
-
123
- The important visible change is in the top-right of the shell. You should now see the realtime status dot alongside the other shell controls.
124
-
125
- If the websocket connects successfully, the dot is green. If the backend is unavailable or the socket is reconnecting, the dot is red. Hovering it shows the current status text.
126
-
127
- That small change is the whole point of this chapter's browser check: the package is already active even though it did not create a page of its own.
128
-
129
- ## Using the client runtime
130
-
131
- The connection indicator is useful, but the real reason to install `realtime` is to let client code subscribe to live events.
132
-
133
- The smallest client-side example looks like this:
134
-
135
- ```vue
136
- <script setup>
137
- import { ref } from "vue";
138
- import { useRealtimeEvent } from "@jskit-ai/realtime/client/composables/useRealtimeEvent";
139
-
140
- const lastEvent = ref("Nothing received yet.");
141
-
142
- useRealtimeEvent({
143
- event: "demo.ping",
144
- onEvent({ payload }) {
145
- lastEvent.value = JSON.stringify(payload);
146
- }
147
- });
148
- </script>
149
-
150
- <template>
151
- <p>{{ lastEvent }}</p>
152
- </template>
153
- ```
154
-
155
- That composable does not create any server-side events by itself. It only subscribes the component to the client socket.
156
-
157
- The important pieces are:
158
-
159
- - `event`
160
- - the event name to listen for
161
- - if you omit it, the composable listens to `*`
162
- - `onEvent`
163
- - the handler that receives `{ event, payload, socket }`
164
- - `matches`
165
- - an optional predicate if you want to filter events before the handler runs
166
-
167
- So the mental model is:
168
-
169
- - `realtime` gives the app a live transport
170
- - your own app code, or later packages, decide which events should travel across it
171
-
172
- ## What `realtime` adds to the app
173
-
174
- This chapter is small enough that it is worth looking directly at the app-owned files it changes.
175
-
176
- ### `.env` gains the Redis adapter setting
177
-
178
- The install writes:
179
-
180
- ```dotenv
181
- REALTIME_REDIS_URL=
182
- ```
183
-
184
- That empty value is deliberate. It means the app can start with the in-memory adapter locally, and you can fill in a real Redis URL later if you need cross-instance fan-out.
185
-
186
- ### `.jskit/vite.dev.proxy.json` gains a websocket proxy entry
187
-
188
- After the install, the app has:
189
-
190
- ```json
191
- {
192
- "version": 1,
193
- "entries": [
194
- {
195
- "packageId": "@jskit-ai/realtime",
196
- "id": "realtime-socket-io",
197
- "path": "/socket.io",
198
- "changeOrigin": true,
199
- "ws": true
200
- }
201
- ]
202
- }
203
- ```
204
-
205
- That one entry is what lets the browser dev server proxy websocket traffic correctly during local development.
206
-
207
- ### `src/placement.js` grows one new shell placement
208
-
209
- The package appends this placement:
210
-
211
- ```js
212
- addPlacement({
213
- id: "realtime.connection.indicator",
214
- target: "shell-layout:top-right",
215
- surfaces: ["*"],
216
- order: 950,
217
- componentToken: "realtime.web.connection.indicator"
218
- });
219
- ```
220
-
221
- That is a good example of JSKIT's placement model working as intended.
222
-
223
- `realtime` does not need to own your shell component. It just contributes one widget into an outlet that `shell-web` already exposed.
224
-
225
- ### `package.json` gets the runtime dependencies
226
-
227
- The install also adds the runtime packages needed for transport:
228
-
229
- - `@jskit-ai/realtime`
230
- - `socket.io`
231
- - `socket.io-client`
232
- - Redis adapter dependencies for scaled deployments
233
-
234
- That is why `npm install` is still required even though this chapter only touches a small number of app-owned files.
235
-
236
- ## Under the hood
237
-
238
- The internal model is simple.
239
-
240
- - the server provider mounts socket.io at `/socket.io`
241
- - the client provider creates one shared socket client for the Vue app
242
- - the shell status dot is registered as `realtime.web.connection.indicator`
243
-
244
- On the server side, the package also publishes container tokens such as:
245
-
246
- - `runtime.realtime`
247
- - `runtime.realtime.io`
248
-
249
- And on the client side it publishes:
250
-
251
- - `runtime.realtime.client.socket`
252
-
253
- If `REALTIME_REDIS_URL` is empty, the server uses a normal single-process socket.io server. If the URL is set, the package enables the Redis adapter so several Node processes can share realtime events.
254
-
255
- That is the right level of abstraction for this package:
256
-
257
- - generic transport in the runtime
258
- - visible status in the shell
259
- - actual event meaning left to the app or to later packages
260
-
261
- ## Summary
262
-
263
- This chapter does not make the app look radically different, but it adds an important new capability.
264
-
265
- - the backend can now host a realtime socket server
266
- - the frontend can now keep one shared websocket connection alive
267
- - the shell now exposes a live connection indicator
268
- - later modules can build live behavior on top of that transport without inventing their own websocket setup