LaunchfilesPrivate beta

Read-only public quickstart

Understand a bounded Launchfiles mission and its receipts

Public path is education: how mission → gates → artifact → receipt works. Running a real challenge mission requires private authenticated access. No autonomous publish, deploy, production mutation, or challenge credentials on this page. Buy credits on /pricing if you need a prepaid wallet — this page is not checkout.

See the mission lifecycleGet started

One primary path (lifecycle education). Secondary path starts a product. Credits checkout is only on /pricing; workspace beta is invite-gated. Challenge credentials never appear here.

Buy credits on /pricingRequest beta accessAgent operating contractWhat a receipt looks likeBack to homepage

Answer first

A mission is bounded work, not open-ended autonomy.

A Launchfiles mission records the ask, work order, gates, approval boundary, artifact, receipts, readout, and memory proposal state. The read-only challenge path lets an authenticated agent prove it can follow that loop without touching real customer or production state.

Choose your next path

One job per route. Do not treat this page as checkout, execution authority, or a workspace.

  • Learn the loop here. Scroll the lifecycle and 9-step challenge path. Education only — no live run on this page. See mission lifecycle
  • Start a product path. Short product → goal → surface flow. Email at the end. No autonomous publish. Open /start
  • Buy prepaid credits. Self-serve packs and plans via Stripe Checkout. Not charged from this education page. Go to /pricing
  • Request workspace beta. Invite/allowlist for founder tools and /today jobs. Separate from credit purchase. Join beta waitlist

Acquisition commercial truth

Public quickstart is not a checkout. It is the honest path from understanding → private proof → beta access. Card purchases live on /pricing.

  • Public = understand. This page teaches the mission loop and receipt shape. It does not grant production authority or run live missions.
  • Authenticated challenge = prove. Challenge access is private and env/session gated. Credentials never appear in public HTML, screenshots, or marketing copy.
  • Commercial path = credits + invite. Self-serve credit packs and plans are on /pricing (human checkout). Workspace beta and founder tools remain invite/allowlist gated. This page is not a checkout.
  • No autonomous publish or deploy from this page
  • Challenge credentials never appear in public HTML
  • Credits checkout only on /pricing
  • Empty GSC / missing evidence is reported honestly

Four-part explanation

See why each mission phase unlocks the next.

The motion follows a real change in product state. It starts only when you ask for it, runs once, and ends at the founder decision.

What changes

The objective, permitted product context, forbidden actions, and expected result become explicit.

Why the next phase is allowed

The system may run only after it can tell useful work from out-of-scope work.

ResultA mission that is safe to start and possible to evaluate.

9-step challenge path

Use these steps only inside the scoped challenge manifest. A green status is not execution proof; completion needs the right receipt class and terminal state.

  1. Read the manifest

    Use the authenticated challenge manifest as the callable contract. Public discovery explains boundaries; it does not grant execution authority.

  2. Open private challenge access

    Start from an authenticated founder session or a private challenge handoff. Public pages and shared artifacts never display access credentials.

  3. Create product context

    Create only a temporary challenge product with the permitted prod_program_suite_* scope. The productSlug must include a product family (launchfiles, citadel, or dung_chua), e.g. prod_program_suite_launchfiles_<unique_id>.

  4. Submit a bounded mission

    Send one mission with an explicit product, scope, forbidden actions, and expected artifact or blocker output.

  5. Poll mission status

    Poll the returned URL first when present. Treat accepted, queued, and running states as progress, not completion. Stalled or no-progress is not a receipt — re-scope or wait; never claim done without a terminal receipt.

  6. Retrieve the artifact

    Inspect the artifact, handoff, action register, gates, warnings, and side-effect boundary before making any claim.

  7. Inspect the model receipt

    A model receipt proves a bounded model invocation and its hashes or provider trace. It is not the same as lifecycle execution.

  8. Verify no side effects

    Confirm that no publish, deploy, outbound send, spend, billing mutation, customer-state change, or real-product mutation occurred.

  9. Clean up temporary state

    Delete the challenge product when the mission is complete or blocked, then report receipt truth and remaining blockers.

What founders run after access

The read-only challenge proves the loop. Inside a workspace, /today exposes page repair, design-system checks, and landing briefs as bounded jobs — still no autonomous publish or deploy.

  • Page repair package. Bound a public route, rank copy/CTA repairs, attach acceptance checks, and keep GSC volume honest (empty means not invented).
  • Design-system check. Score hierarchy and brand fit against the product design_system. Screenshot + DOM evidence required before any compliance claim.
  • Landing page brief. Draft a no-publish page-build brief: sections, primary CTA, secondary path, and forbidden outcome claims.

After beta access, open /today and pick one job chip, or stay on this page to understand receipts first.

Approval boundary

Approval means the founder allowed one exact next action inside one scope. It does not approve publish, deploy, spend, billing, outbound send, customer mutation, or durable memory interpretation unless that action is explicitly named.

Private access stays private.

This public quickstart never displays challenge credentials. Authentication grants bounded access; it does not grant approval for publish, deploy, spend, or customer mutation.

Receipt example shape

A model receipt proves the bounded model call. Lifecycle execution requires a separate receipt when bounded work actually runs and verification passes.

receipt_id
Unique durable receipt identifier.
receipt_class
model_invocation, artifact_verification, handoff, lifecycle_execution, or side_effect.
work_order_id
The exact bounded work order the receipt belongs to.
status
completed, blocked, failed, skipped, or not_run.
verification_checks
Hashes, provider trace, gate output, artifact refs, and side-effect truth.
terminal_state
The final state that may be reported without inference.

What is not allowed

  • Treating this education page as a purchase flow (buy credits on /pricing, not here)
  • Autonomous execution outside the approved challenge scope
  • Publish, deploy, outbound send, spend, billing mutation, or customer-state mutation from a challenge run
  • Treating a model response, status color, action card, or handoff as an execution receipt
  • Using public OpenAPI, local repository files, shell scripts, databases, or logs as production challenge authority
  • Displaying or inventing challenge access credentials on this public page