AgentsPoppy

Approval

What it takes to get listed

Every submission and every update is reviewed by a human against the rules on this page. Most are checked mechanically; the judgement calls — originality, honesty, quality — are exactly why users trust the catalogue enough to install things into their own cloud. And if these rules aren't for you: you can always distribute your poppy outside the catalogue, sideloaded from disk, forever, with no revenue share to us.

The mechanical checks

RuleWhat it means
Open repositoryYour listing links a public repo containing the poppy's source. No open repo, no listing — it's how packages are verified and how users audit you.
It has a faceA square PNG icon, legible at small sizes, and original — imitating another poppy's mark (or AgentsPoppy's) is grounds for delisting.
The name ends in “Poppy”Your brand + the suffix. Unique in the catalogue; first listed keeps the name.
Verified packagesReleases ship the byte-reproducible zip from pack-extension, pinned by sha256 and verified on every machine before install.
No bundled runtimesYour package ships your code, not a runtime. A compiled-in Node (SEA) or an embedded service binary (Redis, Postgres…) is rejected automatically — you declare what you need and the platform provides it.
An accepted licenseOpen source, from the accepted list — see licensing.
An age ratingA short content questionnaire at submission computes Everyone / 13+ / 18+; the reviewer can adjust it.
A data-flow declarationWhether any data leaves the user's cloud, what, where, and why — see Data & privacy.

The judgement calls

  1. It's original — clones are rejected

    Competing poppies are welcome. Copies are not. You may absolutely build a poppy that competes with an existing one — but it must introduce functionality that genuinely distinguishes it, not re-skin or re-upload someone else's work. We will not host ten poppies that look alike and do exactly the same thing: it clutters the catalogue for users and it punishes the developers who did the original work. Copy-pasting another poppy's code and submitting it — with or without cosmetic changes — is rejected outright, and repeat attempts close the account.

  2. It behaves

    Cloud work survives navigation and can resume. Destroying anything takes a real two-step confirmation. Errors speak plain language. And every button responds — a pending state on click, no dead controls. This is the single most common reason for a “needs changes.”

  3. It's honest about access

    Least-privilege permissions that rate green or amber with “No risks to other resources identified”, and a passing npm run certify — provably leaves no trace.

  4. It's genuine

    A real, working poppy in genuine use — names can't be reserved with placeholder apps. Abandoned placeholders are delisted (with notice) and the name is freed.

The review, practically

  • Who: a human — today, the founder. Curation is the security model.
  • How long: usually within days.
  • Outcome: Live, or Needs changes with a written reason. Fix and resubmit as often as you like.
  • Updates too: every update is re-reviewed; permission changes always re-prompt the user.
  • Enforcement: listings that break the rules are delisted with notice; deception (false declarations, malware, data exfiltration) means immediate removal and a ban.
// the door that's always open

The catalogue is one of two doors. The other — sideloading from disk — needs no approval, no listing, and no license blessing from us. Your users install directly from your repo at their own judgement. The catalogue buys you reach and the trust that comes with review; it never locks you in.

← Monetisation Licensing →