@namzu/sdk 3.2.0 → 4.0.0

package/src/types/agent/task.ts

@@ -1,6 +1,7 @@
 import type { ActorRef } from '../../types/session/actor.js'
 import type { WorkspaceBackendKind } from '../../types/workspace/ref.js'
 import type { TokenUsage } from '../common/index.js'
+import type { ResumeHandler } from '../hitl/index.js'
 import type { RunId, SessionId, TaskId, TenantId } from '../ids/index.js'
 import type { Message } from '../message/index.js'
 import type { RunEventListener } from '../run/events.js'
@@ -41,6 +42,23 @@ export interface AgentTaskContext {
 
 	factoryOptions?: AgentFactoryOptions
 
+	/**
+	 * The parent's channel to whoever can answer a decision it cannot make
+	 * alone, handed down so a child asks the same person.
+	 *
+	 * Passed as the function itself, which works because delegation is
+	 * in-process: `LocalTaskGateway` is the only `TaskGateway` in the tree.
+	 * A gateway that dispatched across a process boundary could not carry a
+	 * closure and would have to proxy the request onto the parent's event
+	 * stream and route the answer back by request id — the upward half of
+	 * which already exists, since `wrapChildListener` stamps lineage on
+	 * every child event the parent sees.
+	 *
+	 * Absent means the child auto-approves, exactly as every child did
+	 * before this existed.
+	 */
+	resumeHandler?: ResumeHandler
+
 	/** Isolation boundary. Required per session-hierarchy.md §12.1. */
 	tenantId: TenantId
 

package/src/types/sandbox/index.ts

@@ -110,6 +110,16 @@ export interface SandboxExecOptions {
 	 * Without it a Stop (or a per-tool deadline) could only ever abandon
 	 * the *wait* — the sandboxed process kept running after the host
 	 * believed the run had been cancelled.
+	 *
+	 * **Who honours it.** The in-process local sandbox does: the signal is
+	 * merged with the call's own deadline and reaches `spawn`, so the child
+	 * dies. The remote backends do not, and deliberately: their wire has no
+	 * cancel op, so aborting the request would abandon the wait and leave the
+	 * command running — the failure above, wearing the appearance of a fix.
+	 * They will honour it when their protocols carry a cancel.
+	 *
+	 * Passing it is therefore always safe and never harmful; whether it takes
+	 * effect depends on the backend.
 	 */
 	readonly signal?: AbortSignal
 }

package/src/types/toolset/index.ts

@@ -1,23 +1,5 @@
 import type { LLMToolSchema, ToolDefinition, ToolPermission } from '../tool/index.js'
 
-/**
- * @deprecated Slated for removal in the next major. Nothing produces or
- * reads it — no code constructs any member, and `ToolsetPolicy.surfaces`,
- * the only field that carries it, is never consulted.
- *
- * It is also the wrong axis. Which tools a run may use is already
- * expressible four ways, all of them per-run and dynamic where this is
- * fixed at definition: `allowedTools` on the query, `ToolAvailability`
- * (`active` / `deferred` / `suspended`) with mid-run activation,
- * `runtimeToolOverrides`, and capability negotiation stripping tools a
- * driver cannot carry. Prefer `allowedTools`.
- *
- * The member names encode deployment shapes this kernel does not own,
- * which is the deeper reason not to keep them: a host's surfaces are the
- * host's to name.
- */
-export type ToolCatalogSurface = 'chat' | 'supervised' | 'managed-agent' | 'worker' | 'code'
-
 export type ToolSourceKind =
 	| 'host_tool'
 	| 'provider_builtin'
@@ -57,13 +39,6 @@ export interface ToolsetPolicy {
 	readonly enabled?: boolean
 	readonly loading?: ToolLoadingMode
 	readonly preferred?: boolean
-	/**
-	 * @deprecated Slated for removal in the next major. Never read by
-	 * anything — setting it has no effect today. Use `allowedTools` on the
-	 * query to bound which tools a run may use; it says the same thing per
-	 * run instead of per definition. See {@link ToolCatalogSurface}.
-	 */
-	readonly surfaces?: readonly ToolCatalogSurface[]
 	readonly providerConfig?: Record<string, unknown>
 }