Skip directly to article

Current guidance · concepts baseline 0.2.0-preview.1

Versioning and migrations

What changed and which versions apply?

PREVIEW ACCESS

Use the selected preview versions for this example. Find your packages, or try the package-free Lumber guided tour.

Current package set: Core rc.1, Runtime preview.5 and Actions preview.8. Try HTTP reference preview.4 or Retell adapter preview.3 with equipment example preview.4.

Version history and scope

Retell preview.1 declarations describe the older Runtime preview.1 / Actions preview.2 line. Retell preview.2 uses a mock facade; HTTP preview.1 simulates bookkeeping. The older private HTTP source uses Runtime preview.3 / Actions preview.4. These are separate from the current runnable examples.

Examples use local test systems. They do not validate live providers, arbitrary crashes or distributed durability. Approved participants can use protected downloads.

Current selected private distribution

Documentation concepts in this release use the 0.2.0-preview.1 baseline. That documentation version is not a package version. The selected seven-archive private-preview distribution is portal-distribution-20261017-http-preview4-trace-preview7:

ArchiveSelected version
@answerup/core1.0.0-rc.1
@answerup/runtime0.2.0-preview.5
@answerup/actions0.2.0-preview.8
@answerup/retell0.2.0-preview.3
Retell equipment example0.2.0-preview.4
@answerup/generic-http-reference0.2.0-preview.4
@answerup/trace-local0.1.0-preview.7

The distribution's authoritative seven-archive MANIFEST.sha256 has SHA-256 bcf9b7864818c0e851de9c051d9548f8bf0a0b01a4c310fed68b862f91e6d1ff. The complete ZIP and individual archives contain these selected private-preview releases. Manual checksum verification is optional; a mismatch means the file should be downloaded again before use. Protected Portal downloads are enabled for participants who pass the existing identity, invitation, agreement and active entitlement checks. The archives are not publicly available through unrestricted downloads or a registry. Authentication alone does not grant package access. See Packages and access and Current release status.

Runtime, Actions and the selected Retell adapter use package-root ESM boundaries requiring Node >=22. The reviewed Core artifact is a package-root CommonJS boundary requiring Node >=20; the selected combined examples use Node 22+. The Portal's declaration-backed examples establish API/type identity, not package availability, semantic correctness or production readiness.

Historical compatibility references

The versioned Retell API declaration page describes adapter 0.2.0-preview.1 with an older Runtime preview.1 / Actions preview.2 line. It is a historical reference, not the selected Retell preview.3 adapter. The older private Generic HTTP source used Runtime preview.3 / Actions preview.4; it is separate from the selected executable HTTP preview.4 archive. Earlier versions remain available as historical documentation only where explicitly identified.

Migration checklist

Before a future upgrade:

  1. Pin and record the old chain.
  2. Compare package-root declarations and import responsibility.
  3. Review result taxonomy, identity, binding, finality, reconciliation and projection changes.
  4. Compile positive and negative TypeScript examples with the required settings.
  5. Rerun focused conformance and mutation cases relevant to the changed contracts.
  6. Exercise pre-dispatch, post-dispatch, UNKNOWN and reconciliation paths.
  7. Review counters, privacy output, metrics and customer wording.
  8. Obtain owner approval before rollout.

Successful compilation alone does not prove behavioral compatibility. The host owns adapter composition, provider and verifier contracts, privacy projections, customer wording and explicit migration approval. Do not silently upgrade.

Accepted projection change

Actions preview.8 maps the relevant post-dispatch PROJECTION_FAILED case to UNKNOWN with internal truth preserved and zero redispatch. This closes the former baseline mismatch with the accepted target. A host migrating from older behavior must update exhaustive result handling, customer wording, metrics, tests and verifier-only reconciliation handling. The change does not authorize blind redispatch, establish exactly-once effects or certify a deployment.

The Portal provides no automatic upgrade or migration command. A future release must document its own migration authority.