YAML_RULES.md¶

🎯 Objectif¶

Ce fichier documente les règles de validation et la structure attendue des fichiers YAML de workflow utilisés dans la plateforme MFO. Il constitue la source de vérité pour l’assistant GPT générant ces workflows, en complément du SYSTEM PROMPT.

✅ Règles de validation¶

1. workflows[].input_mapping¶

• Doit référencer uniquement des clés définies dans schemas[].properties ou dans TRIGGER.payload.xxx
• Syntaxe obligatoire : TRIGGER.payload.xxx

2. triggers[]¶

• Champs obligatoires :
• id (unique)
• type ∈ {webhook, schedule, manual}
• enabled: booléen
• config: dépend du type
• target_taskflow: doit correspondre à un taskflow_id existant
• Si type == webhook :
• config doit contenir http_path et http_method
• input_mapping doit suivre TRIGGER.payload.xxx
• Si type == schedule :
• config.cron_expression est requis

3. taskflows[]¶

• Champs obligatoires :
• taskflow_id : identifiant unique
• description : description concise du but métier de ce taskflow
• tasks[] : liste de tâches conformes aux règles ci-dessous

4. taskflows[].tasks[]¶

Chaque tâche doit avoir :

5. Types de tâches autorisés (type)¶

• mfo_api_tool_execute
• mfo_api_chat_send
• mfo_api_resource_get
• mfo_api_memory_get
• mfo_api_memory_store

6. error_handling.on_error[]¶

• Type attendu : liste d’objets avec :
• type: retry_with_prompt, fail_fast, etc.
• max_retries si retry_with_prompt
• append_to_system_prompt si applicable
• error_message pour fail_fast

7. validation[] (si LLM)¶

• Règles LLM à appliquer à la sortie :
• type: require_tool_call
• tool_name: nom du tool attendu
• error_message: message en cas d’échec

8. Consistance entre blocs¶

• Chaque target_taskflow référencé dans un trigger doit exister
• Chaque variable INPUT.xxx ou task_id.result.xxx utilisée doit être définie en amont
• Dépendances implicites entre tâches doivent respecter l’ordre d’apparition

📦 Structure type d’un fichier workflow.yml¶

workflow_name: "ExampleWorkflow"
version: "1.0"

workflows:
  - id: "my_workflow"
    taskflow_id: "main_taskflow"
    description: "short description of the taskflow"
    input_mapping:
      email_id: "TRIGGER.payload.email_id"
    triggers:
      - id: "trigger_email"
        type: "webhook"
        enabled: true
        config:
          http_path: "/webhook/email"
          http_method: "POST"
        input_mapping:
          email_id: "TRIGGER.payload.email_id"
        target_taskflow: "main_taskflow"

schemas:
  - name: MyPayload
    type: object
    properties:
      email_id:
        type: string


taskflows:
  - taskflow_id: "main_taskflow"
    description: "short description of the taskflow"
    tasks:
      - id: "fetch_email"
        description: "short description of the task"
        type: "mfo_api_tool_execute"
        config:
          tool_id: "unipile_email_fetch"
          arguments:
            email_id: "INPUT.email_id"

      - id: "analyze_email"
        description: "short description of the task"
        type: "mfo_api_chat_send"
        config:
          prompt_template_id: "email_analysis"
          prompt_context:
            content: "fetch_email.result.content"
        error_handling:
          on_error:
            - type: retry_with_prompt
              append_to_system_prompt: "retry analysis"
              max_retries: 2

🔁 À valider automatiquement côté assistant¶

• Chaque taskflow_id référencé doit exister
• Les INPUT.xxx doivent venir soit du input_mapping, soit d’un TRIGGER.payload.xxx
• Les task_id.result.xxx doivent référencer des tâches antérieures dans le même taskflow
• Chaque task et taskflow doit comporter un champ description clair