CLI incorrectly assumes non-interactive mode

Our CLI app allows users to provide prompt answers in multiple ways:

• Some values can be configured via CLI arguments and options, e.g. name.
• It is possible to provide JSON object with values to all prompts via --config option.
• It is possible to stream a JSON object to stdin

At the moment, the logic determining when to read data from stdin is based on process.stdin.isTTY flag. Unfortunately, this is often causing confusing behavior.

• When debugging our CLI tool via Visual Studio Code, application's stdin stream is in non-TTY mode. As a result, CLI uses different way (code path) to prompt for options.
• The outcome of our test suite depends on whether the stdin stream is available and in TTY mode. When running the tests with stdin disabled (e.g. via npm test < /dev/null), many of the tests fail.

I would like us to improve the logic deciding how to prompt for options and make it more robust, less suspect to different ways how CLI can be legitimately invoked.

Acceptance Criteria

To be added by the team after discussing with @bajtos.

Start by locating the CLI logic that decides whether to read JSON from stdin, then inspect the tests that fail when stdin is disabled with npm test < /dev/null. The issue has no acceptance criteria yet, so confirm the intended prompting behavior with the team before changing code; done should include stable behavior across debugging, TTY, and disabled-stdin runs.