Surface resolved shell/execution mode in UI, logs, and validation

[yottahmd]

Problem

Dagu supports several ways to determine how a step runs: a step-level shell, a DAG-level shell, the global default shell, shebang-based script execution, and direct execution. That resolution is meaningful because it changes both what interpreter is used and how commands are evaluated.

Today that choice is mostly hidden from users. In the product, authors can define shell behavior in YAML, but the UI, logs, and validation output do not clearly show whether a step will run with bash, zsh, shebang, direct, or an inherited/default shell. This makes authoring and debugging harder, especially when behavior differs because a step inherited its shell or switched execution mode at runtime.

The gap is especially confusing for workflows that rely on shell-specific syntax, preconditions, or scripts with shebangs. Users often have to infer shell resolution from docs instead of seeing it directly in the product.

Expected Behavior

Dagu should explicitly show the execution mode for each step anywhere users need to understand or debug it, including DAG details, DAG run views, step logs, and validation output.

The product should make it clear whether a step is using:

• an explicitly configured step shell
• an inherited DAG shell
• the global default shell
• shebang-based execution
• direct execution

When the exact interpreter cannot be known until runtime, Dagu should say that clearly instead of implying certainty.

Example

name: shell-visibility-example

shell: bash

steps:
  - name: uses-dag-shell
    command: echo "runs with bash"

  - name: uses-step-shell
    shell: zsh
    command: echo "runs with zsh"

  - name: uses-shebang
    script: |
      #!/usr/bin/env python3
      print("runs via shebang")

  - name: uses-direct
    shell: direct
    command: ["/bin/echo", "runs directly"]

Motivation

This closes a real UX gap in a shell-heavy workflow engine.

Making shell choice explicit would reduce authoring mistakes, make debugging faster, and help users understand why the same workflow behaves differently across environments. It also improves trust in validation and run history by showing what Dagu knows, what is inherited, and what is only decided at runtime.

This would unblock workflows that depend on shell-specific behavior without forcing users to over-specify shell: everywhere just to make execution understandable.

Tests

• PR must include integration tests under intg package.