Studio launch testing

Five profiles to prove Studio before launch.

Use separate Chrome profiles for each role. The goal is to test the journeys visitors will actually take: browse, subscribe, return, publish, and open an individualized invite.

Profile 1

Public visitor

Fresh Chrome profile, not signed in

See the what/why, public artifact value, member previews, and reBe seed without being forced to pay.

Open

Studio directoryRareEarths public piece

Checks

No paid wall before useful content
Studio Pass is visible as coming soon, not the first experience
Working Rooms are clearly coming soon
Profile 2

First-time subscriber

Fresh Chrome profile, signed in with checkout account

Start checkout, return to success page, and see Studio Pass continuity immediately after Stripe confirms.

Open

Member preview sectionCheckout success shape

Checks

Google sign-in works for studio.cyos.io
Stripe checkout returns to the same piece
Success stores studio:tier and studio:lastCheckout as a short-lived browser hint
The signed-in account and Stripe membership remain the durable source of truth
Profile 3

Returning subscriber

Same paid profile after closing/reopening browser

Recover membership through session tier or local paid hint without asking the person to pay twice.

Open

Return to paid piece

Checks

Signed-in session shows member/admin tier when webhook or verification has landed
Local paid hint prompts sign-in restore instead of another pay wall
Profile 4

Studio owner

Signed-in owner/admin profile

Stage a piece, submit publishing intake, get a public URL, and run owner/public/invite smoke links.

Open

RareEarths owner consolereBe owner console

Checks

Submit intake requires sign-in
HTTPS asset URL is required for URL publishing
Upload readiness shows storage configured or storage not configured before choosing files
Selecting a main artifact auto-fills title, slug, type, and No transcript when appropriate
Upload stores objects under networks/{network}/owners/{ownerThing}/pieces/{piece}
Unknown networks and non-owner sessions cannot publish
Published dynamic catalog item appears in library and piece route
Profile 5

Invited recipient

Fresh Chrome profile opened from an individualized signed invite

Activate the pre-provisioned invite Thing, see who sent it, and open seeded reBe context.

Open

Unsigned seed example

Checks

Seeded banner is visible
Signed invite token activates the recipient Thing when present
Anonymous visitors cannot mint signed invites

Individualized invite pack

Use the Send panel to create the real links.

Do not hard-code private contact details into public pages. Open the Studio piece as the owner, fill the recipient fields, copy the full message, then mint the signed invite. Test each signed invite in a fresh Chrome profile before sending it.

Technical leader
To: NameOrg: CompanyRole: CTO / chief architect

I thought this piece would be useful for your edge AI, sovereignty, or infrastructure strategy.

What would this mean for our roadmap?What should we pilot first?What should I ask next?
Investor / partner
To: NameOrg: FirmRole: venture / partner / advisor

I thought this would help explain why Distributed Sovereign Intelligences is becoming a working community, not just content.

Where is the first commercial wedge?What proof would increase confidence?Who else should see this?
Domain collaborator
To: NameOrg: Community / projectRole: subject expert / operator

I thought this could become a shared Studio path with source notes, discussion, and reBe-guided synthesis.

What context is missing?What source material should be added?What would make this useful to your collaborators?
1. Copy message: readable outreach text for LinkedIn, email, or SMS.2. Copy signed invite: pre-provisioned invite Thing plus first-browser activation path.3. Fresh-profile smoke: invite banner, signed activation, seeded reBe context, and no forced paywall.