Manifest Model designed
The manifest is the app developer’s package of product and runtime intent. Full self-service manifest registration is still target-state work, but app teams should prepare metadata in the target shape now.
Manifest Layers
| Layer | Purpose |
|---|---|
| App metadata | Stable app identity: slug, display name, category, runtime backend, supported operating modes, supported scopes, UI behavior. |
| Version metadata | Version-specific runtime expectations, config schema, placement schema, credential classes, artifact set, bootstrap notes. |
Current-State Path
- Define app and version metadata under source control.
- Publish/register artifacts through current app-artifact APIs.
- Coordinate initial app/version registration through current platform-admin or seed paths.
- Use entitlement, app-instance, shared-runtime, and artifact APIs as the runtime-facing public surface.
Target-State Path
The target onboarding flow validates the manifest, registers app/version metadata, links artifacts, records review, and publishes or promotes the version through auditable channels.
SDK-Owned Fields
The manifest/SDK path should own or validate app-developer behavior that would otherwise leak into backend seed data:
| Area | Examples |
|---|---|
| Defaults | ports, health paths, route intent, auth mode, connect actions |
| Runtime contract | env vars, mounted credentials, tokens, service accounts, storage, network posture |
| Launch contract | required inputs, optional dependencies, default dependency creation, validation errors |
| Connect contract | Open app, Try endpoint, Open cluster, token/API-key flows |
| Failure contract | app-auth failure, upstream 503, missing token, bad route, unavailable artifact, node-task timeout |
Runtime bugs still belong to the runtime/controller owner. Catalog, manifest, publish, promotion, connect, and developer-visible behavior should be expressed through SDK-visible manifests, examples, validators, and smoke tests.
Current Validator Surface
The current SDK package validates launchable OCI workload manifests against contract families instead of requiring developers to infer supported behavior from seed SQL or backend runtime code.
| Contract family | Developer question answered |
|---|---|
profile | What kind of app contract is this and what launch mode is supported? |
artifacts | Which artifact is deployed, from which source, and is digest pinning required? |
parameters | What launch inputs can the app accept? |
resources | What compute or runtime resources does the app need? |
storage | What mounts or storage expectations does the app declare? |
network | Which endpoints, ports, route families, and auth patterns are exposed? |
execution | Which execution engines are supported and what is the default? |
outputs | Which declared endpoints become connect actions? |
validation | Which readiness checks prove the app is usable? |
SDK examples and portal docs should stay aligned to those families. If a new app behavior cannot be expressed there, treat it as an SDK/manifest gap rather than adding another backend-only assumption.