Delivery, consent and installation

First eligible interaction

1. Discover the manifest. Availability means the server can identify the release; it does not mean the complete instructions were delivered.
2. Offer Install, Review or Not now when the client supports elicitation. Review and Not now must continue to permit unrelated authorized work.
3. Retrieve either the complete content or all chunks in order. A single chunk is incomplete. Verify the reconstructed UTF-8 byte size and SHA-256 digest against the manifest.
4. Only after explicit approval may the client use its own supported installation mechanism. Prefer a user-level installation when the host officially supports one; follow that host's current documentation rather than inventing a path.
5. Report installation or verification separately. The server never writes the client's filesystem.

Consent and acknowledgement states

install_requested, review_requested, not_now, declined, cancelled, client-reported installed and client-reported verified are distinct. Suppressing a repeated offer is not installation authority.

Legacy offers are deduplicated in memory for the current connection and release. A client may supply an opaque x-openepm-client-installation-context to keep two installations distinct without machine fingerprinting. A stateless client can acknowledge the exact release with x-openepm-skill-version, x-openepm-skill-digest and x-openepm-skill-state. Generic new stateless connections that supply no installation identity cannot be universally deduplicated.

Hosts without prompts or native skills

Use the resources or read_openepm_published_skill fallback to review the manifest and content manually. If the host has no supported native installation, keep the verified instructions in the host's supported user-level context or use them for the current session. Do not claim a persistent installation. Installation alone never activates hooks, schedules, packages, permissions or business operations.