Launch is a different mode

A user asks for a timer and wants a link to send to three friends. The system should publish it in minutes. It should not demand a contact address, privacy review, app icons, scheduled jobs, or a custom domain.

Later the user asks for a public launch. That request changes the work. The app now needs a stable identity, truthful metadata, privacy text, indexing files, domain setup, and durable operating behavior. Some outputs make promises that are difficult to retract.

Casual publish and launch must be separate modes. The accessible forms from Native forms, native accessibility belong in both. Launch adds product and operational responsibilities.

Concept map

casual publish
  files + checks + stable preview link

explicit launch
  identity + privacy + SEO + PWA + jobs + push + domain
  + stricter checks + durable promises

Launch is opt-in state on the app, not a guess based on how polished the page looks.

Terms

Casual publish means putting a static app at a shareable link with ordinary safety checks.

Launch mode means an explicit app state that enables generated product metadata and operational capabilities.

Derived file is platform-generated output rebuilt from launch configuration and app facts.

Canonical URL is the public address search engines should treat as authoritative.

Indexing aftermath is provider work performed after publish, such as domain attachment, sitemap submission, or IndexNow notification.

Job is a scheduled, bounded pipeline that updates data or files without starting a full agent turn.

Irreversible promise is a public claim that cannot be silently changed without misleading users, such as data retention, notification behavior, ownership, or a canonical domain.

What casual publish should do

The normal path should remain small:

• Save static files.
• Generate the ordinary offline worker if that is the platform default.
• Run static, browser, and initial design checks.
• Block only hard errors.
• Publish to a stable provider alias.
• Return the link and advisory issues.

The app may be useful and shared. It is still a prototype in the product sense. It makes no claim about indexing, a canonical hostname, fresh scheduled data, or notifications.

Draft and casual links should default to noindex when the hosting model might expose them to crawlers. This is protection, not launch work.

Enter launch mode explicitly

Require a user request that clearly asks for launch, installability, public discovery, a custom domain, or a release campaign. Then collect the minimum identity:

• Public name and short tagline.
• Description grounded in what the app does.
• Contact address or owner.
• Topics or category.
• Accent or icon direction when relevant.
• Canonical domain preference.

Store this as structured launch configuration. It becomes the source for generated output and checks.

Disabling launch should remove derived files and active services where possible. It cannot erase cached pages, search results, notifications, or prior public statements.

Generate derived files, do not ask the model to maintain them

Launch output is repetitive and consistency matters. Generate:

• Web app manifest.
• Raster icons and maskable variants from one source icon.
• Apple touch icon and social preview image.
• Service worker with install, caching, push, and notification-click behavior.
• Canonical, description, theme, Open Graph, social card, and structured-data tags.
• robots.txt, sitemap.xml, and a short machine-readable app description.
• About and Privacy pages.
• Marked head and footer blocks in HTML.

Mark these files as generated and refuse normal edits. Regenerate them before every launch check and publish. If the same inputs produce different bytes, the generator is broken.

The generator should derive privacy text from facts, not marketing prose. Detect local storage, shared sync, push, external hosts, analytics, and monetization configuration. State what data is collected, where it goes, how long it remains, and how users can opt out.

If facts change, update the effective date. Never preserve an old promise because its wording sounds better.

SEO is mechanics plus truth

Metadata should match visible content. The title, canonical URL, heading, manifest, and structured data should agree on the app's name and purpose.

Submission can include:

• A sitemap at the canonical domain.
• IndexNow notification after publication.
• Search Console property verification and sitemap submission when credentials exist.
• Search-safe draft behavior before launch.

Run these actions after deployment and record each result. A generated sitemap does not prove indexing. Crawlers decide whether and when to index.

Avoid claims of search optimization without measured checks. Validate lengths, canonical consistency, structured-data syntax, robots policy, and reachability.

Jobs are not agent follow-ups

A public app may need to fetch a feed, transform data, update a file, or notify visitors on a schedule. Running a full model turn for every interval is expensive and unpredictable.

Use declarative jobs with bounded steps:

{
  "schedule": "0 */6 * * *",
  "steps": [
    {"fetch": "https://example.org/feed.json"},
    {"transform": "pickLatest"},
    {"emit": "data/latest.json"},
    {"notify": "New edition available", "onChange": true}
  ]
}

Restrict destinations, response sizes, execution time, frequency, and output bytes. Make model steps opt-in and token-capped. Hash outputs so unchanged work skips writes, deployments, and notifications.

Pause repeatedly failing jobs and report the failure to the owning conversation.

Push requires restraint

Visitors must choose to subscribe. Store subscriptions per app, enforce quotas, and allow unsubscribe. Only trusted jobs or an explicit owner action may send.

Rate-limit notifications per app and per day. Require useful content and a destination inside the app. A generated page must never send directly from visitor-controlled code.

Push belongs in Privacy text and should stop when launch mode ends. Existing browser subscriptions may remain until removed or expired, so state the cleanup behavior.

Domains and public identity

A custom domain creates DNS, certificate, CORS, shared-service, and canonical-URL work.

Attach the domain after a successful publish. Verify that the exact app origin is allowed by shared services. Reject nested or lookalike hostnames. Keep the provider alias as a diagnostic fallback, but make one canonical URL authoritative.

Changing canonical domains can leave redirects, search records, installed manifests, and shared links behind. Ask for confirmation first.

The same caution applies to names, retention, analytics, monetization, and announcements. Database edits cannot erase prior promises.

Decisions and rejected alternatives

Make launch explicit. Automatically launching every polished app adds cost and creates promises the user never requested.

Generate standard files. Asking the model to hand-maintain manifests, icons, privacy pages, and metadata invites drift.

Keep jobs deterministic by default. Full agent turns are too expensive for scheduled refreshes.

Require confirmation for announcements. Social posts and public submissions act outside the app and cannot be silently undone.

Keep casual apps out of indexing. Public reachability is not consent to search distribution.

Use one canonical domain. Multiple claimed canonical addresses split identity and complicate CORS.

Treat analytics and monetization as separate opt-ins. Launch does not imply tracking or payment.

Failure modes

• Every app enters launch mode. Simple requests become slow, expensive, and burdened with false formality.
• Privacy text is generic. It omits actual storage, sync, push, analytics, or third-party hosts.
• Derived files are editable. Later regeneration removes manual changes.
• A scheduled job deploys unchanged output. Quotas and caches churn for no user benefit.
• Push can be sent from client code. Visitors can spam other subscribers.
• Search submission is reported as indexing. The system claims an outcome it does not control.
• Domain setup ignores shared-service origins. Sync or analytics fails only on the canonical host.
• Retention changes rewrite history. Privacy terms imply the new period applied to old data. Rotate collection generations or state the boundary.
• Announcements happen without final confirmation. A draft message becomes a public commitment.

Launch checklist

• Did the user explicitly request launch mode?
• Is public identity stored as structured configuration?
• Are launch files deterministic, generated, and protected from direct edits?
• Does Privacy text come from actual app capabilities?
• Are drafts and casual publishes kept out of indexing?
• Do metadata, visible copy, manifest, and canonical URL agree?
• Are indexing actions recorded without claiming crawler outcomes?
• Are jobs bounded, observable, and change-aware?
• Are model-backed job steps explicit and capped?
• Is push opt-in, rate-limited, removable, and server-controlled?
• Does the canonical domain work with sync, analytics, and CORS?
• Do analytics and monetization require separate consent?
• Are domain, retention, and announcement changes confirmed?
• Can launch mode be disabled without pretending past public effects vanished?

The mini-app factory now has a complete path: durable artifacts, bounded editing, recoverable history, one-call shipping, non-blocking checks, browser evidence, reusable UI, mobile behavior, native controls, and an explicit launch boundary. One box, done well starts the next part by turning from app production to the smallest credible production cell that can operate the wider system.