Private preview · 0.2.0-preview.1
Versioning and migrations
What changed and which versions apply?
Current version chain
| Package | Version |
|---|---|
| Documentation | 0.2.0-preview.1 |
@answerup/core | 1.0.0-rc.1 |
@answerup/runtime | 0.2.0-preview.1 |
@answerup/actions | 0.2.0-preview.2 |
@answerup/retell | 0.2.0-preview.1 |
Runtime, Actions, and Retell are package-root ESM boundaries requiring Node >=22. The reviewed Core artifact is a package-root CommonJS boundary requiring Node >=20; the chain is not uniform. The portal checks examples against exact content-addressed declaration snapshots. That establishes API/type identity only, not package availability, semantic correctness, deployment readiness, publication, or entitlement.
What the statuses mean
Documentation has its own release identity. Frozen means the contract is authoritative for this review boundary. Candidate or private preview means it remains within controlled review and is not a public availability claim. Planned means there is no available implementation or delivery promise. Unavailable means access or delivery is not provided. Frozen does not mean published, downloadable, generally available, or production-certified; package version strings do not imply publication, downloads, registry access, credentials, or package entitlement.
Current access
There is one selectable current documentation release and no fabricated historical release. Examples and validation are pinned to the chain above. Package access, registry delivery, and downloads remain unavailable.
Migration checklist
Before a future upgrade:
- Pin and record the old chain.
- Compare package-root declarations and import responsibility.
- Review result taxonomy, identity, binding, finality, reconciliation, and projection changes.
- Compile positive and negative TypeScript examples with the required TypeScript settings.
- Rerun conformance and mutation cases.
- Exercise pre-dispatch, post-dispatch,
UNKNOWN, and reconciliation paths. - Review counters, privacy output, metrics, and customer wording.
- 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.
Future Actions-change example
The current Actions baseline maps the relevant post-dispatch PROJECTION_FAILED case to INTEGRATION_FAILURE; the frozen target maps it to UNKNOWN with internal truth preserved and zero redispatch. UNKNOWN means the provider boundary may have been crossed but authoritative evidence cannot currently establish the external effect. INTEGRATION_FAILURE is an integration or projection failure classification: it must not be silently treated as success or as authoritative final absence. A host migrating between these behaviors must update exhaustive result handling, customer wording, metrics, tests, and any permitted verifier-only reconciliation handling. Neither result authorizes automatic blind redispatch; the host must not retry a consequential action merely to convert uncertainty or an integration failure into a convenient terminal result. It must compare the new declarations with the old package-root interfaces and obtain fresh conformance evidence.
Release authority
The portal provides no automatic upgrade or migration command. A future release must document its own migration authority. Detailed adapter and surface availability belongs in Current release status.