@owlmeans/server-planning 0.1.18-rc.28 → 0.1.18-rc.29

package/README.md

@@ -10,7 +10,7 @@ the `@owlmeans/server-planning/store` subpath.
 ## Installation
 
 ```sh
-bun add @owlmeans/server-planning@^0.1.18-rc.27 @owlmeans/planning@^0.1.18-rc.23 ajv
+bun add @owlmeans/server-planning@^0.1.18-rc.29 @owlmeans/planning@^0.1.18-rc.25 ajv
 ```
 
 ## Concepts

package/agent-meta/manifest.json

@@ -1,8 +1,8 @@
 {
   "schemaVersion": 2,
   "package": "@owlmeans/server-planning",
-  "version": "0.1.18-rc.28",
-  "generatedAt": "2026-10-09T13:40:06.949Z",
+  "version": "0.1.18-rc.29",
+  "generatedAt": "2026-10-09T17:24:50.729Z",
   "canonicalRepo": "https://github.com/owlmeans/common",
   "entries": [
     {

package/agent-meta/skills/server-planning/SKILL.md

@@ -8,7 +8,7 @@ user-invocable: false
 # @owlmeans/server-planning
 
 **Layer:** Server
-**Install:** `"@owlmeans/server-planning": "^0.1.18-rc.28"` in `dependencies` (`ajv` is a peer)
+**Install:** `"@owlmeans/server-planning": "^0.1.18-rc.29"` in `dependencies` (`ajv` is a peer)
 
 The general implementation of `@owlmeans/planning`: the planning service (a plugin host), the
 scoped facade, the executor every write goes through, the in-memory reference store, the commit
@@ -300,26 +300,25 @@ mapping external records (`mappers`) belongs to that plugin's own store adapter.
 decision per request; a throw is the request's answer (an `AuthForbidden` answers 403).
 
 - `entityId` is the resolver's — never the token's, never `opts.scope`'s.
-- `projects` becomes `PlanningScope.projects`, which the server facade enforces on every read and
-  write. Visible are the projects, every card whose `parents` name one, and every specification
-  whose parent card is visible (its `parents` hold only that card). Anything else reads as absent
+- `projects` becomes `PlanningScope.projects`, which the server facade enforces on reads and
+  writes. A card is visible when at least one project reached through its recursive parent paths
+  is allowed; specifications follow their containing cards. Anything else reads as absent
   (`WorkcardNotFound`, `null`, an empty list); a create under an invisible parent is
-  `ParentNotFound`; links and transitions are filtered by `project` (and post-filtered, for a store
-  that ignores the field); commit subscriptions drop events outside the set and a status or wait
-  refuses them.
-- **A narrowed list or count sees a specification whenever its parent card is visible** — exactly
-  what a single read admits. It is AND'd with `projectCriteriaOf(projects, through)`; when its
-  criteria ask for specifications (`wantsSpecifications`) the facade resolves `through` (the visible
-  parent cards) with ONE read per call: the query's `parent`, else the projects' own cards. A
-  summary counts no specification and pays nothing extra. `tests/narrowing.spec.ts` pins it.
+  `ParentNotFound`. Links, transitions and commits use current endpoint/card ancestry, with a
+  cached project fallback only for purged records. Subscriptions and commit waits enforce the
+  same visibility.
+- **Narrowed lists, counts and summaries use the allowed recursive descendant IDs before paging.**
+  A specification is admitted through the same containing-card hierarchy as a single read.
+  Do not replace this with a direct-parent query or a filter applied after pagination.
+  `tests/narrowing.spec.ts` and shared hierarchy conformance pin this behavior.
 - A person who may see only SOME projects of their organization (a tool-shed volunteer given one
   shed) is expressed here: the resolver answers the project ids the person's grants list as
   `projects`, and omits the key when a grant covers every project — never a hand-written filter in
   each handler.
 - `writes` is the subset of projects the person may WRITE in (`projects` are the ones they VIEW).
-  `execute` on a card, specification or link needs it to be writable — the rule a narrowed read
-  admits, over `writes`: the project itself, a card whose `parents` name one, a specification
-  through its parent card; a create needs every named parent writable, and a create at the root
+  `execute` on a card, specification or link needs it to be writable — the recursive ancestor
+  rule over `writes`: a card admitted directly or through a writable parent path. A create needs
+  every named parent writable; reparenting checks every supplied destination parent. A create at the root
   (no parent, not a project) is refused. `schema.define` of a project layer needs the project in
   `writes`. A refusal is `PlanningForbidden` (403, `forbidden:writes:<id>`), checked before the grants
   and before the executor. NOT governed by it: a project create (`grants.createProjects` alone) and

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@owlmeans/server-planning",
-  "version": "0.1.18-rc.28",
+  "version": "0.1.18-rc.29",
   "license": "MIT",
   "description": "The general planning implementation — the planning service and its plugin/middleware registry, the transition executor, the in-memory store, the protocol handlers and the commit feed.",
   "type": "module",
@@ -50,7 +50,7 @@
     "@owlmeans/context": "^0.1.18-rc.34",
     "@owlmeans/entrypoint": "^0.1.18-rc.41",
     "@owlmeans/error": "^0.1.18-rc.38",
-    "@owlmeans/planning": "^0.1.18-rc.24",
+    "@owlmeans/planning": "^0.1.18-rc.25",
     "@owlmeans/queue": "^0.1.18-rc.44",
     "@owlmeans/resource": "^0.1.18-rc.40",
     "@owlmeans/log": "^0.1.18-rc.3",