Unify App/Pipeline into one app type; make Overview consumer-visible for every app#6
Merged
Merged
Conversation
The Overview tab previously rendered only from a deployment manifest (`Pipeline`), so it appeared only for the org's own deployed apps and never as the default tab on the consumer base — meaning the public apps a consumer browses from Explore had no Overview at all. Render Overview from the catalog `model` (App), which exists for every app, and treat the deployment manifest as optional enrichment: - Headline stats (Calls·7d, p50 latency, uptime, warm orchestrators) come from the model, so they show for any app. Warm-orchestrator count is a liveness/capacity signal for the caller. - Endpoint card shows the call URL for every app; per-route rows appear when the deployment manifest is known. - Deployment-backed apps additionally get the full Deployment card (pipeline id, entrypoint, image, version, GPU, last deployed, deployed by, environments) + the request Schema — shown to any viewer. - Catalog-only apps get a lighter Details card (provider, category, type, pricing) so the tab isn't bare. Overview is now available to everyone and is the default landing tab. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There were two disjoint types — `App` (static catalog model) and
`Pipeline` (a deployed-app manifest) — with separate arrays and separate
lookups, even though the product vocabulary says "an app is a deployed
pipeline." This makes the data match the vocabulary: one app type, one
catalog array, one lookup, and every app carries its pipeline manifest.
- `App` keeps all its catalog fields and gains `deployment?: AppDeployment`
(the former `Pipeline`-only manifest: pipelineId, entrypoint, image,
version, gpu, endpoints, createdBy, environment, kind, status,
visibility, warm orchestrators, calls/latency/error metrics).
- `Pipeline` is now a transitional alias — `App & { deployment }` — so
operator components keep their prop types while reads migrate to
`app.deployment.X`.
- One `APPS` array = third-party catalog models (each given a derived
manifest) + the org's own deployed apps (manifest lifted from the old
PIPELINES literal). One `getAppById`; `getModelById` /
`getCapabilityById` / `getPipelineById` are thin deprecated aliases.
- Helpers (`publicPipelines`, `publicCatalog`, `deploymentsForPipeline`,
`PIPELINE_APP_IDS`, visibility) preserve their prior meaning over the
unified array — Explore shows the same set, multi-env "Deployed in"
pills intact, no private apps leak.
- The app-detail Overview now takes a single `app: App` and reads
`app.deployment`. Catalog models therefore surface a (synthetic, mock)
deployment manifest too, consistent with "every app is a pipeline."
Verified: typecheck, lint (0 warnings), build all pass; Explore (20
cards), catalog + owned app detail, and Home all render correctly.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
adamsoffer
changed the title
adamsoffer
added a commit
that referenced
this pull request
Jun 17, 2026
Layers the operator/publishing surfaces — the actor who *deploys* apps — on top of the consumer base. Adds, on top of main: - Home: the Deployed-apps health panel, plus the command-bar deployments readout and the erroring/building "attention line". - Onboarding: the deploy-flavored "Get started" (push a hello-world pipeline) alongside the consumer loop. - Nav: the Apps list route (/apps) and its sidebar entry. - Settings: the Deploy tokens tab + its settings-rail item. - API keys: the "to deploy your own apps, use Deploy tokens" pointer. - App detail: owner/operator chrome (Settings/manage tab, publish controls) re-enabled. Rebased onto main after the App/Pipeline unification (#6) merged: the operator surfaces (AppsHealthPanel, AppsView, LogsView, HomeCommandBar attention line) were migrated to the unified app type — manifest reads now go through `app.deployment`, and the operator fleet is sourced from `OWNED_APPS` / `appsInEnvironment`. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
Two related changes to the app model — a data-model unification, plus the Overview fix that motivated it.
1. Unify
AppandPipelineinto one app typeThe vocabulary rework established that an app is a deployed pipeline, but the data still kept two disjoint types:
App(static catalog model) andPipeline(a deployment manifest), with separate arrays and separate lookups. That split is what made catalog models and deployed apps behave like different things. This makes the data match the vocabulary:Appkeeps all its catalog fields and gainsdeployment?: AppDeployment(the formerPipeline-only manifest:pipelineId,entrypoint,image,version,gpu,endpoints,createdBy,environmentId,kind,status,visibility, warm orchestrators, calls/latency/error metrics).Pipelineis now a transitional alias —App & { deployment }— so operator components keep their prop types while reads migrate toapp.deployment.X.APPS= third-party catalog models (each given a derived manifest) + the org's own deployed apps (manifest lifted from the oldPIPELINESliteral).getAppByIdis the single lookup;getModelById/getCapabilityById/getPipelineByIdare thin deprecated aliases.publicPipelines,publicCatalog,deploymentsForPipeline,PIPELINE_APP_IDS, visibility) preserve their prior meaning over the unified array — Explore shows the same 20 cards, the multi-env "Deployed in" pills are intact, and no private apps leak.2. Overview tab is consumer-visible for every app
Overview previously rendered only from a deployment manifest, so it appeared only for deployment-backed apps and never as the default tab — the static catalog models a consumer browses had no Overview. It now takes a single
app: App, renders headline stats from the app, and the Deployment/Schema/Endpoint detail fromapp.deployment. It's the default landing tab for every app.Note worth a look
Because every app now carries a manifest, catalog models surface a (synthetic, mock) Deployment card — e.g. FLUX shows
pipelineId: flux-schnell, a derived image/entrypoint/GPU, "Deployed by Black Forest Labs". That's intended ("every app is a pipeline"), but the manifest values for third-party models are fabricated mock data. Flag if you'd prefer catalog models not surface a synthetic manifest.Verified
pnpm typecheck,pnpm lint(0 warnings),pnpm build— all pass (15/15 pages).flux-schnell) and owned-app detail (app-sentiment) Overviews, and Home all render correctly.🤖 Generated with Claude Code