How the play travels

Where you are in the journey: you have made and released a play. Now you need to move it beyond the machine where it was born—without losing its identity, requirements, history, or access rules.

A play travels as two things at once:

1. a verified package containing the executable method and its presentation; and
2. a canonical identity that tells people and harnesses what that package is, what it needs, and whether they may have it.

That identity is the Play URI:

01https://play.modiqo.ai/<owner>/<name>@<version>

The URI is the durable handoff. It can be pasted into a browser, a chat, a runbook, or any agent harness. Every recipient starts from the same identity instead of an unexplained file.

The journey in one line

01CRYSTALLIZE → RELEASE → PUSH → LIST / SEARCH → INSPECT → PULL + CONVERGE → RUN02local trace      version     hub       discovery      card       this machine      fresh inputs

The registry hub is not just storage in the middle of that line. It resolves ownership and visibility, preserves immutable versions, links Plays to their adapter releases, and returns the metadata needed to prepare another machine safely.

Push: publish one reviewed version

Push begins with a dry run:

rote registry play push ~/.rote/flows/my-play/main.ts my-org --dry-run

The preflight classifies the package, checks size limits, validates run eligibility, predicts version conflicts, and verifies dependency reachability without writing anything. Then publish the same artifact:

rote registry play push ~/.rote/flows/my-play/main.ts my-org

Add --private when the Play is for the owner or organization rather than the public registry.

Adapters travel first

A Play may reach APIs through adapters. The Play package declares those requirements through adapter sources, contract fingerprints, and the operations it uses. A push refuses a Play whose adapter steps are undeclared, because an undeclared dependency would leave the next machine unable to prepare itself.

For an organization namespace, publish required adapters before the Play:

01rote registry adapter publish github my-org --dry-run02rote registry adapter publish github my-org03rote registry play push ~/.rote/flows/my-play/main.ts my-org --dry-run04rote registry play push ~/.rote/flows/my-play/main.ts my-org

The adapter artifact carries the API contract and setup description. Credentials do not travel. Tokens, browser sessions, local paths, and organization secrets stay on the recipient's machine and are requested only when that machine prepares to run.

List and search: the hub makes it discoverable

The local inventory and registry inventory answer different questions:

01rote play list                              # what is installed here?02rote registry play list --mine              # what do I own or belong to?03rote registry play list --org my-org        # what can my organization see?04rote registry play list --owner alice       # what is visible under this owner?05rote registry play search "release health"  # which remote Play matches this intent?

Registry results preserve the owner namespace and version. That is why two Plays with the same short name can coexist without ambiguity, and why a pinned URI always names one immutable release.

The identity card: what unfolds from the URI

Opening a canonical Play URI is a read-only act. It returns a transparency card that a person can read and a harness can process. The card answers the questions that matter before execution:

Inspect the same card from the terminal:

rote play inspect https://play.modiqo.ai/my-org/my-play@1.2.0

The card is the Play's self-issued identity document: it carries enough declared truth for a harness to explain the Play, evaluate access, and plan setup before anything changes locally.

Pull: converge the receiving machine

rote registry play pull my-org/my-play --yes

By default, pull is a convergence operation—not a blind file download:

1. Resolve the visible owner, release, and exact version.
2. Download within limits and verify the archive against its expected content hash and size.
3. Install transactionally so an interrupted pull cannot leave a half-installed Play.
4. Read the declared requirements from the registry manifest and installed frontmatter.
5. Reuse, install, or repair adapters by source and contract fingerprint.
6. Prepare local bindings and credentials without copying anyone else's secrets.
7. Assess run readiness and name any blocker before execution.

Use --no-deps only when you deliberately want the Play package without converging its adapters.

A new machine: self-describing, then consented setup

A Play URI can arrive on a machine that has never seen rote. The URI still does not silently execute an installer.

Its read-only card advertises a separate bootstrap URI. Following that transition is an explicit preparation decision: with consent, it installs rote when absent, resolves the pinned Play, verifies the package, and converges the declared requirements. Merely opening the Play URI changes nothing.

Think of the two surfaces this way:

01PLAY URI        = identity + disclosure      (safe to open)02BOOTSTRAP URI   = consented preparation      (installs what is missing)03rote play run   = execution with fresh input (runs the verified method)

This separation lets a URI be freely shared while keeping installation and execution as visible, reviewable transitions.

Ownership and privacy

Every Play belongs to an owner namespace. The owner may be:

• an individual identity, for work owned personally; or
• an organization, for methods held by a team or company.

Ownership and authorship are deliberately separate. An organization can own and publish a Play while its provenance still credits the human or agent who created the successful method.

Visibility controls future registry access:

• Public — discoverable through the public registry and resolvable by permitted recipients.
• Private — visible only through authorized access to its owner namespace.

An organization owner or admin can invite members so the organization's private Plays become a shared internal library:

01rote registry org invite my-org [email protected] --role developer02rote registry org members my-org

Visibility can change without republishing:

01rote registry play visibility my-org/my-play private02rote registry play visibility my-org/my-play public

Changing a Play to private controls future registry resolution; it cannot recall copies that were already pulled.

Provenance and lineage: where it came from, what changed

Three identities work together:

Provenance adds the origin story: author identity and the recorded workspace from which the Play was crystallized. Version lineage adds the evolution story: 1.2.0 remains immutable; a change becomes 1.2.1, 1.3.0, or 2.0.0.

A versionless URI floats to the newest released version. Once resolved for execution, the runner works from a specific version. Pin the URI anywhere repeatability matters:

01https://play.modiqo.ai/my-org/my-play        # follow the latest release02https://play.modiqo.ai/my-org/my-play@1.2.0  # keep this exact release

What actually travels

The result is portable without being careless: the method travels, its requirements are explicit, its history remains attached, and every new machine supplies its own authority.

The Play has now left its birthplace without becoming a mystery archive. Its URI explains it, the registry governs who can resolve it, and pull reconstructs the environment it declared—one verified dependency at a time.

Next: 5 · What Plays make possible →