Introducing the concept of aliases for step naming in the GUI

 Introducing a step alias or contextual label solves a critical usability problem that emerges as workflows grow.

Let's break down this idea and integrate it into the implementation plan.

Imagine a workflow that fetches data from three different sources before combining it:

codeCode

- Step 0: /core/protocol/http/v1.0.0 --url $source_A_url
- Step 1: /core/protocol/http/v1.0.0 --url $source_B_url
- Step 2: /core/database/sqlite/v1.1.0 --query "SELECT * FROM users"

When you look at this in the IDE, it's ambiguous. Which http call is which? If Step 1 fails, the log says "Step 1 (/core/protocol/http/v1.0.0) failed." This is not very helpful.

Your Solution: The Step Alias

You propose adding an optional alias field to the step definition in config.json.

codeJson

"steps": [
  {
    "agent": "/core/protocol/http/v1.0.0",
    "alias": "Fetch User Profile from API",
    "params": { "url": "$source_A_url" },
    "output": ["user_profile_data"]
  },
  {
    "agent": "/core/protocol/http/v1.0.0",
    "alias": "Fetch Account Details from API",
    "params": { "url": "$source_B_url" },
    "output": ["account_details_data"]
  },
  {
    "agent": "/core/database/sqlite/v1.1.0",
    "alias": "Get Local User Preferences",
    "params": { "query": "SELECT * FROM users WHERE id=$user_id" },
    "output": ["user_prefs"]
  }
]

The "Smart Alias" Enhancement

Your second insight—"it could even be an input name by default, like the http agent saying who it is connecting to. —is what makes this feature truly intelligent.

The IDE can have a "smart default" for the alias.

1. User-Defined Alias: If the user types a specific string like "Fetch User Profile", that's what is used.

2. Dynamic Alias (The Smart Default): If the user enters a variable like $url or $query into the alias field, the IDE and the engine understand this.

3. Fallback Alias: If the user provides no alias, the system falls back to just showing the agent's name.

How This Changes the System (Updated Implementation Plan)

This new feature needs to be woven into the plan. It's a UI/UX and logging feature, so it primarily affects the front-end and any user-facing output.

Phase 2: IDE Modifications (Enhancement)

1. :

   • Add a new CTkEntry field at the top labeled "Step Alias (Optional)".

   • Provide help text explaining its purpose: "Give this step a unique, human-readable name for this workflow. You can use variables like $url to make the alias dynamic."

2.  (

   • This is where the magic happens. The function that renders the list of steps in the IDE will now have more complex logic.

   • For each step, it will:

     1. Check if step['alias'] exists.

     2. If it's a static string: Display it.

        • Example label: 0. Fetch User Profile from API (/core/protocol/http/v1.0.0)

     3. If it's a dynamic alias (starts with : The IDE can't resolve the value at edit-time, so it should display it in a special way to indicate it's dynamic.

        • Example label: 1. Alias: $url (/core/protocol/http/v1.0.0)

     4. If no alias exists: Use the default behavior.

        • Example label: 2. /core/database/sqlite/v1.1.0

Phase 3: Core Engine & Execution (Enhancement)

1.  Logging:

   • The log messages generated by the exec_workflow loop must be enhanced. This is a huge win for debuggability.

   • Before: INFO: Executing step 0: /core/protocol/http/v1.0.0...

   • After (with alias):

     1. The engine resolves the dynamic alias value at runtime using the scoped_params.

     2. resolved_alias = resolve_value(step.get('alias'), scoped_params)

     3. The log message becomes: INFO: Executing step 0: "Fetch User Profile from API" (/core/protocol/http/v1.0.0)...

     4. Or for a dynamic alias: INFO: Executing step 1: "https://api.example.com/details" (/core/protocol/http/v1.0.0)...

   • This makes runtime logs infinitely more useful. If a step fails, you know exactly which one failed conceptually.

Phase 4: Testing & Auxiliary Services (Enhancement)

1.  HTML Report:

   • The test report should also display the step alias. When a test for a specific workflow fails, the report can show the full trace of executed steps, using their resolved aliases, making it much easier to pinpoint the failure.

Impact and Conclusion

This is a relatively small change to the data structure (just adding one optional alias key) but it has a massive positive impact on the usability, readability, and maintainability of the entire system.

It is a perfect example of a feature that:

• Reduces cognitive load for the user.

• Makes the system more self-documenting.

• Greatly improves the debugging experience.

• Fits perfectly and elegantly into the existing architecture.

This is a crucial feature for any non-trivial workflow. It's an excellent addition to the plan.