prepare_input_collection_overview

INPUT COLLECTION OVERVIEW & RULE CREATION

Prepare and present input collection overview before starting any input collection.

MANDATORY FIRST STEP - INPUT OVERVIEW PROCESS (Enhanced): This tool MUST be called before collecting any inputs. It analyzes all selected tasks and presents a complete overview of what inputs will be needed.

ENHANCED WITH AUTOMATIC RULE CREATION: After user confirms the input overview, this tool automatically creates the initial rule structure with selected tasks. The rule will be saved with DRAFT status and can be progressively updated as inputs are collected.

MANDATORY WORKFLOW ENFORCEMENT - CRITICAL INSTRUCTION:

• AFTER user confirms the input overview, IMMEDIATELY call create_rule() with initial structure.

• This call is MANDATORY and CANNOT be skipped or deferred.

• The initial rule structure MUST be created before any input collection begins.

• BLOCK all subsequent input collection if initial rule creation fails.

• NEVER proceed to input collection without successful initial rule creation.

• If create_rule() fails, STOP workflow and resolve the issue before continuing.

• The rule creation establishes the foundation for progressive updates during input collection.

ENFORCEMENT STEPS:

1. Present overview to user

2. Get user confirmation

3. IMMEDIATELY call create_rule() with initial structure that MUST INCLUDE inputs and inputsMeta__ sections WITH ACTUAL INPUT DATA - DO NOT LEAVE inputs and inputsMeta__ SECTION EMPTY - INPUTS AND INPUTSMETA__ ARE MANDATORY CORE COMPONENTS THAT MUST CONTAIN THE REQUIRED INPUT MAPPINGS - THIS IS NON-NEGOTIABLE - NO EXCEPTIONS

4. Verify rule creation success before proceeding

5. Only then allow input collection to begin

TASK-BY-TASK INPUT COLLECTION & VALIDATION (CRITICAL ENFORCEMENT): ═══════════════════════════════════════════════════════════════════ MANDATORY WORKFLOW FOR EACH TASK:

FOR EACH TASK in selected_tasks: STEP 1: Collect ALL inputs for current task - Use collect_template_input() for file/template inputs - Use collect_parameter_input() for parameter inputs - Wait for the current task inputs to be collected

STEP 2: **MANDATORY EXECUTION** (CANNOT BE SKIPPED)
        ⛔ THIS STEP CANNOT BE SKIPPED ⛔
        - Call execute_task(task_name, collected_inputs_for_this_task, application_config)
        - This MUST happen IMMEDIATELY after all task inputs are collected
        - BLOCK progression if execution fails
        - If execution fails:
          * Show execution errors to user
          * Allow input correction
          * Re-execute with corrected inputs
          * Only proceed when execution succeeds
        - On success:
          * Store the REAL outputs from this task
          * Use these outputs as inputs for dependent tasks
          * Display output files to user

STEP 3: Move to next task ONLY after the task execution succeeds
        - Task Execution success = prerequisite for next task
        - No task can start input collection without previous task execution completing successfully
        - Use the REAL outputs from the executed task as inputs for dependent tasks

❌ PROHIBITED ACTIONS:

• Collecting inputs for Task N+1 without executing Task N

• Skipping execution "to save time"

• Assuming execution will happen "later"

• Moving to final rule creation without executing all tasks

✅ CORRECT WORKFLOW: Task1 Inputs → Execute Task1 → Show Results → Task2 Inputs → Execute Task2 → Show Results → Task3 Inputs → Execute Task3 → Show Results → Complete Rule

❌ WRONG WORKFLOW: Task1 Inputs → Task2 Inputs → Task3 Inputs → [Try to execute later]

SELECTIVE INPUT INCLUSION:

• DO NOT automatically include ALL task inputs in initial rule creation.

• Only include inputs that are REQUIRED or explicitly needed for the user's use case.

• Skip optional inputs unless user specifically requests them.

• Additional inputs can be added later if needed during execution or refinement.

FAILURE HANDLING:

• If user confirms but create_rule() fails → STOP and fix issue.

• If user declines → End workflow, no rule creation needed.

• If create_rule() succeeds → Proceed to task-wise input collection and execution.

• NEVER skip the create_rule() call after user confirmation.

HANDLES DUPLICATE INPUT NAMES WITH TASK ALIASES (Preserved):

• Creates unique identifiers for each task-alias-input combination.

• Format: "{task_alias}.{input_name}" for uniqueness.

• Prevents conflicts when multiple tasks have same input names or same task used multiple times.

• Maintains clear mapping between task aliases and their specific inputs.

• Task aliases should be simple, meaningful step indicators (e.g., "step1", "validation", "processing").

OVERVIEW REQUIREMENTS (Preserved):

1. Analyze ALL selected tasks with their aliases for input requirements.

2. Categorize inputs: templates vs parameters.

3. Create unique identifiers for each task-alias-input combination.

4. Count total inputs needed.

5. Present clear overview to user.

6. Get user confirmation before proceeding.

7. Return structured overview for systematic collection.

8. NEW: Automatically create initial rule after user confirmation.

OVERVIEW PRESENTATION FORMAT (Enhanced with Validation):

INPUT COLLECTION OVERVIEW:

I've analyzed your selected tasks. Here's what we need to configure:

TASK 1: [TaskAlias] ([TaskName]) ─────────────────────────────────── Template Inputs: • [InputName] ([Format] file) - [Description] Unique ID: [TaskAlias.InputName]

Parameter Inputs: • [InputName] ([DataType]) - [Description] Unique ID: [TaskAlias.InputName] Required: [Yes/No]

⚠️ EXECUTION CHECKPOINT: After collecting all Task 1 inputs, execute_task() will be called to execute the task with real data before proceeding to Task 2.

TASK 2: [TaskAlias] ([TaskName]) ─────────────────────────────────── [... similar structure ...]

⚠️ EXECUTION CHECKPOINT: After collecting all Task 2 inputs, execute_task() will be called to execute the task with real data before proceeding to Task 3.

SUMMARY:

• Total inputs needed: X

• Template files: Y ([formats])

• Parameter values: Z

• Estimated time: ~[X] minutes

• Execution checkpoints: [number of tasks]

WORKFLOW:

1. For each task in the rule:

   • Collect all required inputs for the task

   • Execute the task with real data using execute_task()

   • Mark the task as executed (✓)

   • Store REAL outputs for use by dependent tasks

2. After all tasks are executed → proceed to final rule completion

Ready to start task-by-task input collection with execution checkpoints?

CRITICAL WORKFLOW RULES:

• ALWAYS call this tool first before any input collection.

• NEVER start collecting inputs without user seeing overview.

• NEVER proceed without user confirmation.

• Create unique task_alias.input identifiers to avoid conflicts.

• Show clear task-alias-input relationships to user.

• NEW: Collect inputs task-by-task and execute each task immediately after collection.

• NEW: Use REAL outputs from executed tasks as inputs for dependent tasks.

• NEW: Create initial rule structure after user confirmation.

CRITICAL REQUIREMENTS:

• Input names: alphanumeric + underscore only (auto-sanitize with re.sub(r'[^a-zA-Z0-9_]', '_', name))

• Collection order: Complete ALL inputs for each task one by one (Task 1 → execute Task 1 → Task 2 → execute Task 2 → Task 3 → execute Task 3)

• Within each task: collect all inputs, then execute using 'execute_task()' to get real outputs before proceeding

• If a task (e.g., Task 2) has input files or other inputs that depend on a previous task, use the REAL output from the executed previous task as the input. Do NOT generate sample data.

• If the previous task has not been executed yet, execute it first to obtain real outputs.

ARGS:

• selected_tasks: List of dicts with 'task_name' and 'task_alias' Example: [ {"task_name": "data_validation", "task_alias": "step1"}, {"task_name": "data_processing", "task_alias": "step2"}, {"task_name": "data_validation", "task_alias": "final_check"} ]

Returns: Dict containing structured input overview and collection plan with unique identifiers, plus automatic rule creation capability after user confirmation, with explicit execution checkpoints for each task