UIAP Authoring/Manifest

UIAP Authoring/Manifest Spec v0.1

Feld	Wert
Status	Draft
Version	0.1
Datum	2026-03-27
Abhängigkeiten	[UIAP-CORE], [UIAP-CAP], [UIAP-WEB], [UIAP-ACTION], [UIAP-POLICY], [UIAP-WORKFLOW]
Editoren	Patrick

Normative Begriffe

Die Schlüsselwörter MUSS, DARF NICHT, SOLLTE, KANN in diesem Dokument sind normativ gemäss RFC 2119 und BCP 14 zu interpretieren, wenn und nur wenn sie in GROSSBUCHSTABEN erscheinen.

1. Zweck und Geltungsbereich

UIAP Authoring/Manifest Spec v0.1 definiert, wie UIAP-Artefakte für eine Anwendung strukturiert beschrieben, versioniert, zusammengesetzt, überprüft und veröffentlicht werden.

Die Spezifikation regelt insbesondere:

Paketstruktur und Paket-Metadaten
Manifest-Typen für App, Bindings, Actions, Policies, Workflows, Lokalisierung und Discovery-Import
Imports und Wiederverwendung
Overlays und Umgebungs-Overrides
Review- und Provenance-Modell
Versionierung und Kompatibilität
Build- und Release-Modell

Diese Spezifikation baut auf:

UIAP Core v0.1
UIAP Capability Model v0.1
UIAP Web Profile v0.1
UIAP Action Runtime Spec v0.1
UIAP Policy Extension v0.1
UIAP Workflow Extension v0.1
optional UIAP Discovery Mapper Spec v0.1

auf.

Sie definiert nicht den Wire-Transport zur Laufzeit, sondern die authoritative Quelle, aus der Runtime-Bundles und Releases gebaut werden.

2. Grundprinzipien

Authoring-Manifeste sind die Source of Truth für veröffentlichte UIAP-Pakete.
Discovery-Artefakte sind Input, aber nicht automatisch Wahrheit.
Overlays und Imports MÜSSEN deterministisch auflösbar sein.
Review-Status MUSS maschinenlesbar sein.
Build-Ausgaben MÜSSEN normalisiert und reproduzierbar sein.
Runtime soll keine losen Authoring-Dateien lesen, sondern kompilierte Bundles.
Semantik und IDs müssen stabil sein. Menschen lieben es, alles „später mal aufzuräumen“. Protokolle eher nicht.

3. Dokumentmodell

Authoring-Dokumente verwenden ein gemeinsames Hüllenformat.

interface UIAPAuthoringDocument<TSpec = unknown, TStatus = unknown> {
  apiVersion: "uiap.authoring/v0.1";
  kind: AuthoringKind;
  metadata: ManifestMetadata;
  spec: TSpec;
  status?: TStatus;
}

type AuthoringKind =
  | "Package"
  | "App"
  | "Capabilities"
  | "Bindings"
  | "Actions"
  | "PolicySet"
  | "WorkflowCatalog"
  | "LocalePack"
  | "Overlay"
  | "ReviewSet"
  | "DiscoveryImport";

3.1 Metadata

interface ManifestMetadata {
  id: string;                         // packageweit eindeutig
  title?: string;
  description?: string;

  version?: string;                   // optional für Teilmanifeste, Pflicht für Package
  packageId?: string;

  labels?: Record<string, string>;
  tags?: string[];

  owners?: OwnerRef[];
  source?: "manual" | "generated" | "mixed" | "imported";

  reviewState?:
    | "draft"
    | "generated"
    | "in_review"
    | "approved"
    | "rejected"
    | "deprecated";
}

interface OwnerRef {
  id: string;
  role?: "owner" | "maintainer" | "reviewer" | "approver";
  contact?: string;
}

Regeln

metadata.id MUSS innerhalb eines Pakets eindeutig sein.
Package-Manifeste MÜSSEN metadata.version setzen.
Teilmanifeste DÜRFEN metadata.version weglassen, wenn sie die Paketversion erben.
reviewState beschreibt den fachlichen Freigabestatus, nicht nur ob JSON syntaktisch hübsch aussieht.

4. Paketmodell

Ein UIAP-Paket ist die kleinste versionierte und veröffentlichbare Einheit.

4.1 Package Manifest

interface PackageManifest {
  packageId: string;
  version: string;                    // semver-like
  profile: string;                    // z. B. "[email protected]"

  compatibility: CompatibilitySpec;

  imports?: PackageImport[];
  manifests: LocalManifestRef[];

  build?: BuildSpec;
  publish?: PublishSpec;
}

interface CompatibilitySpec {
  uiapCore: string;                   // z. B. ">=0.1 <0.2"
  profiles: string[];                 // z. B. ["[email protected]"]

  extensions?: Array<{
    id: string;
    range: string;
    required?: boolean;
  }>;

  sdk?: {
    web?: string;
  };

  appVersions?: string[];             // semver-like ranges oder fixe Strings
}

interface PackageImport {
  packageId: string;
  versionRange: string;
  alias: string;

  include?: {
    kinds?: AuthoringKind[];
    manifestIds?: string[];
  };
}

interface LocalManifestRef {
  id: string;
  kind: Exclude<AuthoringKind, "Package">;
  path: string;
  required?: boolean;
}

Regeln

Ein Paket MUSS genau ein Package-Manifest haben.
Ein Paket MUSS genau ein App-Manifest liefern, direkt oder über Import plus Overlay.
Ein Paket DARF mehrere Bindings-, Actions-, PolicySet-, WorkflowCatalog- und LocalePack-Manifeste enthalten.
Importierte Manifest-IDs MÜSSEN über alias:id namespaced werden.
Lokale Manifest-IDs DÜRFEN nicht mit importierten vollqualifizierten IDs kollidieren.

5. Manifest-Typen

5.1 App Manifest

Das App-Manifest beschreibt die Zielanwendung als authoring-seitige Einheit.

interface AppManifest {
  appId: string;
  displayName: string;

  profile: string;                    // typischerweise "[email protected]"
  defaultLocale?: string;
  supportedLocales?: string[];

  environments?: AppEnvironment[];
  principalProfiles?: AppPrincipalProfile[];

  routing?: AppRoutingConfig;
  sdk?: AppSDKConfig;

  metadata?: Record<string, unknown>;
}

interface AppEnvironment {
  id: string;                         // z. B. "dev", "staging", "prod"
  baseUrls?: string[];
  labels?: Record<string, string>;
}

interface AppPrincipalProfile {
  id: string;                         // z. B. "workspace-admin"
  roles?: string[];
  grants?: string[];
  description?: string;
}

interface AppRoutingConfig {
  mode?: "history" | "hash" | "custom";
  routeProviderRef?: string;
}

interface AppSDKConfig {
  annotationPrefix?: string;          // RECOMMENDED: "data-uiap-"
  routeProviderRef?: string;
  overlayEnabled?: boolean;
}

5.2 Capabilities Manifest

Wrappt oder ergänzt das formale Capability Model.

interface CapabilitiesManifest {
  document: CapabilityDocument;
}

Regeln

Dieses Manifest KANN vollständig manuell gepflegt oder aus Actions/Bindings abgeleitet werden.
Build-Systeme SOLLTEN bei Konflikten zwischen Capabilities und Actions/Bindings einen Fehler oder mindestens eine Review-Warnung erzeugen.

5.3 Bindings Manifest

Beschreibt Routes, Scopes und Elemente in authoritativer Form.

interface BindingsManifest {
  routes?: RouteBinding[];
  scopes?: ScopeBinding[];
  elements?: ElementBinding[];
}

interface RouteBinding {
  id: string;
  match: RouteMatcher[];

  title?: AuthoredText;
  parentRouteId?: string;

  successSignals?: SuccessSignal[];
  metadata?: Record<string, unknown>;
}

type RouteMatcher =
  | { kind: "routeId"; value: string }
  | { kind: "path"; value: string }
  | { kind: "urlPattern"; value: string }
  | { kind: "title"; value: string }
  | { kind: "signal"; value: string };

interface ScopeBinding {
  id: string;
  kind: ScopeKind;

  routeIds?: string[];
  parentScopeId?: ScopeId;

  title?: AuthoredText;
  stableIds?: StableId[];
  metadata?: Record<string, unknown>;
}

interface ElementBinding {
  id: StableId;
  scopeId?: ScopeId;
  routeIds?: string[];

  role?: UIRole;
  name?: AuthoredText;
  meaning?: string;

  match: ElementMatcher[];

  risk?: RiskLevel;
  dataClasses?: DataClass[];

  defaultAction?: ActionId;
  success?: SuccessSignal[];

  metadata?: Record<string, unknown>;
}

type ElementMatcher =
  | { by: "annotation"; attr: string; value: string }
  | { by: "semantic"; role?: UIRole; name?: string; scopeId?: ScopeId }
  | { by: "label"; text: string }
  | { by: "text"; text: string }
  | { by: "adapter"; id: string }
  | { by: "runtimeHint"; css?: string; xpath?: string };

Regeln

annotation und semantic SOLLTEN gegenüber runtimeHint bevorzugt werden.
runtimeHint.css und runtimeHint.xpath DÜRFEN genutzt werden, SOLLTEN aber nicht die einzige robuste Identität kritischer Ziele sein.
ElementBinding.id MUSS stabil bleiben, auch wenn sich DOM-Strukturen ändern.

5.4 Actions Manifest

Beschreibt primitive und domänenspezifische Actions plus Implementierungsverweise.

interface ActionsManifest {
  actions: AuthoredAction[];
}

interface AuthoredAction extends ActionDescriptor {
  implementation?: ActionImplementationRef;
  selectors?: ManifestSelector[];
}

interface ActionImplementationRef {
  kind: "sdkHandler" | "serverAction" | "externalDriver" | "none";
  ref?: string;                       // z. B. "app.actions.createVideo"
}

Regeln

ActionDescriptor.id MUSS paketweit eindeutig sein.
Domänen-Actions SOLLTEN eine Implementierung referenzieren.
sdkHandler ist die bevorzugte Form für direkte App-Actions.
none ist nur zulässig für rein deklarative oder noch nicht implementierte Kandidaten mit entsprechendem Review-Status.

5.5 PolicySet Manifest

Beschreibt ein oder mehrere anwendbare Policy-Dokumente.

interface PolicySetManifest {
  policies: ScopedPolicyDocument[];
}

interface ScopedPolicyDocument {
  id: string;
  selector?: ManifestSelector;
  document: PolicyDocument;
}

Regeln

Mehrere Policies DÜRFEN koexistieren.
Selektoren bestimmen, wann sie aktiv sind.
Konflikte MÜSSEN deterministisch gelöst werden. Standardregel: strengere Policy gewinnt.

5.6 WorkflowCatalog Manifest

Beinhaltet versionierte Workflow-Definitionen.

interface WorkflowCatalogManifest {
  workflows: AuthoredWorkflow[];
}

interface AuthoredWorkflow {
  selector?: ManifestSelector;
  review?: WorkflowReviewHints;
  definition: WorkflowDefinition;
}

interface WorkflowReviewHints {
  level?: "draft" | "candidate" | "approved";
  highRisk?: boolean;
  generatedFromDiscovery?: boolean;
}

Regeln

Workflow-IDs MÜSSEN paketweit eindeutig sein.
Generated Workflows SOLLTEN nicht automatisch in produktive Kanäle gelangen, außer sie wurden reviewt oder per Waiver freigegeben.
Workflows DÜRFEN durch Overlays ergänzt oder eingeschränkt werden, aber nicht stillschweigend semantisch umgedeutet.

5.7 LocalePack Manifest

Definiert wiederverwendbare Texte.

interface LocalePackManifest {
  namespaces: Record<string, LocaleNamespace>;
}

interface LocaleNamespace {
  messages: Record<string, LocaleMessage>;
}

interface LocaleMessage {
  default: string;
  byLocale?: Record<string, string>;
}

Authoring-Text

Authoring-Quellen DÜRFEN statt LocalizedText auch Referenzen verwenden:

type AuthoredText =
  | LocalizedText
  | {
      ref: string;                    // z. B. "workflow.video.first.title"
      fallback?: string;
    };

Regeln

Build-Systeme MÜSSEN AuthoredText in normales LocalizedText oder String-Ausgabe auflösen.
Fehlende Locale-Keys SOLLTEN auf fallback oder defaultLocale zurückfallen.
Fehlende Pflichttexte MÜSSEN mindestens als Review-Warnung erscheinen.

5.8 Overlay Manifest

Erlaubt Umgebungs-, Tenant-, Kanal- oder Rollen-spezifische Änderungen.

interface OverlayManifest {
  selector: ManifestSelector;
  patches: ManifestPatch[];
}

interface ManifestSelector {
  environments?: string[];
  channels?: ReleaseChannel[];
  locales?: string[];
  tenantIds?: string[];
  principalProfiles?: string[];
  appVersionRanges?: string[];
}

type ManifestPatchOp =
  | "replace"
  | "merge"
  | "append"
  | "remove"
  | "upsert";

interface ManifestPatch {
  manifestId: string;                 // lokal oder alias:id
  path: string;                       // JSON Pointer
  op: ManifestPatchOp;

  matchKey?: string;                  // nur für upsert
  value?: unknown;
}

Patch-Semantik

replace: ersetzt Wert an path
merge: deep-merge für Objekte
append: hängt an Arrays an
remove: entfernt Ziel
upsert: fügt in Arrays von Objekten anhand matchKey ein oder aktualisiert

Regeln

Overlays MÜSSEN nach Imports und vor dem finalen Build angewendet werden.
Bei mehreren zutreffenden Overlays SOLLTE die Reihenfolge deterministisch sein, standardmäßig nach manifest-Reihenfolge im Paket.
Konflikte auf demselben Pfad MÜSSEN entweder deterministisch aufgelöst oder als Build-Fehler markiert werden. Heimliches Überschreiben ist die Art „Feature“, die später Monate kostet.

5.9 ReviewSet Manifest

Trägt Review-Entscheidungen, Waiver und Freigaben.

interface ReviewSetManifest {
  decisions: ReviewDecision[];
  waivers?: ReviewWaiver[];
}

interface ReviewDecision {
  target: ReviewTarget;
  state: "approved" | "rejected" | "needs_review";
  by: string;
  at: string;
  comment?: string;
}

interface ReviewWaiver {
  target: ReviewTarget;
  reason: string;
  by: string;
  at: string;
  expiresAt?: string;
}

interface ReviewTarget {
  manifestId: string;
  path?: string;
  itemId?: string;
}

Regeln

ReviewSet verändert keine fachlichen Inhalte, sondern nur den Freigabestatus.
Abgelaufene Waiver DÜRFEN nicht für Produktiv-Releases zählen.
Build-Pipelines SOLLTEN Review-Gates aus ReviewSet und PublishSpec gemeinsam auswerten.

5.10 DiscoveryImport Manifest

Bringt Discovery-Ergebnisse kontrolliert ins Authoring.

interface DiscoveryImportManifest {
  source: {
    runId?: string;
    ref?: string;                     // Dateipfad, URI oder Paketref
  };

  accept: DiscoveryAcceptanceRule[];
  reject?: DiscoveryRejectionRule[];
}

interface DiscoveryAcceptanceRule {
  kind:
    | "route"
    | "scope"
    | "element"
    | "action"
    | "workflowCandidate"
    | "reviewItem";

  ids?: string[];
  targetManifestId: string;
  mode?: "copy" | "promote" | "link";
}

interface DiscoveryRejectionRule {
  kind:
    | "route"
    | "scope"
    | "element"
    | "action"
    | "workflowCandidate"
    | "reviewItem";

  ids?: string[];
  reason?: string;
}

Regeln

Discovery-Importe MÜSSEN explizit sein.
Discovery-Artefakte DÜRFEN nicht automatisch ohne Acceptance-Regeln produktiv werden.
promote bedeutet: Discovery-Inhalt wird in ein authoritatives Manifest überführt.
link bedeutet: Discovery bleibt Beleg, nicht Quelle.

6. Imports und Auflösung

6.1 Import-ID-Raum

Importierte Manifeste werden im Build mit Alias namespaced:

<alias>:<manifestId>

Beispiel:

base:actions.core
shared:workflow.onboarding.common

6.2 Import-Regeln

alias MUSS innerhalb des Pakets eindeutig sein.
Importierte Manifeste DÜRFEN nur über vollqualifizierte IDs referenziert werden.
Lokale Manifeste DÜRFEN importierte Inhalte nicht implizit überschreiben.
Änderungen an importierten Manifesten erfolgen nur über Overlay oder bewusstes Forken.

7. Merge- und Build-Semantik

Ein Build MUSS diese Schritte in genau dieser Reihenfolge behandeln:

Paket laden
Imports auflösen
lokale Manifeste laden
Discovery-Importe anwenden
Overlays anwenden
Locale-Referenzen auflösen
Review-Status anwenden
Referenzen validieren
Normalisiertes Bundle erzeugen
Publish-Gates prüfen

7.1 Kind-spezifische Merge-Regeln

App

genau ein effektives App-Dokument nach Merge

Capabilities

Objekte deep-mergen
Listen nach stabiler Identität deduplizieren

Bindings

routes, scopes, elements nach id bzw. stableId mergen
Konflikte in match-Definitionen SOLLTEN reviewpflichtig sein

Actions

nach action.id mergen
inkompatible Implementierungsrefs MÜSSEN Fehler oder Review-Warnung erzeugen

PolicySet

Policies zusammenführen
Selektion und Priorisierung bleiben Policy-Sache

WorkflowCatalog

nach definition.id mergen
gleiche ID + andere Struktur = Konflikt, außer Overlay regelt es explizit

LocalePack

nach namespace + message key + locale mergen

ReviewSet

Entscheidungen auf Ziele anwenden
spätere Entscheidungen KÖNNEN frühere überschreiben, SOLLTEN aber auditiert werden

8. Build-Kontext

interface BuildContext {
  environment?: string;
  channel?: ReleaseChannel;
  locale?: string;
  tenantId?: string;
  principalProfile?: string;
  appVersion?: string;
}

Ein Build MUSS immer gegen einen expliziten oder impliziten Kontext aufgelöst werden.

9. Publish- und Release-Modell

type ReleaseChannel =
  | "dev"
  | "staging"
  | "canary"
  | "prod"
  | "deprecated";

interface PublishSpec {
  defaultChannel?: ReleaseChannel;
  channels: ReleaseChannelSpec[];
}

interface ReleaseChannelSpec {
  name: ReleaseChannel;

  selectors?: ManifestSelector[];
  requiredReviewState?: "approved" | "in_review" | "draft";
  allowWaivers?: boolean;

  forbidGeneratedOnly?: boolean;
  requireDigest?: boolean;
}

Regeln

prod SOLLTE requiredReviewState = "approved" verlangen.
prod SOLLTE forbidGeneratedOnly = true verwenden.
canary und staging DÜRFEN lockerere Review-Gates haben.
Publish-Spezifikation MUSS vor Bundle-Ausgabe geprüft werden.

10. Provenance und Status

status ist optional, aber für echte Teams praktisch unvermeidlich.

interface ManifestStatus {
  provenance?: ProvenanceRecord[];
  warnings?: string[];
  digest?: string;
}

interface ProvenanceRecord {
  source: "manual" | "discovery" | "import" | "generated" | "runtime-trace";
  ref?: string;
  note?: string;
  at?: string;
}

Regeln

Authoritative Inhalte SOLLTEN Provenance enthalten.
Discovery-basierte Felder SOLLTEN nachvollziehbar auf Run, Evidence oder Import verweisen.
Build-Systeme SOLLTEN aus Provenance Review-Pflichten ableiten können.

11. Versionierung

11.1 Paketversion

Package.spec.version MUSS semver-artig sein.

11.2 Breaking Change

Ein Major-Bump SOLLTE erfolgen, wenn:

IDs inkompatibel geändert werden
Workflow- oder Action-Semantik inkompatibel wird
Policy-Verhalten strenger oder schwächer mit relevanter Laufzeitwirkung geändert wird
App- oder Profilkompatibilität bricht

11.3 Minor Change

Ein Minor-Bump SOLLTE erfolgen, wenn:

neue Workflows, Bindings, Actions oder Policies additiv hinzukommen
neue Lokalisierungen ergänzt werden
Overlays additiv erweitert werden

11.4 Patch Change

Ein Patch SOLLTE erfolgen, wenn:

nur Texte, Review-Metadaten oder harmlose Korrekturen angepasst werden
keine Wire- oder Laufzeitsemantik relevant geändert wird

12. Normalisiertes Build-Output

Runtime und SDK SOLLTEN ein kompiliertes Bundle konsumieren.

interface UIAPCompiledBundle {
  packageId: string;
  version: string;
  profile: string;

  buildContext: BuildContext;
  compatibility: CompatibilitySpec;

  app: AppManifest["spec"];
  capabilities?: CapabilityDocument;
  bindings?: BindingsManifest["spec"];
  actions?: AuthoredAction[];
  policies?: ScopedPolicyDocument[];
  workflows?: WorkflowDefinition[];
  locales?: Record<string, string>;

  manifestIndex?: string[];
  digest?: string;
}

Regeln

Das Bundle MUSS frei von nicht aufgelösten Importen und Overlays sein.
Locale-Referenzen MÜSSEN aufgelöst sein.
Nur für den Build-Kontext gültige Inhalte DÜRFEN enthalten sein.
Review-Gates MÜSSEN vor Bundle-Erstellung oder spätestens vor Publish bestanden sein.

13. Minimale Konformität

Eine konforme uiap.authoring/v0.1-Implementierung MUSS:

das gemeinsame Dokumentmodell unterstützen
Package, App, Bindings, Actions, PolicySet, WorkflowCatalog, Overlay und ReviewSet verstehen
Imports und Overlays deterministisch auflösen
IDs validieren
ein normalisiertes Bundle erzeugen können
Review-Gates auswerten können

Sie SOLLTE zusätzlich:

Capabilities und LocalePack unterstützen
DiscoveryImport unterstützen
Provenance speichern
Build-Digests erzeugen
Publish-Channels unterstützen

14. Empfohlene Verzeichnisstruktur

uiap/
  package.uiap.yaml
  app.uiap.yaml

  capabilities/
    core.uiap.yaml

  bindings/
    routes.uiap.yaml
    elements.uiap.yaml

  actions/
    core.uiap.yaml
    billing.uiap.yaml

  policies/
    default.uiap.yaml
    admin.uiap.yaml

  workflows/
    onboarding.uiap.yaml
    support.uiap.yaml

  locales/
    common.uiap.yaml

  overlays/
    staging.uiap.yaml
    prod.uiap.yaml
    tenant-acme.uiap.yaml

  reviews/
    approvals.uiap.yaml

  discovery/
    staging-admin.discovery.json
    promoted.uiap.yaml

15. Referenzbeispiel

15.1 Package Manifest

apiVersion: uiap.authoring/v0.1
kind: Package
metadata:
  id: package.videoland
  version: 0.1.0
  title: Videoland UIAP Pack
  reviewState: approved
spec:
  packageId: videoland.uiap
  version: 0.1.0
  profile: [email protected]

  compatibility:
    uiapCore: ">=0.1 <0.2"
    profiles: ["[email protected]"]
    extensions:
      - id: uiap.policy
        range: ">=0.1 <0.2"
        required: true
      - id: uiap.workflow
        range: ">=0.1 <0.2"
        required: true
    sdk:
      web: ">=0.1 <0.2"

  imports:
    - packageId: uiap.shared.base
      versionRange: "^0.1.0"
      alias: base

  manifests:
    - id: app.core
      kind: App
      path: app.uiap.yaml

    - id: bindings.routes
      kind: Bindings
      path: bindings/routes.uiap.yaml

    - id: bindings.elements
      kind: Bindings
      path: bindings/elements.uiap.yaml

    - id: actions.core
      kind: Actions
      path: actions/core.uiap.yaml

    - id: policies.default
      kind: PolicySet
      path: policies/default.uiap.yaml

    - id: workflows.onboarding
      kind: WorkflowCatalog
      path: workflows/onboarding.uiap.yaml

    - id: locales.common
      kind: LocalePack
      path: locales/common.uiap.yaml

    - id: overlays.prod
      kind: Overlay
      path: overlays/prod.uiap.yaml

    - id: reviews.approvals
      kind: ReviewSet
      path: reviews/approvals.uiap.yaml

  publish:
    defaultChannel: staging
    channels:
      - name: staging
        requiredReviewState: in_review
        allowWaivers: true
      - name: prod
        requiredReviewState: approved
        allowWaivers: false
        forbidGeneratedOnly: true
        requireDigest: true

15.2 Workflow Catalog Manifest

apiVersion: uiap.authoring/v0.1
kind: WorkflowCatalog
metadata:
  id: workflows.onboarding
  title: Onboarding Workflows
  source: mixed
  reviewState: in_review
spec:
  workflows:
    - review:
        level: approved
        highRisk: false
      definition:
        id: video.create_first_video
        version: 0.1.0
        title:
          ref: workflow.video.first.title
          fallback: Erstes Video erstellen
        category: onboarding
        startMode: suggested
        interactionModes: [guide, assist, auto]
        initialStepId: intro
        steps:
          - id: intro
            type: instruction
            text:
              ref: workflow.video.first.intro
              fallback: Ich helfe dir beim ersten Video.
            next: done

          - id: done
            type: complete

15.3 Overlay Manifest

apiVersion: uiap.authoring/v0.1
kind: Overlay
metadata:
  id: overlays.prod
  reviewState: approved
spec:
  selector:
    channels: [prod]
  patches:
    - manifestId: policies.default
      path: /spec/policies/0/document/defaults/onUnknownAction
      op: replace
      value: deny

    - manifestId: workflows.onboarding
      path: /spec/workflows
      op: upsert
      matchKey: definition.id
      value:
        review:
          level: approved
        definition:
          id: video.create_first_video
          version: 0.1.1
          title:
            default: Erstes Video erstellen
          category: onboarding
          startMode: suggested
          interactionModes: [guide, assist]
          initialStepId: intro
          steps:
            - id: intro
              type: instruction
              text: Ich helfe dir beim ersten Video.
              next: done
            - id: done
              type: complete

15.4 ReviewSet Manifest

apiVersion: uiap.authoring/v0.1
kind: ReviewSet
metadata:
  id: reviews.approvals
  reviewState: approved
spec:
  decisions:
    - target:
        manifestId: workflows.onboarding
        itemId: video.create_first_video
      state: approved
      by: patrick
      at: "2026-03-26T17:00:00Z"
      comment: Freigegeben für Staging und Prod.

  waivers: []

16. Was danach als nächstes fehlt

Nach diesem Spec ist der nächste logische Baustein ganz klar UIAP Conformance Suite v0.1. Jetzt gibt es nämlich endlich etwas, das man überhaupt konsistent testen kann: Manifest-Validierung, Import-Auflösung, Overlay-Konflikte, Review-Gates, Bundle-Kompilierung und die schöne Frage, ob jemand „UIAP-kompatibel” ist oder nur besonders überzeugt davon.

Normative Referenzen

[UIAP-CORE] UIAP Core v0.1
[UIAP-CAP] UIAP Capability Model v0.1
[UIAP-WEB] UIAP Web Profile v0.1
[UIAP-ACTION] UIAP Action Runtime v0.1
[UIAP-POLICY] UIAP Policy Extension v0.1
[UIAP-WORKFLOW] UIAP Workflow Extension v0.1
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels, BCP 14

Security Considerations

Manifest-Dateien KÖNNEN Credentials-Locations oder API-Endpunkte referenzieren; sie SOLLTEN nicht in öffentlichen Repositories ohne Redaktion committed werden.
Schema-Validierung MUSS vor dem Laden von Manifesten durchgeführt werden, um Injection-Angriffe über manipulierte YAML/JSON-Dateien zu verhindern.
Authoring-Tools SOLLTEN nur mit minimalen Berechtigungen auf die Zielanwendung zugreifen.

Changelog

Version	Datum	Änderungen
0.1	2026-03-27	Initialer Entwurf