Interactive product tour on omadia.ai (no install)

[iret77]

Re-cut. Three proposals were filed here; two of them have shipped, so the ticket is trimmed to the one that is left. The shipped work stays below as the record, with numbers, rather than being deleted.

Already shipped

Original proposal	Where it landed
1. Prebuilt images + minimal core	#339. docker-compose.yaml pulls ghcr.io/byte5ai/omadia-middleware and ghcr.io/byte5ai/omadia-web-ui; kroki, minio, storage and embeddings moved into opt-in overlay files. First run is pull + start.
1b. Native installer	Went well past the original note. #355 replaced PGlite with native PostgreSQL 17 + pgvector, #357/#358 followed, and every release now ships macOS (arm64 and x64), Linux (AppImage, deb) and Windows installers. macOS signing landed via #558/#574. Windows signing is still open on PR #559, blocked on the Azure setup.
The API-key wall	#309 / PR #367. A Claude Pro/Max subscription works through the official CLI, so trying omadia no longer means buying API credit first.
2. One-click PaaS deploy	PR #471, commit 58c00985. render.yaml backs a Deploy to Render button, fly/ holds the Fly variant.

What is left

Proposal 3: a clickable walkthrough on omadia.ai (Arcade, Storylane or similar) that shows the prompt -> run -> audit-receipt flow without installing anything. No backend, no shared instance, decoupled from infra.

Acceptance criteria

• A visitor can step through the whole flow in the browser and see what a run and its audit receipt actually look like.
• It is hosted on the marketing site. No omadia instance is involved and nothing is multi-tenant, which is the constraint the original ticket set.
• Reachable from the landing page and linked from the README.
• Recorded against a real instance, with a note on who refreshes it when the UI changes.

Is it still worth building?

Worth answering before anyone starts, because the ground has moved since this was filed.

Both hard barriers named in the original ticket are gone. The Docker footprint went away with #339, the API-key wall with #309, and there is now a signed macOS build plus a one-click deploy button. A tour is a marketing asset today, not an adoption blocker.

The numbers point the same way from the other end. The repo sits at 26 stars and 6 forks, and installer downloads run in single digits per release. The thin part of the funnel is people hearing about omadia at all, not people bouncing off the install.

So two questions gate any work here:

1. Does this belong in this repo? The tour would live on the marketing site, which is its own repository (byte5ai/omadia-homepage). If it gets built, the ticket should move there.
2. Is a tour the best use of that effort compared to anything that increases reach? Closing this as "not now" is a legitimate answer, and the one this re-cut leans towards.

Re-cut as part of wave K. Original body preserved in the edit history.

[iret77]

Adding a dimension this issue doesn't yet cover, plus a cross-link.

There's a third barrier besides the Docker footprint: the API-key / billing wall. A large share of evaluators already pay for a Claude Pro/Max subscription but have no console.anthropic.com API billing set up. Today omadia only accepts a metered ANTHROPIC_API_KEY, so even once the stack is light enough to run, those users hit "API key required" and stall. For the "just let me try it" funnel this is often a harder stop than Docker.

The lever already exists as a design: #309 (subscription-backed agents via the official CLIs — claude -p / PTY, sanctioned, no separate metered billing). That path lets a subscription holder run omadia with a local claude login instead of provisioning a metered key. So #309 isn't only cost/provider-parity — it's the structural fix for the onboarding key-wall.

Recommendation: treat #309 (at minimum the cheap Shape 2 — a keyless, tool-less claude -p shim) as an onboarding enabler, not an "experimental / later" nice-to-have. Combined with the prebuilt-image / minimal-core work (#336), it yields a first run with no Docker build and no API key — which is the actual bar for a non-technical evaluator.

[iret77]

Research status — onboarding path portfolio (for colleagues to pick up)

We worked the onboarding solution space end-to-end. Outcome: three complementary paths, not an either/or.

Path	What	Home	Status
c	Docker compose (the existing dev/self-host way)	this repo	exists; stays for devs / production-near
a	self-contained desktop app — bundle the backend into the existing omadia-ui Electron app	byte5ai/omadia-ui#40	concept
b	setup-prompt + public skill file — an agent (Claude/Codex desktop app) installs omadia locally	#338	concept

Key findings from the research

• The under-rated blocker isn't only Docker — it's the API-key wall. Many evaluators hold a Claude Pro/Max subscription but have no metered API billing. #309 (subscription via the official CLI, claude -p) is the structural fix, and it's not a show-stopper (~1–2 days for Shape 2; the keyless provider seam already landed).
• omadia-ui is a mature Electron canvas app with an auto-release pipeline (mac/win/linux), but today it's a client against a running host. Setup / Builder / Audit are web-ui-only (the canvas doesn't cover them yet — planned, but capacity-bound). The Agent Builder is elementary (omadia isn't really usable without it), so a self-contained app must bundle web-ui as an interim admin layer. Details in omadia-ui#40.
• Signing is not a blocker (byte5 can sign).
• The consumer desktop app can execute locally → Path b is viable for laypeople (desktop apps), not just dev-CLI users. Note our kemia/palaia precedent ran through dev tools (OpenClaw, Claude Code), so the desktop-app route is new — see Concept: setup-prompt onboarding — agent-driven local install via a public skill file #338.

Direction

• a→b is a stack, not a rivalry: once the prebuilt app (a) exists, b's skill file shrinks to "download, start, connect subscription" — robust and cheap. Starting with b alone means orchestrating the heavy from-source/Docker install (fragile).
• Current lean: a first (the learned, deterministic path) as the benchmark b must beat on real user value; ship both if they come out even per scenario.
• Open / next step: a hands-on dry-run of the non-Docker install — measures real robustness and produces the first draft of b's skill file. Planned next session.

Full detail in omadia-ui#40 (a) and #338 (b); engine in #309/#280; footprint findings in #336.

[iret77]

Status update — Path a shipped today; linking the path map

@Weegy landed the desktop app in #341 (merged): a native one-click installer under desktop/ — an Electron supervisor that forks the existing kernel + web-ui (unchanged) over an embedded PGlite (no Docker), with OS-keychain secrets, an onboarding wizard, tray, and auto-update. #342 (open) adds the cross-platform build/sign CI.

It already resolves the PGlite concerns raised on byte5ai/omadia-ui#40: single-connection → GRAPH_POOL_MAX=1; migration parity → pgcrypto dropped (gen_random_uuid is core PG13+); pgvector + pg_trgm loaded.

Path map (current):

• a — native installer: feat(desktop): native one-click installer (Electron + embedded PGlite) + signing CI #341 (shipped) · fix(desktop): installer CI build/sign pipeline + review hardening #342 (build/sign CI) · concept/analysis in Concept: self-contained desktop build — bundle the omadia backend so the app runs standalone (no Docker) omadia-ui#40
• b — setup-prompt + public skill file: Concept: setup-prompt onboarding — agent-driven local install via a public skill file #338 (concept)
• c — Docker minimal-core: feat: minimal-core onboarding stack (prebuilt images + opt-in overlays) #339 (shipped — prebuilt images, closes Default compose stack is heavier than documented + two docs/compose contradictions #336)

All three are complementary onboarding paths (no either/or); c is the existing dev/self-host way, a + b target non-technical evaluators.

[Weegy]

Triage

Priority: P2 · Category: ux · Effort: M (for the remaining scope) · Status: partially shipped — most of the original scope is on main

The path-map comment above (2026-06-19) is still the right frame, but it predates several ships. Verified against main@1e5b24d, the two hardest barriers named here — Docker footprint and the API-key wall — are both resolved. What remains open from the original proposals is proposal 2 (PaaS deploy template) and proposal 3 (interactive tour), plus the path-b concept #338.

Implementation notes

Shipped since the last status update (verified on main):

• Proposal 1 (prebuilt images + minimal core) — done via feat: minimal-core onboarding stack (prebuilt images + opt-in overlays) #339. docker-compose.yaml pulls ghcr.io/byte5ai/omadia-middleware / omadia-web-ui (OMADIA_VERSION pinnable); kroki/mermaid, minio, and ollama embeddings moved to opt-in overlay files docker-compose.storage.yaml, docker-compose.diagrams.yaml, docker-compose.embeddings.yaml; .github/workflows/publish-images.yml publishes release + :edge images. README documents the minimal-core-first flow.
• Path a (native installer) — shipped beyond what the 2026-06-19 comments record. feat(desktop): native one-click installer with bundled PostgreSQL 17 + pgvector (macOS/Linux/Windows) #355 replaced the PGlite approach with bundled native PostgreSQL 17 + pgvector; follow-ups fix(desktop): onboarding wizard preload + install verbosity #357/fix(desktop): wizard freezes on Continue — rename colliding bridge const #358 fixed the onboarding wizard. Code lives under desktop/src/ (supervisor.ts, embeddedDb.ts, secrets.ts, updater.ts). .github/workflows/desktop-apps.yml builds installers on all three platforms (signing/notarization is fail-soft — applied when the repo secrets are present), and auto-release.yml attaches them — release v0.56.0 carries .dmg, .AppImage, .deb, and .exe assets. The no-Docker eval path this issue asked for exists and is downloadable today.
• API-key wall — Subscription-backed agents via official CLIs (Claude / Codex / Gemini) using an MCP tool bridge #309 closed via PR feat(#309): run agents on LLM subscriptions via the official CLIs #367 (merged 2026-06-24): agents run on a Claude Pro/Max subscription through the official claude CLI, no metered key required (Codex/Gemini CLIs are detected but Claude is the only v1-recommended path). Combined with the desktop app this delivers the "no Docker build, no API key" first run named as the bar in the first comment.

Still open:

1. PR fix(desktop): installer CI build/sign pipeline + review hardening #342 is stale — its scope (desktop build/sign CI) was delivered by feat(desktop): native one-click installer with bundled PostgreSQL 17 + pgvector (macOS/Linux/Windows) #355 and the current desktop-apps.yml. Recommend closing it unmerged, not rebasing.
2. Proposal 2 (Railway/Render/Fly deploy button) — nothing in the repo (no template files, no deploy badge in README.md). The prebuilt GHCR images make this cheap now, but its value should be re-weighed: the desktop app already covers the "no Docker, own instance" persona. If pursued, the embedding overlay (docker-compose.embeddings.yaml, Ollama) must be swapped for an API-based embedder on PaaS, as the issue already notes.
3. Proposal 3 (interactive tour) — belongs to the marketing site, which is maintained in a separate repository, not here. Suggest re-filing it there and dropping it from this repo's scope.
4. Path b (Concept: setup-prompt onboarding — agent-driven local install via a public skill file #338, agent-driven install skill) — untouched since filing (0 comments). With path a shipped, its skill file reduces to "download, start, connect subscription", exactly the a→b stacking the research comment predicted. Cheap now, but only worth doing after the installer has some real-user mileage.

Risks / dependencies:

• Desktop signing depends on repo secrets (desktop-apps.yml builds unsigned/ad-hoc without them) — verify the published assets are actually signed/notarized before pointing evaluators at them.
• Proposal 2 introduces a hosted-secrets surface (LLM key in PaaS env vars); keep it single-tenant per-user instances as the issue's constraint requires.
• Cross-repo: proposal 3 work cannot land here.

Acceptance criteria (remaining scope):

• Decision recorded: pursue or drop proposal 2 given the desktop app now covers the no-Docker persona
• PR fix(desktop): installer CI build/sign pipeline + review hardening #342 closed as superseded by feat(desktop): native one-click installer with bundled PostgreSQL 17 + pgvector (macOS/Linux/Windows) #355
• Proposal 3 re-filed against the marketing-site repo (or explicitly dropped)
• Concept: setup-prompt onboarding — agent-driven local install via a public skill file #338 either scheduled with the reduced "download + connect" scope or closed
• This umbrella issue closed once the above are dispatched — everything else it asked for is verifiably on main

---

Automated triage against main@1e5b24d; posted after adversarial fact-check review.

[Weegy]

Closing as not planned.

The two hard barriers this ticket was filed against are gone. The Docker footprint went with #339, the API-key wall with #309 / PR #367, and there is now a one-click deploy button (PR #471) plus signed macOS installers on every release. What is left is a marketing asset, not an adoption blocker.

The funnel numbers point the same way. 26 stars, 6 forks, and installer downloads in single digits per release. The thin part is people hearing about omadia at all, not people bouncing off the install.

If the tour does get built, it belongs on the marketing site, which is its own repository (byte5ai/omadia-homepage), so the ticket would move there rather than live here. Reopen or refile there if that changes.