Launch Surface Preparation

Purpose

Prerequisites

Steps

1. 01

   Validate the selected launch surfaces

   Read the supplied setup and create a normalized manifest. Require 1–10 sites, unique stable IDs and valid HTTPS URLs. Reconcile duplicate domains explicitly: select one canonical site and record every merged ID without dropping an input. Reject empty, malformed or conflicting setup with a descriptive native issue rather than inventing product facts or a site list. Validate the account mode; use research-only for every site without explicit permission. Never infer authority from a signed-in session. Write the manifest with all original IDs, canonical sites, scope, allowed account actions and missing optional assets. Do not copy identity details into public-facing drafts.

   Completion criteria

   • The manifest accounts for every supplied site ID exactly once as canonical or merged and records the authorized action scope for each canonical site.

   • Required product facts and permissions are verified; missing or conflicting setup is reported without fabricated values.

2. 02

   Research launch mechanics and eligibility

   Research each canonical site from the manifest in the in-app browser. Prefer current official documentation and actual submission forms. Record launch mechanics, complete field requirements, image sizes, community norms, common maker strategies, timing, eligibility, exact costs and dated source URLs. Record unavailable evidence as unknown, never as free or eligible. An account wall, disabled domain or CAPTCHA yields an explicit blocker; do not bypass it. Check for an existing product listing before proposing a new entry. Record one result for every canonical site, even if research is partial. Never create accounts or mutate the site in this step.

   Completion criteria

   • Every canonical site has dated sources, explicit eligibility and cost evidence or a named unknown, and requirements or a specific access blocker.

3. 03

   Prepare permitted accounts and profiles

   Process the researched sites sequentially. Research-only, unapproved, ineligible, paid-only and unknown-cost sites receive a recorded no-action outcome. For explicitly permitted eligible free sites, first inspect existing account/product state and reuse it; never create duplicates. Use only the approved identity and profile facts. Prefer the approved existing sign-in session. If password signup is required, create a strong unique password only when an available secure secret store can hold it immediately; record its key name only. If secure storage or owner authentication is unavailable, record setup blocked and continue independent sites. Stop that site at email verification, CAPTCHA, ambiguous visibility, billing, or an unapproved permission request. Use approved assets only; record missing required assets. Never purchase, bypass a challenge, send messages, follow, vote, post or submit a launch. Save account state, public URLs, fields completed and blockers; never save credentials or private session data.

   Completion criteria

   • Every canonical site has an account outcome; each mutation is supported by explicit permission and current eligibility evidence.

   • Existing accounts were reused; passwords, tokens and recovery codes are absent from all artefacts.

4. 04

   Create launch strategies and unpublished drafts

   Combine the research and account results into one site-by-site launch pack. For each site provide positioning and audience fit, allowed categories, approved copy blocks, exact required fields/assets, recommended timing, preparation tasks, launch-day activities and follow-up recommendations. Keep blocked and ineligible sites with their evidence and next owner action. Do not invent missing product claims. If permission allows it, an account exists, and the site clearly supports a private draft, save it unpublished and record its URL and observed state. Otherwise keep the draft local. Never publish, schedule, submit or queue a launch, and never treat a public profile action as a private draft.

   Completion criteria

   • Every canonical site has a launch strategy or a clearly explained ineligible/blocked outcome, with local drafts and any verified private draft URL.

   • Every factual product claim comes from approved inputs; no launch was published, scheduled or submitted.

5. 05

   Reconcile the launch preparation results

   Produce a final report and JSON status register. Map every original site ID, including merged duplicates, to exactly one result: prepared, research_only, partial, ineligible, or blocked. Include sources, account state, draft state, blockers, output paths and specific owner actions; count inputs and results and explain every merge. Missing or invalid evidence remains partial or blocked. Verify that every referenced output is from this run and readable. Do not claim a successful account or draft from a planned action. Return the report to the owner; do not contact external people or dispatch another routine.

   Completion criteria

   • Input IDs and final status IDs are equal sets, with no duplicates or missing sites; every merge has an explicit canonical ID.

   • The report separates completed actions, partial evidence and unresolved owner actions and contains no secret values.

   Outcomes

   • completed

     Launch preparation is reconciled, including any blocked sites.

Escalation