Predefined Pipe Concepts

Vordefinierte Pipe-Konzepte

:::caution Exploratory design Diese Seite dokumentiert einen explorativen Designansatz für vordefinierte Pipes. Die Funktion ist noch nicht in Produktionsversionen verfügbar, und die hier beschriebenen Konzepte können sich während der Validierung des Ansatzes mit internen Prototypen noch deutlich ändern. :::

Dieses Dokument fasst frühe Ideen für die Bereitstellung wiederverwendbarer, vordefinierte Pipes zusammen, die in projektbezogene YAML-Pipelines importiert werden können.

Aktueller Status

Vordefinierte Pipes befinden sich in der Erkundungsphase, mit nur YAML-Prototypen für interne Reviews. Es gibt keine Runtime-Unterstützung im Engine, und der Katalog wurde nicht veröffentlicht. Engineering validiert die Import-Mechanik, Dependency-Handling und Packaging-Flows, bevor ein Implementierungszeitplan festgelegt wird. Der aktuelle Fokus liegt auf der Umsetzung des Loaders, der Kompatibilitätstests und der Entwickler-Tools, die unten beschrieben sind, gefolgt von iterativen Pilotprogrammen mit einer kleinen Gruppe von Design-Partners.

Ziele

Bereitstellung eines Katalogs mit austauschbaren Automatisierungs-Patterns für Support-Workflows.
Teams ermöglichen, komplexe Automatisierungen durch Import einer einzelnen Datei zu komponieren.
Die vordefinierte Pipes kompatibel mit der bestehenden Execution Engine halten, sodass ein importiertes YAML ohne zusätzliche Verknüpfungen ausgeführt werden kann.

Design-Prinzipien

Single-file portability – Jede vordefinierte Pipe liegt in einer eigenen YAML-Datei mit allen benötigten Steps und Metadaten. Der Import der Datei sollte die Pipe direkt ausführbar machen.
Declarative parameters – Pipes stellen einen parameters Block bereit, in dem downstream YAMLs Defaults überschreiben können, ohne die gemeinsame Datei zu editieren.
Idempotent steps – Jede Pipe sollte sicher sein, sie mehrfach auszuführen.
Observability hooks – Standard-Annotationen für Logging, Metrics und Alerting, sodass importierte Pipes sauber mit Monitoring integrieren.

YAML-Struktur Prototyp

# file: pipes/triage-basic.yaml
pipe:
  name: triage-basic
  version: 0.1.0
  description: >-
    Basic triage workflow that classifies an incoming ticket, enriches context,
    and queues follow-up actions.

  parameters:
    classification_model: clf-ticket-small
    notification_channel: slack://#support-triage
    sla_minutes: 30

  steps:
    - id: normalize
      uses: actions/normalize-text@v1
      with:
        fields: [title, description]

    - id: classify
      uses: actions/classify@v2
      with:
        model: '${{ parameters.classification_model }}'
        input: ${{ steps.normalize.output.cleaned_text }}

    - id: sla_guard
      uses: actions/sla-reminder@v1
      when: ${{ ticket.created_at + parameters.sla_minutes < now() }}
      with:
        channel: '${{ parameters.notification_channel }}'
        message: 'SLA threshold reached for ticket ${{ ticket.id }}'

  outputs:
    classification: ${{ steps.classify.output.label }}
    confidence: ${{ steps.classify.output.confidence }}

Import Pattern

Das Team-Level YAML referenziert einfach die vordefinierte Pipe und überschreibt optional Parameter:

imports:
  - from: pipes/triage-basic.yaml
    as: triage-basic

pipe:
  name: support-intake
  steps:
    - uses: triage-basic
      with:
        classification_model: clf-ticket-enterprise
        notification_channel: slack://#support-critical

Katalog-Ideen

Pipe Name	Problem Solved	Key Steps	Notes
`triage-basic`	Classify and enqueue new tickets	normalization → classification → SLA reminder	Baseline for all teams
`triage-advanced`	Multi-language classification with translation fallback	language detection → translation → classification → routing	Requires translation credits
`auto-escalate`	Escalate urgent tickets	severity detection → senior engineer notification → incident logging	Integrates with on-call schedules
`knowledge-base-suggest`	Suggest KB articles to agents	vector embed → similarity search → suggestion post	Consumes search API quota
`customer-sentiment-monitor`	Track sentiment drift over conversation lifetime	conversation aggregation → sentiment scoring → trend alerting	Works best with hourly cron
`bug-report-digest`	Aggregate bug-related tickets	label filter → deduplicate → weekly digest email	Ties into product board

Validierungs Checkliste

Vor der Veröffentlichung einer vordefinierten Pipe:

Schema mit python -m open_ticket.pipeline validate pipes/<pipe-name>.yaml verifizieren.
Integrationstests mit staging data ausführen.
Dokumentation der benötigten Secrets, externen Services und Quotas.
Pipe Release im Katalog Repository taggen.

Next Steps

Build a lightweight loader that merges imported parameters into the active pipeline context and validates dependencies.
Create automated smoke and contract tests to ensure imported pipes remain compatible across version bumps.
Prototype a CLI command ot pipe add triage-basic that fetches and verifies the YAML before adding it to a project repository.
Evaluate hosting the catalog in a Git-based registry for versioned distribution and controlled pilot access.