Upload, Install & Publish

Uploading is not installing, and installing is not publishing. Each step has its own gate.

1. 1Pack the project and note the content hash (arvexa plugin pack).
2. 2Upload the archive to a developer app (arvexa plugin upload --app-id <id>).
3. 3Register a plugin-manifest-1.0 against the uploaded package (--register-manifest).
4. 4Run a security scan of those exact bytes; a PASS is required to install.
5. 5Install into an organization, which binds the declared hooks and extension points.
6. 6Exercise it with arvexa sandbox run, starting in DRY_RUN.
7. 7Request a harness attempt (arvexa plugin test --package-id <id>); a PASS is required to publish.
8. 8Publish to the plugin marketplace, which requires a PASSED scan *and* a PASSED test report for the same exact bytes.

Upload. The bytes are validated locally before anything is sent, so you never hold an archive the host will reject. An upload is never retried, including on timeout: the host makes uploads idempotent by content hash, but a timed-out client cannot tell an accepted upload from a rejected one, and re-sending on that guess is worse than reporting the error. If the host records a different content hash than your local one, the CLI warns — the two sides are not describing the same archive, and no scan or test evidence for the host's copy says anything about yours.

Install gate. Install requires an exact-package scan Pass. Evidence is re-verified before invocation, not only at install time, so a scan that has gone stale stops execution rather than lingering as a one-time check. If the manifest's content hash no longer matches its linked package, the gate denies with SECURITY_SCAN_STALE.

Publish gate. Marketplace publish requires a PASSED scan and a PASSED test report, evaluated independently, for the same exact bytes. A PASSED test report never substitutes for a scan, and a PASSED scan never substitutes for tests.

The plugin marketplace is not Marketplace OS. They are distinct surfaces with distinct listings and distinct gates; a plugin listing is not a traffic marketplace listing.

Interim endpoint availability. The public /api/developer/* REST surface is a later phase. On a host build that does not serve it yet, the API-backed CLI commands fail closed with ENDPOINT_UNAVAILABLE (exit 6) and an explanation naming the phase, rather than degrading into a confusing 404 or a false success. The offline commands — plugin validate, plugin pack, plugin test --preflight-only — are complete today, and they are what you need first: nothing about uploading helps until the package validates.