Private preview · 0.2.0-preview.1

Package and SDK boundaries

How should package-root integrations be understood?

The supported import boundary is the package root. Runtime, Actions, and Retell use ESM with Node >=22. The reviewed Core artifact is CommonJS with Node >=20; package access is not yet available. The application is the software using AnswerUp; the host is the trusted runtime/backend environment operating the integration; the integration owner supplies and governs that integration.

import { createProtectedActionRuntime } from '@answerup/actions';
const runtime = createProtectedActionRuntime();

Do not use deep imports, workspace paths, or guessed exports. Do not apply the ESM-only restriction to Core: its reviewed artifact declares CommonJS. The portal validates package-root imports against exact content-addressed declaration snapshots.

Example: a package-root boundary

An integrator may create a protected-action runtime from the package root and provide its own bounded provider, verifier, policy, and trusted-context dependencies. The runtime object is not a provider connection, and this excerpt does not execute the lumber reservation. Keep credentials outside result objects and follow the frozen declarations when package access is separately approved.

Package-root contract

The supported public boundary is the package root: @answerup/core, @answerup/runtime, @answerup/actions, and @answerup/retell. Deep imports, workspace paths, guessed exports, and copied declaration files are not substitutes for that contract. The exact declaration snapshots prove API/type identity only; they do not prove package availability, semantic correctness, deployment readiness, publication, or entitlement.

What the host still supplies

Creating a Runtime or Actions object does not supply a provider, verifier, policy authority, credentials, durable action record, or HTTP transport. Durable-store interfaces in Actions describe a host-supplied persistence contract; they do not provide hosted durable storage or prove restart-safe reconciliation. The host must register or provide those boundaries according to the package contract, enforce its own input and privacy limits, and decide how results become application behavior. A package API can classify a result; it cannot know whether a host’s inventory system is authoritative unless the host connects the correct independent verifier/read-back.

Version and availability boundary

The frozen chain is @answerup/core@1.0.0-rc.1, @answerup/runtime@0.2.0-preview.1, @answerup/actions@0.2.0-preview.2, and @answerup/retell@0.2.0-preview.1. Package access is not available from this portal. HTTP, MCP, and OpenAI/tool adapters remain planned and under separate implementation. This page therefore explains API boundaries and type relationships; it is not an installation guide.

Example: adapter preparation

An integrator creates the Actions runtime, supplies a trusted-context resolver, and prepares a refund operation with a separate provider and ledger verifier. The package-root import can be type-checked against frozen declarations, but nothing in the excerpt sends a refund. If the host passes a malformed context or a verifier that returns an unsupported shape, it must fail closed rather than cast the value into a success result.

Do not infer

An import does not mean the package is downloadable. A type declaration does not mean an adapter is certified. A Runtime handle does not survive process loss. A successful preparation does not prove dispatch, and a provider response does not prove effect truth. These limitations are part of the reference, not incidental setup details.