@rytass/bpm-core-nestjs-module 0.1.4 → 0.1.5

package/CHANGELOG.md

@@ -9,6 +9,55 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 Releases are managed by [`nx release`](https://nx.dev/recipes/nx-release) with
 Conventional Commits — see `nx.json` for the release config.
 
+## 0.1.5 — 2026-05-28
+
+### Documentation
+
+- **Identity contract clarifications.** `BPMMemberResolver.resolve` JSDoc
+  now states the unknown-id contract explicitly (throw
+  `MemberNotFoundException`); `resolveMany` documents the diverging
+  partial-success contract (omit unknown ids from the returned `Map`).
+  Both methods cross-link `identityMemberMetadataCacheTtlMs`
+  (default 5 min) so consumers know BPM caches their resolver responses.
+- **`BPMRootModule` JSDoc dangling refs removed.** The previous
+  references to `docs/10-bpm-embedding-auth.md` and
+  `docs/11-consumer-quickstart.md` (files that never shipped) are now
+  inline pointers to the README sections.
+- **New "Organization data ownership" README section.** Documents that
+  BPM is authoritative for `org_units`, `positions`, `memberships`, and
+  `manager_resolutions` (no host-injectable resolver pattern, unlike
+  members), the rationale (approver-routing / tree-diff hot path), the
+  mirror pattern using `OrgUnit.code` as the natural key and the
+  `metadata` JSON for host foreign-keys, and an idempotent worked
+  example using only `@rytass/bpm-core-client/organization` exports.
+
+### Why a patch
+
+No public type signatures change. JSDoc + README only.
+
+## 0.1.4 — 2026-05-27
+
+### Fixed
+
+- **Re-publish of the 0.1.3 release.** The 0.1.3 tarball was inadvertently
+  published from `libs/bpm-core/` instead of from `dist/libs/bpm-core/`,
+  shipping only TypeScript sources with `main: "./src/index.js"` pointing
+  at non-existent files. 0.1.3 has been **deprecated on npm**. The
+  publish procedure (`docs/api-reference.md` Publish Procedure section
+  and `tools/publish/finalize-dist-package.mjs` header) now codifies the
+  correct flow: `nx build` → `finalize-dist-package.mjs` →
+  `cd dist/libs/<pkg> && npm publish`.
+
+### Documentation
+
+- Publish-procedure-from-dist section added to `docs/api-reference.md`.
+- `tools/publish/finalize-dist-package.mjs` header warning expanded.
+
+## 0.1.3 — 2026-05-27 (deprecated on npm)
+
+**DO NOT INSTALL — broken release.** Published from source dir instead
+of dist dir; tarball contains only `.ts` files. Use 0.1.4 or newer.
+
 ## 0.1.2 — 2026-05-27
 
 ### Fixed

package/README.md

@@ -275,6 +275,149 @@ export interface BPMMemberResolver {
 }
 ```
 
+## Organization Data Ownership
+
+> **Read this before integrating BPM into a host that already has its own
+> organization model.** The org-integration shape is **asymmetric** with
+> member integration above — knowing which side owns what saves a day of
+> source spelunking.
+
+### Ownership claim
+
+BPM is the **sole authority** for four organization tables:
+
+| Table | Owns |
+|---|---|
+| `org_units` | Department / division / company nodes (typed by `OrgUnitType`) |
+| `positions` | Job titles, with optional org-unit scoping |
+| `memberships` | Member × org-unit × position relations (the join table that puts a member at a position inside a unit) |
+| `manager_resolutions` | "Who is whose manager" rules (per-member, per-org-unit, or per-position scope), consumed by the `ORG_MANAGER` approver resolver |
+
+There is **no** host-injectable `OrgUnitResolver` / `PositionResolver` /
+`MembershipResolver` pattern, deliberately so. If you went looking for
+the symmetric counterpart to `BPMMemberResolver`, stop now — it doesn't
+exist, and the rest of this section explains why and what to do instead.
+
+### Why no resolver
+
+The BPM workflow engine reads the org graph on hot paths:
+
+- **Approver routing** — every running instance evaluates `UserTaskNode`
+  candidates (resolved via `DIRECT`, `POSITION`, `ORG_MANAGER`, or
+  `CANDIDATE_GROUP`) against the current org snapshot. A `ParallelGateway`
+  fanning out to "all managers in the IT division" may touch dozens of
+  membership rows in one step.
+- **Tree-diff commits** — `commitOrgUnitTreeDraft` writes batched moves
+  inside a single transaction, with referential integrity against
+  `memberships` and `manager_resolutions`. Round-tripping each lookup
+  through a host adapter would make this prohibitively chatty.
+- **Reporting** — admin dashboards aggregate counts across the full graph.
+
+A read-through adapter would force the host to mirror BPM's tree
+semantics (ltree paths, soft-delete masking, position-vs-org-unit join
+shape) anyway. We chose to make BPM authoritative so the contract is one
+direction only.
+
+### Mirror pattern
+
+Host applications that already maintain their own org structure should
+**mirror their data into BPM** through the GraphQL mutations exposed by
+`@rytass/bpm-core-client/organization`. Three rules keep this idempotent
+and observable:
+
+1. **`OrgUnit.code` is your natural key.** Every `createOrgUnit` /
+   `createPosition` accepts a `code` field that you control. BPM enforces
+   uniqueness; use your host's stable identifier here (e.g. an LDAP DN
+   slug or a internal ERP code). On a re-sync, look up existing entities
+   by `code` before deciding INSERT vs UPDATE.
+2. **`metadata` is the host-FK stash.** Both `OrgUnit` and `Membership`
+   carry an opaque `metadata` JSON object that BPM never introspects.
+   Store your host's primary key here (e.g. `{ shuttleOrgUnitId: 12345 }`)
+   so you can chase the back-pointer when reconciling.
+3. **Soft delete via `deleteOrgUnit` / `deleteMembership`.** Deletes set
+   `deletedAt` rather than removing rows. BPM's query layer hides
+   soft-deleted rows automatically; reading `orgUnitCount()` will report
+   the live count.
+
+### Worked example: idempotent sync
+
+The example below uses only published exports from
+`@rytass/bpm-core-client/organization`. It pushes a host org tree into
+BPM, handling the create-or-update path by checking `code` matches.
+Verified exports: `orgUnits`, `createOrgUnit`, `updateOrgUnit`,
+`deleteOrgUnit`, `createPosition`, `createMembership`, `updateMembership`,
+`createManagerResolution`, `commitOrgUnitTreeDraft`.
+
+```ts
+import {
+  createOrgUnit,
+  updateOrgUnit,
+  createPosition,
+  createMembership,
+  orgUnits,
+  type OrgUnitRecord,
+} from '@rytass/bpm-core-client/organization';
+
+interface HostOrgUnit {
+  readonly hostId: string;     // e.g. ERP primary key — your host-FK
+  readonly code: string;       // stable across sync runs
+  readonly name: string;
+  readonly type: 'COMPANY' | 'DIVISION' | 'DEPARTMENT' | 'TEAM';
+  readonly parentCode: string | null;
+}
+
+async function syncOrgUnit(host: HostOrgUnit): Promise<OrgUnitRecord> {
+  // 1. Look up by host's stable code; BPM enforces uniqueness.
+  const existing = (
+    await orgUnits({ page: 1, pageSize: 1, searchText: host.code })
+  ).find((u) => u.code === host.code);
+
+  const parentId = host.parentCode
+    ? (await orgUnits({ searchText: host.parentCode })).find(
+        (u) => u.code === host.parentCode,
+      )?.id ?? null
+    : null;
+
+  // 2. Stash the host-FK back into metadata so future reconciliations
+  //    can chase the pointer either direction.
+  const metadataJson = JSON.stringify({ hostId: host.hostId });
+
+  if (existing) {
+    return updateOrgUnit({
+      id: existing.id,
+      input: {
+        code: host.code,
+        name: host.name,
+        type: host.type,
+        parentId,
+        metadataJson,
+      },
+    });
+  }
+
+  return createOrgUnit({
+    code: host.code,
+    name: host.name,
+    type: host.type,
+    parentId,
+    metadataJson,
+  });
+}
+```
+
+The same pattern works for `Position` (key on `code`), `Membership`
+(unique by `memberId × orgUnitId × positionId`), and
+`ManagerResolution` (unique by scope shape + active flag). For bulk
+tree-shape changes (multi-node moves under a single parent),
+`commitOrgUnitTreeDraft` accepts the full draft in one transaction.
+
+### What you do NOT mirror
+
+Member identity itself stays in your host's user table — BPM reaches it
+through `BPMMemberResolver` (see the previous section). Only the
+**org structure** (who reports where, what unit they sit in, who manages
+them) needs to live inside BPM.
+
 ## Root Module Configuration
 
 Use `BPMRootModule.forRoot()` for static configuration or

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rytass/bpm-core-nestjs-module",
-  "version": "0.1.4",
+  "version": "0.1.5",
   "description": "Embeddable NestJS BPM approval workflow module: workflow engine, approval templates, forms, organization/member contracts, attachments, signatures, notifications, delegation, and TypeORM migrations.",
   "keywords": [
     "bpm",
@@ -141,7 +141,7 @@
     "@nestjs/core": "^11.0.0",
     "@nestjs/graphql": "^13.4.0",
     "@nestjs/typeorm": "^11.0.1",
-    "@rytass/bpm-core-shared": "^0.1.4",
+    "@rytass/bpm-core-shared": "^0.1.5",
     "@rytass/secret-adapter-vault-nestjs": "^0.4.5 || ^0.5.0",
     "express": "^4.0.0 || ^5.0.0",
     "graphql": "^16.0.0",

package/src/lib/bpm/bpm-root.module.d.ts

@@ -112,9 +112,9 @@ export interface BPMRootModuleAsyncOptions extends Pick<ModuleMetadata, 'imports
  *
  * Hosts call `forRoot` or `forRootAsync` once from their root `AppModule`.
  * BPMCore does **not** own login, GraphQL setup, TypeORM bootstrap, or
- * Vault loading — those remain the host's responsibility. See
- * `docs/10-bpm-embedding-auth.md` and `docs/11-consumer-quickstart.md` for
- * the full contract.
+ * Vault loading — those remain the host's responsibility. See the
+ * package README sections "Embedding & auth", "Organization data
+ * ownership", and "Consumer quickstart" for the full contract.
  *
  * The host must avoid Nest's `app.setGlobalPrefix(...)`; BPM controllers
  * mount at relative paths driven by their respective options (notably

package/src/lib/bpm/bpm-root.module.js

@@ -24,9 +24,9 @@ const workflow_engine_module_1 = require("../workflow-engine/workflow-engine.mod
  *
  * Hosts call `forRoot` or `forRootAsync` once from their root `AppModule`.
  * BPMCore does **not** own login, GraphQL setup, TypeORM bootstrap, or
- * Vault loading — those remain the host's responsibility. See
- * `docs/10-bpm-embedding-auth.md` and `docs/11-consumer-quickstart.md` for
- * the full contract.
+ * Vault loading — those remain the host's responsibility. See the
+ * package README sections "Embedding & auth", "Organization data
+ * ownership", and "Consumer quickstart" for the full contract.
  *
  * The host must avoid Nest's `app.setGlobalPrefix(...)`; BPM controllers
  * mount at relative paths driven by their respective options (notably

package/src/lib/identity/member-resolver.interface.d.ts

@@ -21,17 +21,55 @@ export declare const MEMBER_RESOLVER: symbol;
  * BPM never reads the host's user table directly — it only knows
  * `memberId` strings and asks this resolver for any additional information.
  *
- * - `resolve` is called per missing id; throwing here surfaces as a BPM
- *   GraphQL error.
- * - `resolveMany` is the batched form BPM prefers when many ids are needed.
- *   Implementations may de-duplicate / cache as they see fit; missing ids
- *   should be omitted from the result `Map`.
- * - `search` is optional. When omitted, BPM's `searchMembers` GraphQL
- *   query simply returns an empty array.
+ * ## Caching
+ *
+ * BPM caches resolver responses in the `member_metadata_cache` table
+ * with a configurable TTL (`identityOptions.memberMetadataCacheTtlMs`,
+ * default 5 minutes — `IDENTITY_MEMBER_METADATA_CACHE_TTL_MS_DEFAULT`).
+ * Hosts do **not** need to add their own cache layer for the common
+ * case; implementations may layer additional caching if they have a
+ * faster source of truth (e.g. an in-process LRU over a remote auth
+ * service). The two layers do not coordinate — BPM's row-level cache
+ * is invalidated only by TTL expiry, never by host signals.
+ *
+ * ## Unknown-id contract (the two methods diverge intentionally)
+ *
+ * - `resolve(id)` is the **single-id, must-succeed** form. Throw
+ *   `MemberNotFoundException` (or any error) when `memberId` is unknown
+ *   — the caller is asking about one specific member and a partial
+ *   answer is meaningless. BPM surfaces the error as a GraphQL
+ *   `errors[]` entry on the originating query.
+ * - `resolveMany(ids)` is the **batched, partial-success** form BPM
+ *   prefers when many ids are needed (e.g. resolving the assignee list
+ *   on a task page). Implementations should **omit** unknown ids from
+ *   the returned `Map` rather than throwing; BPM treats missing entries
+ *   as deleted/anonymized members and renders a placeholder. Throwing
+ *   here aborts the entire batch and fails the GraphQL query — almost
+ *   never the right choice.
+ * - `search(text)` is optional. When omitted, BPM's `searchMembers`
+ *   GraphQL query returns an empty array (the picker UI degrades to
+ *   id-only entry).
+ *
+ * Implementations may de-duplicate within a single call freely.
  */
 export interface BPMMemberResolver {
+    /**
+     * Single-id lookup. **Throw** (e.g. `MemberNotFoundException`) when
+     * the id is unknown — BPM surfaces the error to the caller. Result is
+     * row-cached by BPM with TTL `identityOptions.memberMetadataCacheTtlMs`.
+     */
     resolve(memberId: string): Promise<MemberMetadata>;
+    /**
+     * Batched lookup. **Omit** unknown ids from the returned `Map`
+     * (do not throw) — BPM renders missing entries as deleted/anonymized
+     * members. Cached per-id under the same TTL as `resolve`.
+     */
     resolveMany(memberIds: readonly string[]): Promise<ReadonlyMap<string, MemberMetadata>>;
+    /**
+     * Optional free-text search. Return up to ~50 best matches; BPM does
+     * not paginate the result. Omit the method entirely to disable
+     * member-picker search.
+     */
     search?(searchText: string): Promise<readonly MemberMetadata[]>;
 }
 /**