bjs inject is step 1 of 3 in the member publishing flow. By itself it submits your component for curator review. The product page — the thing buyers see, the thing that takes payment — comes from steps 2 and 3.

The three steps

1. bjs inject — submit your component from src/components/<Name>/ to BabylonJS Market for curator review. The CLI side of Members Only. You're using it today.
2. Curator review — server-side, no member action required. Your submission lands in the member_submissions queue. A curator validates the diff, runs the library's tests against it, and merges it into the arcade (or viz) library when it's clean.
3. New-product wizard — a marketplace-side flow that creates the product page: category, price tier, description, dependency graph, Stripe sync. (coming soon)

Today, members run step 1 from any project without a local library checkout. Step 2 is the operator's job and happens out of sight. Once step 3 lands, members will tie their merged component to a marketplace product page from the browser.

Step 1: bjs inject — what you already know

You ran bjs inject Foo. The CLI computed the diff against the right library namespace in a tmpdir, packaged it as a submission, and shipped it to the marketplace API. You got back a submission ID. Your project is untouched; nothing wrote to disk locally.

What's still missing:

• The submission is in the queue but hasn't been merged into the library's working tree yet.
• The marketplace doesn't have a product page for your component. There's no listing, no payment hook.
• Downstream consumers can't install your version yet.

Steps 2 and 3 close that gap.

Step 2: Curator review

bjs inject IS the publisher. There's no separate publisher route, no upload form, no PR button — the CLI already does the submission. From your side, step 2 is invisible.

On the server side:

• The submission row sits in the member_submissions table with status: 'pending'.
• A curator (the operator, in v1) walks the queue. For each submission they review the file list, the patches, and the closure.
• The curator runs the diff against a local checkout of the arcade or viz library, runs its tests, and either merges (status: 'merged') or rejects with notes (status: 'rejected').
• A merged submission flows into the next library release. Once that ships, downstream consumers can arcade eject your component.

There's no operator UI in v1 — the curator works straight from the database. You can track your submission's status at babylonjsmarket.com/account/submissions/<id> (the URL the CLI prints on success); it's a forward-link that will populate as the reviewer UI ships.

Step 3: New-product wizard (coming soon)

A future route — likely /publish/new-product or the CLI command bjs product new <slug> — turns an already-merged component into a marketplace product. The flow:

• Pick the component (the one you submitted in step 1 and that a curator merged in step 2).
• Pick a category (gameplay, physics, viz, UI, …).
• Pick a price tier (free, paid, member-only).
• Fill in the description, the dependency graph, the screenshots/video.
• The wizard scaffolds the product row in the marketplace database, creates the Stripe product+price entries, and stubs the product page.
• The operator reviews the page and flips published: true.

A shared core package — likely @babylonjsmarket/product-scaffold — will sit underneath both surfaces (the CLI and the web wizard), so the same scaffold logic runs whether a member uses the browser or the terminal.

What bjs inject does commit to today

Even before step 3 exists, the contract of step 1 is fixed:

• The submission is recorded with your user ID and a full file map.
• The diff lines up with the right library's working tree shape (per-component for arcade, per-layer for viz).
• Registry/barrel patches are described in the submission so the curator's merge is mechanical.
• Imports are rewritten symmetrically to how arcade eject rewrites them on the way out.
• Tests come along intact.

Everything downstream of that — the curator's merge, the version bump, the npm publish, the product page — uses these properties. They're not going to change as the wizard gets built out.

Why the staged rollout

The CLI lands first because it's the smallest piece with the clearest contract. It's testable, it's reviewable, and it gives the operator a queue to drain without forcing every part of the pipeline to be built up-front.

Curator review is a human process for now. It's small in code (a Prisma model + an endpoint), but the policy — what to accept, what to reject, what to send back with notes — is the kind of thing that needs to be lived in before it's automated.

The new-product wizard is harder still — it touches Stripe, the marketplace database, the product page rendering, and the operator review workflow. The clean separation between "ship code to the pro package" (steps 1 and 2) and "ship a product to buyers" (step 3) is what makes both halves tractable on their own.

What's next

The next section, round-trip with eject, describes the contract you sign by publishing: downstream consumers can pull your component back out with arcade eject, and your imports rewrite symmetrically.