Skip to content

Add global banner for top-level dev-tools execution with orchestration-safe suppression #276

@coisa

Description

@coisa

Problem

dev-tools currently shows the ASCII logo only when the Symfony Application help path is executed (help/list), because the current customization is in DevTools::getHelp().

When users run normal commands, the logo is not shown. If we add output in run()/doRun(), orchestrator commands that execute nested dev-tools commands via process queue (for example dev-tools:standards) end up printing the logo repeatedly.

Proposal

Add a generic mechanism to show the logo at the top-level CLI execution only, while automatically suppressing it in orchestrated child invocations.

Goals

  • Show the ASCII header before command output for direct dev-tools CLI invocations.
  • Preserve list/help behavior and avoid regressions.
  • Avoid per-command changes; centralize suppression logic in shared execution/process infrastructure.
  • Prevent repeated logo output from orchestrators that spawn nested dev-tools commands.

Expected Behavior

  • Running vendor/bin/dev-tools <command> prints the logo once before the command output.
  • Running orchestrator commands that internally run vendor/bin/dev-tools <subcommand> should print the logo only for the root process.
  • Non-dev-tools subprocesses should continue unchanged.

Implementation Strategy

  1. Add a single execution suppression flag read early in DevTools (for example FAST_FORWARD_DEV_TOOLS_SUPPRESS_LOGO), defaulting to disabled.
  2. In DevTools::run() (or doRun() if more appropriate in this stack), print the logo when the process is top-level and not in JSON/noisy-mode-restricted contexts, then delegate to parent execution.
  3. Make nested ProcessBuilder instances automatically propagate FAST_FORWARD_DEV_TOOLS_SUPPRESS_LOGO=1 into the environment for all spawned processes, so nested dev-tools commands detect suppression automatically.
  4. Keep getHelp() behavior unchanged (or make it explicit that logo is still shown for help list text only if desired).
  5. Add tests that cover:
    • top-level invocation prints logo exactly once;
    • nested orchestrator invocation does not print logo in subprocesses;
    • command outputs/exit codes remain stable in JSON mode.

Non-goals

  • Refactoring orchestrator command logic.
  • Adding new process APIs outside command-run centralization.
  • Changing output semantics outside CLI startup branding.

Requirements

  • Deterministic and predictable logo emission, independent of command name for top-level runs.
  • Child dev-tools invocations launched by process queue must not show duplicate logo lines.
  • Existing list/help output should remain supported and readable.

Acceptance Criteria

Functional Criteria

  • Running a top-level dev-tools command renders the ASCII logo before command output.
  • Orchestrated nested dev-tools commands do not print the logo in each subprocess call.
  • list/help output remains correct and still includes help text as expected.
  • Non-dev-tools subprocess behavior remains unchanged.

Architectural / Isolation Criteria

  • MUST: The core logic MUST be isolated into dedicated classes or services instead of living inside command or controller entrypoints.
  • MUST: Responsibilities MUST be separated across input resolution, domain logic, processing or transformation, and output rendering when the change is non-trivial.
  • MUST: The command or controller layer MUST act only as an orchestrator.
  • MUST: The implementation MUST avoid tight coupling between core behavior and CLI or framework-specific I/O.
  • MUST: The design MUST allow future extraction or reuse with minimal changes.
  • MUST: The solution MUST remain extensible without requiring major refactoring for adjacent use cases.
  • MUST: Argument and option resolution MUST be validated separately from command execution logic.
  • MUST: Console formatting and rendering MUST stay separate from domain processing.
  • MUST: Exit behavior, error messaging, and generated output MUST remain deterministic and testable.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status

    Released

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions