Playbook: Public And Marketplace

Load when changing Discover visibility, marketplace visibility, public copy,
pricing, install behavior, or public/end-user output.

Approval Boundary

Public visibility, marketplace visibility, paid-flow settings, release, and
promotion require explicit author approval. Keep authoring, live version,
activation/setup, Discover install, marketplace, public app page, installed run,
and output page as separate proof surfaces.

The public marketing app page is always derived from the flow slug:
https://breyta.ai/apps/<flow-slug>. Include that URL in public handoff proof
alongside the workspace install and Discover surfaces.

Do not treat "make this a public app" as approval to expose the flow to all
Breyta users. Do not set :discover {:public true}, :marketplace {:visible true}, or equivalent CLI flags until the author explicitly approves and the
flow has installable-ready proof.

Default Loop

1. Confirm the requested public surface:
   • Discover listing
   • marketplace visibility
   • paid/pricing
   • public app page copy
   • install/setup/run behavior
   • for paid source-authored apps, whether the catalog belongs under
     :marketplace {:app {... :monetization {:plans [...]}}} or an existing
     legacy :marketplace {:monetization ...} listing must be preserved
2. Inspect current state:
   • breyta flows show <slug>
   • breyta flows discover search "<query>" --include-own --limit 5 when debugging own public indexing
3. Keep installable values out of source:
   • use :requires, setup inputs, run inputs, connection slots, templates, and resources
   • avoid hardcoded workspace ids, user ids, emails, private URLs, and secrets
4. Verify release/install shape, not draft alone:
   • breyta flows show <slug> --target live
   • breyta flows run <slug> --target live --interface-id <id> --wait
   • installation commands or UI proof when install behavior changed
   • for HTTP/MCP public flows, inspect installed interfaces with
     breyta flows installations interfaces <installation-id> and run one
     installation-scoped interface smoke test
5. Use supported CLI/API operations directly once approved; ask only for true
   author decisions such as visibility, exact price, currency, paywall timing,
   free runs, and public claims.
6. Inspect public output from the intended audience perspective. Markdown,
   tables, media, and resource viewers should be readable without raw debug
   payloads.
7. Consider step-level metering or cost estimates for paid external API, LLM,
   search, and other provider calls. State when cost metadata is unavailable.
8. Report all relevant URLs: source flow, live version, activation/setup,
   Discover/public listing, https://breyta.ai/apps/<flow-slug>,
   marketplace/app page, run, output, and resources.

Common Pitfalls

• /activate is setup proof, not Discover install proof.
• Template search is not public catalog proof.
• Draft CLI proof is not public-ready proof.
• The workspace install URL is not the marketing app URL. Use
  https://breyta.ai/apps/<flow-slug> for public app-page proof.
• Public copy should explain audience, setup requirements, run input,
  integrations, outputs, limits, and failure expectations.
• New paid apps should use app-owned plan catalogs. Keep plan ids stable, use
  at most one default/recommended plan, and do not describe seat pricing unless
  explicit seat entitlements exist.

References

• Paid Public Flows
• Installations
• Flow Metadata
• Output Artifacts