The short answer

AgentPlat preview packages are coordinated, while registry tags can move and source checkouts can differ from published artifacts. Verify the exact packages you need, record their resolved versions and evaluate the chosen installation path rather than assuming tag names prove compatibility.

Choose the installation path before following examples

A repository example and a downstream app installed from a registry are different environments. The maturity matrix explicitly separates checkout capabilities from observed distribution.

For an illustrative pilot, record whether the team is evaluating a source commit or a set of published packages. A successful source example should not be reported as proof that the same integration was assembled from registry artifacts.

Treat distribution tags as references, not immutable versions

The release-channel guide describes coordinated preview distribution and the intended roles of next and latest. It also documents a first-publication caveat for new packages.

Resolve tags when selecting the release and record the resulting exact versions. Avoid embedding a mutable tag in an evidence claim as if it permanently identified the package set used by the test.

Check every required package and integration surface

The package catalog maps packages to responsibilities, but your application also depends on the exact exports and adapter combinations it imports.

Verify the selected registry packages and version-specific README for those surfaces. If distribution of one required adapter is unverified, retain that status instead of assuming a similarly named package supplies an equivalent integration.

Keep coordinated Room packages aligned

The Room migration guidance requires a coordinated package version and schema-aware worker rollout. Package selection therefore affects deployment state as well as TypeScript compilation.

For a planned upgrade, inspect migration requirements before starting the new workers. A lockfile that resolves successfully does not establish that persisted projections or older workers are compatible with the selected operational runtime.

Retain a small installation evidence record

  • Source commit or exact registry package versions.
  • Package-manager version and lockfile.
  • Required exports and adapter composition.
  • Migration revision where persistence is involved.
  • The example or consumer check actually executed.

Do not substitute historical release notes for fresh verification of the chosen set. The result should say what was installed and tested, and which remaining integration or operational questions are still outside that observation.

This article explains version selection. It does not announce a current registry release or certify that every documented optional package is available through a particular registry.

Sources and further reading

Documentation reviewed . Consult the linked documentation for current implementation details.