@jskit-ai/agent-docs 0.1.290 → 0.1.292

package/skills/jskit/references/patterns/database/postgres-application/example/package.json

@@ -9,7 +9,7 @@
     "test": "jskit test --databases"
   },
   "dependencies": {
-    "@jskit-ai/database-runtime": "0.1.265",
-    "@jskit-ai/database-runtime-postgres": "0.1.262"
+    "@jskit-ai/database-runtime": "0.1.266",
+    "@jskit-ai/database-runtime-postgres": "0.1.263"
   }
 }

package/skills/jskit/references/patterns/realtime/realtime-application/example/package.json

@@ -2,7 +2,7 @@
   "private": true,
   "type": "module",
   "dependencies": {
-    "@jskit-ai/realtime": "0.2.23",
-    "@jskit-ai/shell-web": "0.2.20"
+    "@jskit-ai/realtime": "0.2.24",
+    "@jskit-ai/shell-web": "0.2.21"
   }
 }

package/skills/jskit/references/patterns/server/feature-package/example/booking-engine/package.json

@@ -5,7 +5,7 @@
   "private": true,
   "type": "module",
   "dependencies": {
-    "@jskit-ai/kernel": "0.2.16",
+    "@jskit-ai/kernel": "0.2.17",
     "json-rest-schema": "^1.0.17"
   },
   "exports": {

package/skills/jskit/references/patterns/users/user-administration-server/example/packages/users/package.json

@@ -10,9 +10,9 @@
     "./shared": "./src/shared/index.js"
   },
   "dependencies": {
-    "@jskit-ai/crud-core": "0.2.20",
-    "@jskit-ai/resource-crud-core": "0.1.207",
-    "@jskit-ai/users-core": "0.2.21"
+    "@jskit-ai/crud-core": "0.2.22",
+    "@jskit-ai/resource-crud-core": "0.1.208",
+    "@jskit-ai/users-core": "0.2.23"
   },
   "jskit": {
     "kind": "runtime",

package/skills/jskit/references/patterns/users/user-administration-server/example/packages/users-workspace/package.json

@@ -10,14 +10,14 @@
     "./shared": "./src/shared/index.js"
   },
   "dependencies": {
-    "@jskit-ai/crud-core": "0.2.20",
-    "@jskit-ai/resource-crud-core": "0.1.207",
-    "@jskit-ai/users-core": "0.2.21",
-    "@jskit-ai/workspaces-core": "0.2.21"
+    "@jskit-ai/crud-core": "0.2.22",
+    "@jskit-ai/resource-crud-core": "0.1.208",
+    "@jskit-ai/users-core": "0.2.23",
+    "@jskit-ai/workspaces-core": "0.2.23"
   },
   "peerDependencies": {
-    "@jskit-ai/kernel": "0.2.16",
-    "@jskit-ai/resource-runtime": "0.2.17"
+    "@jskit-ai/kernel": "0.2.17",
+    "@jskit-ai/resource-runtime": "0.2.19"
   },
   "jskit": {
     "kind": "runtime",

package/skills/jskit/references/sanity-checks.md

@@ -4,9 +4,9 @@
 
 Before calling a list, a save, a test, a refactor, a screen or a deployment
 done, measure what it costs and does, judge whether that is sane, and fix the
-cause when it is not. This page holds JSKIT's part: the pitfalls JSKIT's own
+cause when it is not. This page holds JSKIT's part: the pitfalls its own
 packages cause, then the JSKIT call, helper or setting that applies each
-check, with one line on what it catches and why.
+check, and what it catches.
 
 ## JSKIT's own pitfalls
 
@@ -67,10 +67,14 @@ expects the relationship id or an unselected field never gets it.
 ### Every row
 
 - A handle's `query()` answers one page and refuses a missing or oversized
-  `page.size`, because json-rest-api would otherwise cut the list without an
-  error. A read its callers treat as complete uses `queryAll()`, because the
-  missing rows otherwise vanish from every picker and delivery built on it
+  `page.size`, where json-rest-api would cut the list silently. A read its
+  callers treat as complete uses `queryAll()`, or the missing rows vanish from
+  every picker and delivery built on it
   ([Reads](data-access.md#reads-shaped-for-the-screen)).
+- A grouped `aggregate()` answers every group or throws
+  `RESOURCE_GROUP_LIMIT`; past `pageLimits().request` groups, page it with
+  `page: { size, number }`
+  ([The handle's calls](data-access.md#the-handle-s-calls)).
 - A lookup by a unique key matches at most one row: `get(id)`, or a `query()`
   of page size 1.
 
@@ -79,12 +83,11 @@ expects the relationship id or an unselected field never gets it.
 - Count a path's queries with `expectFlatQueries()` from
   `@jskit-ai/resource-runtime/test`, or `countQueries()` from
   `@jskit-ai/database-runtime/server/testDatabases`, at a few rows and at a
-  realistic number; the count should follow tables and pages, not rows
+  realistic number; it should follow tables and pages, not rows
   ([Tests](data-access.md#tests)).
 - A JSON:API read adds a few lookup and visibility queries per page and per
-  relationship field, and json-rest-api reads each relationship's related ids
-  in one statement however many rows the page has. Both follow pages, not
-  rows, so `expectFlatQueries` passes them.
+  relationship field, and one statement per relationship for its related ids.
+  Both follow pages, not rows, so `expectFlatQueries` passes them.
 - A handle's `get()` or `query()`, or a service `get`, inside a loop is the
   usual per-row read; batch it with an id-list filter through `queryAll()` or
   `include`, grouped with `Map.groupBy()`
@@ -108,11 +111,15 @@ expects the relationship id or an unselected field never gets it.
   `DB_NAME`, because tests write and delete rows and would destroy the
   developer's data. A skip for want of a test database is a failure.
 - Test databases restore a stored snapshot checked by a digest of the
-  migration and seed sources, and the harness reports each preparation phase's
-  duration, so slow preparation shows ([Test databases are prepared
+  migration and seed sources, and the harness times each preparation phase,
+  so slow preparation shows ([Test databases are prepared
   once](typed-features.md#test-databases-are-prepared-once),
   [integration test
   databases](database-layer.md#integration-test-databases)).
+- A component's content and states are checked in a Vitest component test;
+  a browser check is an assertion in the Playwright spec that already reaches
+  that screen. Every Playwright run ends with its 10 slowest tests: compare a
+  new test's time, and the suite's, before and after.
 
 ### Inputs and access
 
@@ -135,7 +142,7 @@ Before changing a JSKIT feature, list where its behaviour lives, with the test
 that covers each item, and walk the list again after: routes, actions and
 their input schemas, row policies, CRUD fields, lookups and hooks, placements
 and navigation meta, messages and their codes, events, jobs and migrations.
-These are the places a consolidation drops behaviour without a failing build.
+A consolidation drops behaviour there without a failing build.
 
 ### Changes others depend on