@kortexya/reasoninglayer 0.22.0 → 0.22.1

package/dist/index.d.cts

@@ -109,7 +109,7 @@ type JsonValue$1 = string | number | boolean | null | JsonValue$1[] | object;
  * This is the single source of truth for the version constant.
  * The `scripts/release.sh` script updates this value alongside `package.json`.
  */
-declare const SDK_VERSION = "0.22.0";
+declare const SDK_VERSION = "0.22.1";
 /**
  * Configuration for the Reasoning Layer client.
  *
@@ -3469,14 +3469,38 @@ type CreateScenarioResponse$1 = {
 /**
  * Request body for `POST /api/v1/scheduling/problems`.
  *
- * Same inline shape as [`SchedulingOptimizeRequest`].  The endpoint
- * freezes the inputs into a `scheduling.problem` Ψ-term snapshot
- * stored in the application-layer scheduling store and returns the
- * snapshot's `problem_id`.  Re-solving reads only the snapshot,
- * matching the user's "snapshot mode" decision.
+ * Two mutually exclusive ways to identify the problem's agents:
+ *
+ *   * **Inline** — set `agents` to a list of [`AgentInput`]s.
+ *     The problem term embeds frozen copies of the agent specs.
+ *     Convenient for ad-hoc demos but doesn't compose with other
+ *     KB-stored entities.
+ *
+ *   * **Reference** — set `agent_ids` to a list of `TermId`
+ *     UUIDs pointing at agent Ψ-terms (sort `nurse` or any
+ *     tenant-defined agent sort) created via the regular
+ *     `POST /api/v1/terms` endpoint.  The problem term carries
+ *     refs only; re-solving fetches the agent terms from the KB
+ *     at solve time, so updating an agent (e.g. adding a
+ *     certification, adding a personal_constraint sub-term)
+ *     immediately affects the next solve.  This is the
+ *     OSF/LIFE-native flow and what multi-user collaboration
+ *     uses.
+ *
+ * Exactly one of `agents` / `agent_ids` must be supplied;
+ * supplying both, or neither, returns HTTP 400.
  */
 interface CreateSchedulingProblemRequest$1 {
-    agents: AgentInput[];
+    /**
+     * References to agent Ψ-terms in the KB (UUID strings).
+     * Optional; mutually exclusive with `agents`.
+     */
+    agent_ids?: any[] | null;
+    /**
+     * Inline agent specs (legacy / demo-friendly path).  Optional;
+     * see `agent_ids` for the reference-based alternative.
+     */
+    agents?: any[] | null;
     /** @min 0 */
     days: number;
     demands: ShiftDemandInput[];
@@ -39879,22 +39903,44 @@ interface SchedulingOptimizeResponse {
  * Input to {@link SchedulingClient.createProblem}.
  *
  * @remarks
- * Same inline shape as {@link SchedulingOptimizeRequest}.  The
- * server freezes the inputs into a `scheduling.problem` Ψ-term
- * snapshot, stores it under the caller's tenant, and returns the
- * snapshot's `problemId`.  Subsequent re-solves
- * ({@link SchedulingClient.solveProblem}) read only the snapshot —
- * mutations to the source data after creation do not affect the
- * stored problem, keeping every solve reproducible and auditable.
+ * Two mutually-exclusive ways to identify the problem's agents:
+ *
+ *   - **Inline** — set `agents` to a list of {@link AgentSpec}s.
+ *     The server embeds frozen agent-spec copies on the problem
+ *     term.  Convenient for ad-hoc demos.
+ *
+ *   - **Reference** — set `agentIds` to a list of `TermId` UUIDs
+ *     pointing at agent Ψ-terms (sort `nurse` or any other
+ *     tenant-defined sort) created via the regular
+ *     `POST /api/v1/terms` endpoint.  The problem term carries
+ *     refs only; re-solving fetches the agent terms from the KB
+ *     at solve time, so mutating an agent (adding a
+ *     `personal_constraints` sub-term, for instance) immediately
+ *     affects the next solve.  This is the OSF/LIFE-native flow
+ *     and what multi-user collaboration uses.
+ *
+ * **Exactly one** of `agents` / `agentIds` must be supplied.
+ * Sending both — or neither — returns HTTP 400.
+ *
+ * `pins` / `preferences` on the create payload are only honoured
+ * for the inline path.  In the reference path, create the problem
+ * first and add pins / preferences via the mutation endpoints
+ * (where `agentId` is then a TermId UUID).
  */
 interface CreateSchedulingProblemRequest {
-    agents: AgentSpec[];
+    /** Inline agent specs.  Mutually exclusive with `agentIds`. */
+    agents?: AgentSpec[];
+    /**
+     * References to agent Ψ-terms in the KB (UUID strings).
+     * Mutually exclusive with `agents`.
+     */
+    agentIds?: string[];
     days: number;
     shiftsPerDay: number;
     demands: ShiftDemand[];
-    /** Pre-assigned `(agent, day, shift)` triples.  Defaults to empty. */
+    /** Pre-assigned `(agent, day, shift)` triples.  Inline path only. */
     pins?: Pin[];
-    /** Soft preferences applied to the optimum's objective.  Defaults to empty. */
+    /** Soft preferences applied to the optimum's objective.  Inline path only. */
     preferences?: Preference[];
 }
 /**

package/dist/index.d.ts

@@ -109,7 +109,7 @@ type JsonValue$1 = string | number | boolean | null | JsonValue$1[] | object;
  * This is the single source of truth for the version constant.
  * The `scripts/release.sh` script updates this value alongside `package.json`.
  */
-declare const SDK_VERSION = "0.22.0";
+declare const SDK_VERSION = "0.22.1";
 /**
  * Configuration for the Reasoning Layer client.
  *
@@ -3469,14 +3469,38 @@ type CreateScenarioResponse$1 = {
 /**
  * Request body for `POST /api/v1/scheduling/problems`.
  *
- * Same inline shape as [`SchedulingOptimizeRequest`].  The endpoint
- * freezes the inputs into a `scheduling.problem` Ψ-term snapshot
- * stored in the application-layer scheduling store and returns the
- * snapshot's `problem_id`.  Re-solving reads only the snapshot,
- * matching the user's "snapshot mode" decision.
+ * Two mutually exclusive ways to identify the problem's agents:
+ *
+ *   * **Inline** — set `agents` to a list of [`AgentInput`]s.
+ *     The problem term embeds frozen copies of the agent specs.
+ *     Convenient for ad-hoc demos but doesn't compose with other
+ *     KB-stored entities.
+ *
+ *   * **Reference** — set `agent_ids` to a list of `TermId`
+ *     UUIDs pointing at agent Ψ-terms (sort `nurse` or any
+ *     tenant-defined agent sort) created via the regular
+ *     `POST /api/v1/terms` endpoint.  The problem term carries
+ *     refs only; re-solving fetches the agent terms from the KB
+ *     at solve time, so updating an agent (e.g. adding a
+ *     certification, adding a personal_constraint sub-term)
+ *     immediately affects the next solve.  This is the
+ *     OSF/LIFE-native flow and what multi-user collaboration
+ *     uses.
+ *
+ * Exactly one of `agents` / `agent_ids` must be supplied;
+ * supplying both, or neither, returns HTTP 400.
  */
 interface CreateSchedulingProblemRequest$1 {
-    agents: AgentInput[];
+    /**
+     * References to agent Ψ-terms in the KB (UUID strings).
+     * Optional; mutually exclusive with `agents`.
+     */
+    agent_ids?: any[] | null;
+    /**
+     * Inline agent specs (legacy / demo-friendly path).  Optional;
+     * see `agent_ids` for the reference-based alternative.
+     */
+    agents?: any[] | null;
     /** @min 0 */
     days: number;
     demands: ShiftDemandInput[];
@@ -39879,22 +39903,44 @@ interface SchedulingOptimizeResponse {
  * Input to {@link SchedulingClient.createProblem}.
  *
  * @remarks
- * Same inline shape as {@link SchedulingOptimizeRequest}.  The
- * server freezes the inputs into a `scheduling.problem` Ψ-term
- * snapshot, stores it under the caller's tenant, and returns the
- * snapshot's `problemId`.  Subsequent re-solves
- * ({@link SchedulingClient.solveProblem}) read only the snapshot —
- * mutations to the source data after creation do not affect the
- * stored problem, keeping every solve reproducible and auditable.
+ * Two mutually-exclusive ways to identify the problem's agents:
+ *
+ *   - **Inline** — set `agents` to a list of {@link AgentSpec}s.
+ *     The server embeds frozen agent-spec copies on the problem
+ *     term.  Convenient for ad-hoc demos.
+ *
+ *   - **Reference** — set `agentIds` to a list of `TermId` UUIDs
+ *     pointing at agent Ψ-terms (sort `nurse` or any other
+ *     tenant-defined sort) created via the regular
+ *     `POST /api/v1/terms` endpoint.  The problem term carries
+ *     refs only; re-solving fetches the agent terms from the KB
+ *     at solve time, so mutating an agent (adding a
+ *     `personal_constraints` sub-term, for instance) immediately
+ *     affects the next solve.  This is the OSF/LIFE-native flow
+ *     and what multi-user collaboration uses.
+ *
+ * **Exactly one** of `agents` / `agentIds` must be supplied.
+ * Sending both — or neither — returns HTTP 400.
+ *
+ * `pins` / `preferences` on the create payload are only honoured
+ * for the inline path.  In the reference path, create the problem
+ * first and add pins / preferences via the mutation endpoints
+ * (where `agentId` is then a TermId UUID).
  */
 interface CreateSchedulingProblemRequest {
-    agents: AgentSpec[];
+    /** Inline agent specs.  Mutually exclusive with `agentIds`. */
+    agents?: AgentSpec[];
+    /**
+     * References to agent Ψ-terms in the KB (UUID strings).
+     * Mutually exclusive with `agents`.
+     */
+    agentIds?: string[];
     days: number;
     shiftsPerDay: number;
     demands: ShiftDemand[];
-    /** Pre-assigned `(agent, day, shift)` triples.  Defaults to empty. */
+    /** Pre-assigned `(agent, day, shift)` triples.  Inline path only. */
     pins?: Pin[];
-    /** Soft preferences applied to the optimum's objective.  Defaults to empty. */
+    /** Soft preferences applied to the optimum's objective.  Inline path only. */
     preferences?: Preference[];
 }
 /**

package/dist/index.js

@@ -5,7 +5,7 @@ var __export = (target, all) => {
 };
 
 // src/config.ts
-var SDK_VERSION = "0.22.0";
+var SDK_VERSION = "0.22.1";
 function resolveConfig(config) {
   if (!config.baseUrl) {
     throw new Error("ClientConfig.baseUrl is required");
@@ -20696,12 +20696,29 @@ function SchedulingOptimizeResponseFromApiToFront(dto) {
   };
 }
 function CreateSchedulingProblemRequestFromFrontToApi(request) {
+  const hasInline = request.agents !== void 0;
+  const hasRefs = request.agentIds !== void 0;
+  if (hasInline && hasRefs) {
+    throw new Error(
+      "CreateSchedulingProblemRequest: supply exactly one of `agents` (inline) or `agentIds` (TermId refs), not both"
+    );
+  }
+  if (!hasInline && !hasRefs) {
+    throw new Error(
+      "CreateSchedulingProblemRequest: must supply either `agents` (inline) or `agentIds` (TermId refs)"
+    );
+  }
   const dto = {
-    agents: request.agents.map(AgentSpecFromFrontToApi),
     days: request.days,
     shifts_per_day: request.shiftsPerDay,
     demands: request.demands.map(ShiftDemandFromFrontToApi)
   };
+  if (request.agents !== void 0) {
+    dto.agents = request.agents.map(AgentSpecFromFrontToApi);
+  }
+  if (request.agentIds !== void 0) {
+    dto.agent_ids = request.agentIds;
+  }
   if (request.pins !== void 0) {
     dto.pins = request.pins.map(PinFromFrontToApi);
   }