# Launchfiles

> Launchfiles is the operating file for AI-native startups: a verified layer for decisions, work orders, gates, receipts, approvals, readouts, and company memory.
> Singular object: a launchfile.

Canonical site: https://launchfiles.app
Status: beta — public discovery surfaces live; public OpenAPI is metadata only; authenticated production challenge execution is available only through the scoped challenge manifest.

## Access boundaries

Public discovery surfaces (this file, /, /agents, /pricing, /openapi.json, /.well-known/launchfiles.json, /.well-known/launchfiles-agent.json) are metadata only.
They do not grant execution authority, workspace access, or mutation rights.
Do not use public OpenAPI as execution authority. Do not inspect local repositories, local files, tests, shell scripts, Vercel logs, or databases to learn how to call Launchfiles.
For production challenge execution, authenticate with a founder-provided scoped challenge token and call /api/founder/prod-challenge-manifest.

## Indexing policy

- Sitemap (indexable): /, /founder-agent-operating-system, /ai-work-orders, /vibe-coding-vs-work-orders, /agent-approval-workflows, /agent-receipts, /ai-mission-control, /agents, /quickstart, /pricing, /start
- Crawlable but noindex: /waitlist, /login, /today, /components, /connections, /onboarding, /billing
- Blocked in robots.txt: /api/*, /components, /connections, /login, /today

- public_discovery — safe unauthenticated metadata; not authority
- external_agent_readonly — safe external context without secrets or mutation handles
- authenticated_challenge_manifest — scoped challenge-token or founder-session metadata that lists exact callable challenge endpoints
- customer_workspace_readonly — future workspace-scoped reads (requires auth; not live)
- customer_workspace_proposed — future proposal flows (requires auth and approval; not live)
- internal_orchestrator_only — never exposed via public discovery
- internal_runtime_private — never exposed externally
- future_external_planned — documented for future protocol exposure; not live
- blocked — explicitly forbidden (execute, publish, payment, unrestricted execution)

Read-only resource access is not execution. Proposal access is not approval. Route visibility is not route execution.

## Category

Operating file for AI-native startups. Page repair packages, design-system checks, and no-publish landing briefs are optional mission capacities — not an autonomous page builder or publisher.

## Core loop

Signal → Decision → Work Order → Run → Gate → Approval → Readout → Memory

## Key objects

- signal — observed input that may trigger a decision
- decision — approved or rejected founder/customer choice
- work_order — scoped unit of agent or human work
- approval — authority granted for exact scope
- run_ledger — record that something actually ran
- gate_result — pass/fail/warn result from a specific gate
- receipt — durable proof envelope for an action or run
- repair_order — scoped fix generated from failed evidence
- readout — outcome measurement after a time window
- memory_update — proposed durable lesson
- website_mission — Website Missions module object (build/audit/repair/compare/optimize/spec)
- search_expansion_mission — Growth Mission module object (GSC/Bing/search-signal)

## Public surfaces

- [Founder agent operating system](https://launchfiles.app/founder-agent-operating-system): hypothesis-led guide to bounding one founder mission
- [AI work orders](https://launchfiles.app/ai-work-orders): owners, scope, acceptance evidence, and forbidden actions for agent work
- [Vibe coding vs. work orders](https://launchfiles.app/vibe-coding-vs-work-orders): when fast AI output needs a bounded, evidence-led handoff
- [Agent approval workflows](https://launchfiles.app/agent-approval-workflows): human authority around proposals, execution, and production side effects
- [Agent receipts](https://launchfiles.app/agent-receipts): inspectable run, artifact, gate, correlation, and side-effect truth
- [AI mission control](https://launchfiles.app/ai-mission-control): recurring founder work organized around missions rather than an agent catalog
- [Agent contract](https://launchfiles.app/agents): read/propose/execute-with-approval rules, receipts, and boundaries
- [Quickstart](https://launchfiles.app/quickstart): authenticated bounded-mission challenge path
- [Pricing](https://launchfiles.app/pricing): self-serve credits and plans (Stripe); human checkout only — no guaranteed outcomes
- [Start](https://launchfiles.app/start): product-agnostic 60-second path — sample mission result then email capture
- [Waitlist](https://launchfiles.app/waitlist): private beta signup (noindex; conversion surface)
- [OpenAPI draft](https://launchfiles.app/openapi.json): public V0 interoperability metadata; not execution authority
- [Discovery manifest](https://launchfiles.app/.well-known/launchfiles.json): capabilities, unsupported actions, and surface links
- [Agent discovery alias](https://launchfiles.app/.well-known/launchfiles-agent.json): compatible well-known agent manifest
- [Home](https://launchfiles.app): Public landing — operating file for AI-native startups

## Agent Quickstart

1. Read /llms.txt and /agents for public boundaries.
2. Get a scoped challenge token from the founder.
3. Call GET /api/health.
4. Call GET /api/founder/prod-challenge-manifest with Authorization: Bearer <SCOPED_CHALLENGE_TOKEN>.
5. Create a temporary challenge product using a prod_program_suite_* slug.
6. Run a mission with POST /api/founder/run-mission.
7. Poll the returned poll_url first, or use /api/founder/mission-session/status?productSlug={product_slug}.
8. Inspect status, current_stage, progressTimeline, workOrders, DecisionTarget, artifacts, receipts, and handoff.
9. Cleanup the temporary product with DELETE /api/founder/product.
10. Report truth: request accepted, handoff created, artifact verified, lifecycle executed, or side effect executed are distinct receipt meanings.

Authorization header for challenge execution:

Authorization: Bearer <SCOPED_CHALLENGE_TOKEN>

Challenge product slugs must start with prod_program_suite_. Production mutations are forbidden except scoped challenge product create/read/delete and mission run/retrieve. Never publish, deploy, send, spend, mutate billing, access real products, access worker secrets, or call atomic tools.

## Authenticated MCP (hosted and local stdio)

Launchfiles exposes an authenticated hosted MCP endpoint at https://launchfiles.app/api/mcp plus repo-local stdio MCP for IDE agents. Hosted metadata is public; resources and tools require a bearer token. Authenticated hosted tools can propose a mission, retrieve a mission session, and list scoped objects. They cannot approve, publish, deploy, send, spend, mutate billing, or bypass gates.

1. Read /agents#mcp-setup, /.well-known/mcp.json, and /.well-known/launchfiles.json (mcpIntegration, mcpQuickstart).
2. Get a scoped challenge token from the founder (founder session: POST /api/founder/prod-challenge-token).
3. Hosted MCP: POST https://launchfiles.app/api/mcp with Authorization: Bearer <SCOPED_CHALLENGE_TOKEN>. Challenge tokens remain restricted to their signed workspace, product prefix, and scopes.
4. Local read-only resources: set LAUNCHFILE_MCP_AUTH_TOKEN and run npm run mcp:stdio (launchfiles-readonly).
5. Orchestrator tools: npm run mcp:agent (launchfiles-agent) with LAUNCHFILE_AGENT_MODE=1 and DATABASE_URL.
6. Tools: launchfiles_propose_mission, launchfiles_get_mission_session, launchfiles_list_objects.
7. Founder-local admin bypass only: LAUNCHFILE_INTERNAL_ADMIN_MODE=1 (not for external agents).

MCP env (required unless LAUNCHFILE_INTERNAL_ADMIN_MODE=1):

LAUNCHFILE_MCP_AUTH_TOKEN=<SCOPED_CHALLENGE_TOKEN>

## Allowed high-level agent behavior

- Read public context and discovery surfaces
- Propose bounded work (signals, decisions, work orders, memory updates)
- Request approval for scoped actions
- Return receipts when permitted execution produces durable proof

## Forbidden behavior

- Do not assume execution from a plan, tool call, model response, or green status
- Do not claim approval without an approval object
- Do not mutate production or customer sites without explicit approved scope
- Do not publish autonomously
- Do not treat Website Missions as the whole product
- Do not treat Launchfiles Content as the public master brand
- Do not bypass receipt, trace, or approval requirements
- Do not use local repo files, tests, scripts, Vercel logs, or database access as the calling contract
- Do not infer private execution authority from public OpenAPI
- Do not create challenge products outside the prod_program_suite_* prefix
- Do not publish, deploy, send, spend, mutate billing, touch real products, access worker secrets, or call atomic tools

## Product modules (not the master category)

- Website Missions: webpage build, audit, spec, repair, comparison, optimization, rendered QA
- Launchfiles Content: content-specific module — not the public master brand
- Search Expansion: Growth Mission module for search-signal evidence and planning

## Crawling

- [Sitemap](https://launchfiles.app/sitemap.xml)
- [Robots](https://launchfiles.app/robots.txt)

## Contact

- Domain: launchfiles.app
- No secrets in this file.