Showcase and publishing

Create a deliberately public browser demonstration and a product listing without exposing the whole authoring workspace. This guide follows the selected release through preview, metadata review, publication and visitor-side verification.

Before you begin

Open the intended cApp project and select a verified compiler release of the application. Compile it in Build first. Showcase does not recompile raw source and does not treat an unverified reference as a publishable product.

Decide what a visitor should be able to do, which data is safe to show and which services the demo needs. Use sample or deliberately public data. Have access to the GitHub account/organisation that will own the public payload repository; signing in alone does not establish repository publication permission.

Showcase and Showroom have different jobs

A public demo is not a copy of the installed authoring workspace. Browser code is inspectable. Omitting private backend source does not make a secret embedded in frontend JavaScript private.

Prepare a demo deliberately

1. Open Showcase and confirm Demo target and Selected compiled release. Check app, version and release identity.
2. Choose Build & preview demo. Read the compatibility result before assuming every selected Sidecar will run in a browser.
3. Inspect the actual rendered demo, including its initial data, visible navigation and intended interaction. This is the Showcase browser payload, not just a screenshot of Build.
4. Use Show demo sidecars to inspect composed browser capabilities, and the preview controls to test the visitor experience.
5. Before publishing, check the listing, publisher information, media and backend policy described below.

For multi-app projects, Project component demos separates compiled product surfaces, diagnostic surfaces and blocked or missing results. Switch between the available components and inspect each one. Publishing walks the available components into a canonical project listing; do not assume the currently visible component is the only public surface. Review per-component copy, readiness and captures.

A selected immutable User Guide can accompany a compatible demo. Guide drafts, authoring endpoints and private project knowledge must stay out of that projection. Use the Guide release workflow to select reviewed end-user help.

Preview controls and backend policy

Focus demo, Launch / refresh, Stop, Clean preview and the Sidecar-panel controls affect the demonstration session. Reset data resets the demo's browser-session state; do not interpret it as an undo for any request already sent to a remote service. These controls do not rewrite the selected compiler release or install a native app.

Under Info & advanced, inspect compatibility and Showcase backend mode:

Choose Apply policy after reviewing a mode change. A URL is not an unrestricted network grant. Public service access still needs permitted routes/provider access; the visitor must not inherit your owner credentials. A simulated or unavailable native feature should remain labelled, not represented as a live integration.

Before enabling a remote backend, check its public-data scope and operation effects. Do not expose a production service simply to make a demo control look functional.

Give the demo a repeatable starting state

An application can supply a public synthetic snapshot at /.well-known/capp/showcase-demo.json. The materializer prefers the copy inside the verified release; otherwise it may retrieve the same path from the project-bound release backend without credentials. Review this endpoint/file as public information, not a private build hook.

The following illustrates storage, a local response and a blocked action. Replace the example keys and paths with ones your application actually reads; these names do not create new cApp APIs.

{
  "protocol": "capp.showcase.demo-snapshot.v1",
  "profile": {"id": "default", "label": "Sample account"},
  "live": {"mode": "none", "capabilities": []},
  "browserStorage": {
    "localStorage": {"example.preferences": "{\"displayName\":\"Ada\"}"},
    "sessionStorage": {}
  },
  "routeFixtures": [
    {
      "path": "/api/demo/profile",
      "methods": ["GET"],
      "response": {"status": 200, "json": {"name": "Ada", "demo": true}}
    }
  ],
  "lockedRoutes": [
    {"path": "/api/demo/delete", "methods": ["POST"], "reason": "Unavailable in this demo"}
  ]
}

The snapshot is embedded into the demo's verified identity; opening that artifact later does not refetch its seed. Each preview session gets a fresh working copy, and reset/reopen returns to the embedded starting state. Browser-storage values are strings. Route fixtures are local responses, and locked routes return a local locked response instead of contacting a backend.

A snapshot can also seed declared cApp collections; it cannot create a new collection or provider grant merely by naming one. live.mode: "none" describes a local-only profile, while provider-grants still requires separately authorised service access. Neither synthetic account state nor a premium-looking UI proves real authentication or payment. See the snapshot schema and client runtime API for the contract and showcaseDemo() context.

Review product and publisher information

Open Edit Showroom listing. Review the name, tagline, directory summary, full description, listing type, maturity stage, supported platforms, availability and feature highlights. Availability is a discovery signal, not an automatically executed sale or licence agreement.

Set the intended public repository owner and name. The publication flow can create or reuse the public payload repository; this does not require publishing your complete application source. Keep source-repository access and demo-repository access conceptually separate.

Use the live listing preview. Save draft saves local project metadata; it does not publish. Reload published retrieves the published listing, so preserve unsent edits before replacing them. Download JSON shell and Import JSON support reviewed metadata editing; they do not let imported text replace verified demo hashes, releases or repository authority.

Open Publisher profile for public identity, contact links, capabilities, proof and updates. Review it independently and use Publish profile for that public change. A publisher profile is not the same object as one product listing.

Review screenshots and captures

Provide a cover, useful alt text and relevant gallery images. The editor supports PNG, JPEG and WebP inputs and re-encodes accepted images as WebP to remove original metadata; SVG/GIF are refused. Re-encoding does not remove private information visible inside the image.

Capture visible frame captures the configured demo. Auto navigate + capture explores rendered safe states; multi-component capture can cycle landing surfaces at Wide, Compact and Mobile sizes. Inspect the capture navigator and resulting images rather than assuming automatic capture found the best public story.

Auto capture missing listing/component media on publish is enabled in the current editor. Review that setting before publication: publishing may also generate missing demo media. Disable it and supply reviewed images when you need full control over exactly what is captured. Only the configured demo should be a capture input, not hidden source content or unrelated windows.

Publish and verify the result

Choose Publish to Showroom to enter the publication workflow. Sign in with GitHub and confirm that the cApp GitHub App is installed with access to the intended publish target. A successful sign-in without an appropriate installation is not sufficient.

Before upload, cApp verifies the exact public payload and runs its publication safety checks. Resolve a blocker rather than bypassing it. Automated scanning is an additional guard, not a substitute for reviewing code, screenshots, links and data yourself.

Inspect the publication result. When a recorded publication is incomplete, the UI may offer Resume Showroom publication; inspect which stages already succeeded before creating another repository or new publication. Multi-component publication can have partial outcomes, so read its component results and canonical-listing status.

After publication, open the resulting product page as a visitor without your owner session. Confirm the title, version, intended components, public media, publisher links, backend behaviour and demo operation. Reload the deep link directly, try a narrow screen and exercise one safe representative workflow.

A GitHub upload and a Showroom index update are separate stages. A returned registration response alone is not proof that the intended indexed page is visible. Compare the actual product page and demo against the selected release before announcing it.

Public records and updates

Public product and publisher documents live in publisher-owned GitHub content. The hosted directory is a discovery index, not the authoritative application backend or source repository. The protocols remain capp.showroom.product.v1 and capp.showroom.developer.v1; the latter includes publisher, studio and team identities.

For copy or media changes, edit the listing, review the preview and publish the update. For application behaviour changes, compile a new release, rebuild the public demo, then publish and verify that version. Editing a description does not replace the demo's code. Keep user-facing release/update notes short and tied to functionality rather than internal work logs.

See the schema reference for reviewed contracts. For an offline inspection before publication, Download demo exports the .capp-showcase artifact; the advanced Choose local .capp-showcase and Preview verified local flow re-verifies it before preview. Local disk is not a trust exemption.

Troubleshooting

What success looks like

An unauthenticated visitor sees the intended product, public profile and verified browser demonstration, with simulation/native limits clear and no private workspace data. For native distribution, return to Build's release checklist; a successful Showcase is not native acceptance.