11 Commits

Author	SHA1	Message	Date
Lars	5fa2ea2e6b	feat: Show node.name from workflow editor in debug panel ... - Add name field to WorkflowNode model - Add node_name field to NodeExecutionState - Set node_name in execute_workflow from node.name - Display priority: node_name > debug_prompt_slug > node_label > node_id User sees 'Qualitätseinschätzung' instead of 'node_abc123'	2026-04-13 15:43:42 +02:00
Lars	12d4d7c63b	feat: Add comprehensive debug information for workflow nodes ... Backend changes: - workflow_models.py: Add debug_prompt, debug_raw_response, debug_node_type, debug_prompt_slug, metadata fields to NodeExecutionState - workflow_executor.py: Capture and store debug info for analysis, logic, and join nodes when enable_debug=True - Analysis nodes: store full prompt + raw AI response - Logic nodes: store expression + evaluation result - Join nodes: store strategy + path statistics Frontend changes: - Analysis.jsx: Enable debug mode by default (debug=true) for all workflow executions This allows developers to see exactly what prompt was sent to the AI, what response was received, and how each node was processed - essential for debugging workflow issues.	2026-04-13 12:38:55 +02:00
Lars	057df0afc8	fix: Support UI-format edge routing with sourceHandle ... Logic-Nodes evaluated correctly but activated_edges was empty because _get_edges_by_label() only checked e.label, which is null in UI format. UI format uses: - sourceHandle: "true" / "false" (instead of label: "then" / "else") - targetHandle: "in" / "path_1" / etc. Changes: 1. Added source_handle/target_handle fields to WorkflowEdge model - With aliases sourceHandle/targetHandle for camelCase JSON 2. Updated _get_edges_by_label() to check both formats: - Legacy: e.label == "then" / "else" - UI: e.source_handle == "true" / "false" Now Logic-Nodes correctly activate outgoing edges → Join-Node receives completed paths → End-Node executes → Workflow completes! Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-04-13 09:07:50 +02:00
Lars	ba04e0c0b6	fix: Add extra='forbid' to Condition for proper Union resolution ... Critical fix: Without extra='forbid', Pydantic accepted UI format {operator: "and", operands: [...]} as valid Condition by ignoring unknown fields, resulting in Condition(expression=None). With extra='forbid': - Condition rejects unknown fields → fails - Union tries next type → LogicExpression → success Test Results (9/9 passed): - Simple comparisons (eq, neq, gt, lt, in) ✅ - AND/OR combinations ✅ - Deep nesting (3+ levels) ✅ - NOT operator ✅ - All operators (eq, neq, in, not_in, gt, lt, gte, lte, and, or, not) ✅ - Legacy format (Condition wrapper) ✅ - Complex real-world scenarios ✅ Added comprehensive test suite in: - test_condition_parsing.py (9 test cases) - test_condition_union.py (Union resolution verification) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-04-13 09:01:53 +02:00
Lars	f5ce1ec941	refactor: Proper type-safe condition handling with Union types ... Previous fix used Any type, breaking type safety and only handling simple cases. This is the correct implementation: Changes: 1. LogicExpression.operands: List[Any] → List['LogicExpression'] - Enables recursive/nested expressions - Proper type checking for all operator combinations 2. WorkflowNode.condition: Any → Union[LogicExpression, Condition] - Type-safe deserialization - Supports both UI format (direct LogicExpression) and legacy (Condition wrapper) - Pydantic automatically tries LogicExpression first, then Condition 3. Executor: Simplified with isinstance() checks - Clean type detection without dict manipulation - Fallback for edge cases This now correctly handles: - Simple conditions: {operator: "eq", ref: "...", value: "..."} - Combined: {operator: "and", operands: [...]} - Nested: {operator: "or", operands: [{operator: "and", ...}, ...]} - All operators: eq, neq, in, not_in, gt, lt, gte, lte, contains, and, or, not - Legacy format: {expression: {...}, then_path: "...", else_path: "..."} Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-04-13 08:45:55 +02:00
Lars	2deb6510f8	fix: Support UI-format LogicExpression in Logic-Node condition field ... Root cause: UI saves LogicExpression directly as condition: {operands: [...], operator: "and"} But Pydantic model expected Condition with wrapped expression: {expression: {operands: [...], operator: "and"}} Result: Pydantic deserialized it as Condition with expression=None → Logic-Nodes failed with "'NoneType' object has no attribute 'operator'" Fix: 1. Changed WorkflowNode.condition type from Condition to Any 2. Executor now handles both dict and Pydantic model formats 3. Detects UI format (operator+operands) vs legacy format (expression wrapper) 4. Converts dict to LogicExpression before evaluation Fixes: Logic-Node execution failures in Training-Tiefenanalyse workflow Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-04-13 08:40:43 +02:00
Lars	a1723db387	feat: Workflow Engine Part 3 - Inline Prompts (v0.9q) ... Ermöglicht Analysis Nodes zwischen zwei Prompt-Modi zu wählen: - Reference Mode: Basis-Prompt aus DB referenzieren (bestehend) - Inline Mode: Template direkt im Node editieren (NEU) Frontend: - InlineTemplateEditor Component (~80 Zeilen) - Radio Buttons in WorkflowEditorPage für Mode-Auswahl - Placeholder Picker für beide Modi (End Node + Inline Template) - Cursor-Position Tracking mit textareaRef - Conditional Rendering basierend auf promptSource - Validation: Entweder prompt_slug ODER inline_template Backend: - load_prompt_template() akzeptiert ganzen WorkflowNode (statt nur slug) - Unterstützt inline_template (Mode 1) und prompt_slug (Mode 2) - WorkflowNode.inline_template Feld hinzugefügt - Validation: HTTPException wenn weder slug noch template Serialization: - inline_template in graph_data speichern/laden - Backward-compatible mit bestehenden Workflows Version: 0.9q Module: workflow 0.7.0 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-04-11 08:45:00 +02:00
Lars	b888f5d3c8	feat: Phase 4 - End Node Template Engine (v0.9n) ... Backend: - workflow_models.py: EndNodeOutputMode enum (AUTO, TEMPLATE) - workflow_executor.py: execute_end_node() with Jinja2 rendering - Template Context: {{node_id.analysis_core}}, {{node_id.decision_signals.key}} - Conditional Rendering: {% if node_id %} for optional paths - AUTO Mode: Backward compatible (concatenates all analyses) - TEMPLATE Mode: Custom Jinja2 templates with placeholders Features: - Access node results: {{node_id.analysis_core}} - Access signals: {{node_id.decision_signals.relevanz}} - Optional paths: {% if node_id %}...{% endif %} - Default values: {{node_id|default("N/A")}} Version: 0.9n Module: workflow 0.6.0 Konzept: konzept_workflow_engine_konsolidated.md (Section 11) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-04-05 07:07:49 +02:00
Lars	2ce0874dcb	feat: Phase 3 - Logic Nodes + Conditional Branching ... Backend: - logic_evaluator.py (NEU, 307 Zeilen): Deterministischer Logic Evaluator - Vergleichsoperatoren: EQ, NEQ, IN, NOT_IN, GT, LT, GTE, LTE, CONTAINS - Logische Operatoren: AND, OR, NOT mit Verschachtelung - Resolve signal references (node_id.question_type) - Error handling für UNCLEAR/INVALID/NOT_DECIDABLE Signale - workflow_executor.py (ERWEITERT): - execute_logic_node(): Bedingungen evaluieren, Pfade aktivieren/deaktivieren - execute_workflow(): BFS-Traversierung mit Edge-Activation statt Sequential - _apply_fallback(): 4 Fallback-Strategien (CONSERVATIVE_SKIP, DEFAULT_PATH, UNCERTAINTY_PATH, DOCUMENT_ONLY) - _has_active_incoming_edge(): Prüft ob Node erreichbar ist - _get_edges_by_label(): Findet then/else/uncertainty Pfade - workflow_models.py (ERWEITERT): - LogicOperator.CONTAINS hinzugefügt - version.py: 0.9k → 0.9l, workflow 0.3.0 → 0.4.0 Tests: - test_phase3_logic_evaluator.py (NEU): 20 Unit Tests (alle passing) - Comparison operators (EQ, NEQ, IN, GT, LT, CONTAINS) - Logical operators (AND, OR, NOT) - Nested expressions - Error handling (missing refs, UNCLEAR/INVALID signals) - test_phase2_workflow_executor.py (AKTUALISIERT): 11 Tests (alle passing) - execute_node() graph parameter hinzugefügt (Phase 3 requirement) - test_execute_node_unknown_type: logic → join (logic jetzt implementiert) - test_phase3_workflow_branching.py (NEU): Integration Tests vorbereitet - Erfordert vollständige DB-Mock-Strategie (wird in E2E-Test nachgeholt) Phase 2 Backward Compatibility: ✅ Alle Phase 2 Tests bestehen weiterhin Konzept: .claude/task/Workflow_engine_prompting_engine/konzept_workflow_engine_konsolidated.md Anforderungsanalyse: .claude/task/Workflow_engine_prompting_engine/phase3_anforderungsanalyse.md Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-04-04 08:02:22 +02:00
Lars	1f8791f4dd	feat: Phase 2 - Normalisierung + Workflow Executor ... Backend: - normalization_engine.py (200 Zeilen): Synonym-Mapping, 5 Statuswerte * normalize_decision_signal(): Kaskade (exact → case → synonym → invalid) * apply_synonym_mapping(): DB-basierte Synonyme (case-insensitive) * normalize_all_signals(): Batch-Processing gegen Katalog * load_question_catalog(): Lädt normalization_rules aus DB - workflow_executor.py (440 Zeilen): Sequenzielle Workflow-Ausführung * execute_workflow(): Traversiert DAG in topologischer Reihenfolge * execute_node(): Führt analysis nodes aus (start/end = no-op) * aggregate_results(): Kombiniert analysis_core + normalized_signals * save_execution_state(): Persistiert in workflow_executions - workflow_models.py: Erweitert um Phase 2 Models * SignalStatus Enum (valid, normalized, unclear, invalid, not_decidable) * NormalizedSignal (question_type, raw_value, normalized_value, status) * NodeExecutionState (node_id, status, analysis_core, normalized_signals) * ExecutionResult (execution_id, workflow_id, status, node_states, aggregated_result) - workflow_engine.py: Neue Funktion get_execution_order() * Flattened topological sort für sequenzielle Execution * Phase 7: Wird zu levels (parallele Execution) - prompt_executor.py: execute_workflow_prompt() Implementierung * Ruft workflow_executor.execute_workflow() auf * Konvertiert ExecutionResult zu API-Response - routers/workflows.py (230 Zeilen): Workflow Execution API * POST /api/workflows/{id}/execute (mit enable_debug) * GET /api/workflows/executions/{id} (lädt gespeicherten State) * GET /api/workflows (listet alle aktiven Workflows) * GET /api/workflows/{id} (lädt einzelnen Workflow mit Graph) - main.py: Router-Registrierung (workflows.router) Tests: - test_phase2_normalization.py (17 Tests): Alle Normalisierungs-Szenarien * Exact match, case-insensitive, synonym mapping, invalid, whitespace * Batch-Normalisierung, not_in_catalog, mixed validity - test_phase2_workflow_executor.py (10 Tests): Executor + Aggregation * aggregate_results mit verschiedenen Konstellationen * execute_node für start/end/analysis/unknown * Integration mit question_augmenter + result_container_parser Alle 27 Unit-Tests bestanden. version: 0.9k (backend) module: workflow 0.3.0 Konzept: .claude/task/Workflow_engine_prompting_engine/anforderungsanalyse_umsetzungsplan.md (Phase 2)	2026-04-03 21:20:23 +02:00
Lars	b5be6e21a5	feat: Phase 0 - Workflow Engine Foundation ... Backend: - DB-Migration 034: workflow_definitions, workflow_question_catalog, workflow_executions - ai_prompts.question_augmentations JSONB-Spalte (Hybridmodell: Prompt-Defaults) - 6 Grundtypen Fragenergänzungen mit Normalisierungsregeln (Seed-Daten) - Pydantic-Modelle (16 Models, 11 Enums) in workflow_models.py - Workflow-Engine: Graph-Parsing, Topologische Sortierung, DAG-Validierung - Dispatcher-Erweiterung type='workflow' (Stub für Phase 1-3) - Adjacency Lists, Erreichbarkeits-Prüfungen, Zyklen-Erkennung Testing: - 22 Unit-Tests (alle bestanden): Graph-Parsing, Validierung, Topologische Sortierung - Fixtures: simple_valid_graph, parallel_graph, branching_graph Version: - APP_VERSION 0.9i - DB_SCHEMA_VERSION 20260403 - Module: workflow 0.1.0 Anforderungsanalyse: .claude/task/Workflow_engine_prompting_engine/anforderungsanalyse_umsetzungsplan.md Konzept-Basis: .claude/task/Workflow_engine_prompting_engine/konzept_workflow_engine_konsolidated.md Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-04-03 16:55:51 +02:00