Skip to content

bug: make standard color and verbosity options work through the application launcher #450

Description

@codeforester

Goal

make standard color and verbosity options work through the application launcher.

Background and verified evidence

Review date: 2026-09-17. Reviewed commit: 38042cbf23b9380c626aae6c9fe168f97096c1cc. Parent: #214.

Follow-up to #450: mode forwarding and logging threshold fixes landed, but base_app_apply_standard_options maps both auto and always to the same boolean. __base_bash_libs_std_init_colors__ then always disables ANSI output when stderr is not a TTY. An initialized public CLI/app model parsed with --color always and base_std_print_error produces no escape bytes when captured. always cannot force color as its advertised mode implies.

Scope and acceptance criteria

  • Distinguish auto/always/never at the renderer rather than only in published policy globals.
  • Specify the interaction between explicit always, NO_COLOR, non-TTY stderr, and the compatible bare launcher color flag.
  • Test actual captured and PTY output through direct, generated and packaged execution, retaining quiet/verbose behavior.

Validation

Create an initialized model with base_app_add_standard_options, parse/apply each color mode, capture base_std_print_error bytes with NO_COLOR unset and set, and run app/launcher/full gates.

Non-goals

No unrelated API expansion or automatic release publication. Preserve immutable published assets and unrelated consumer files.

Project fields

  • Status: Ready
  • Priority: P2
  • Area: CLI
  • Initiative: Adoption Polish
  • Size: S
  • Milestone: v2.2.0
  • Target date: unset; no delivery date has been committed.
  • Type: Bug

Agent assignment

Assignee: codeforester. This is review/backlog intake; implementation has not started.

Original issue description (historical evidence)

Goal

Honor the behavior advertised by generated applications' standard option help.

Background

Parent: #214. Identified in the 2026-09-11 design, engineering, and adoption review at de1589c803591ac41a16cca33da4726bb96e15fc.

base_init consumes bare --color as a wrapper flag, while base_app_add_standard_options declares --color <MODE> for the app. bin/base-bash examples/reference-apps/ops-cli/bin/app --color never status returns 2 because never becomes positional and prevents subcommand selection. Separately, a standard generated app invoked via the repository launcher with status --quiet still emits an INFO framework diagnostic: apply-standard-options publishes globals but the generated flow never applies the advertised log policy. --verbose and color rendering need the same end-to-end check.

Scope

Choose a backward-compatible wrapper/application ownership rule for color and make the generated/reference applications apply standard logging/color policy.

Acceptance Criteria

  • Record how legacy bare wrapper --color remains compatible or is explicitly deprecated; do not silently reinterpret a stable invocation.
  • App --color never/always/auto and --color=MODE survive forwarding with equivalent results.
  • Generated --quiet suppresses informational diagnostics; --verbose enables the intended diagnostics; invalid/conflicting modes return 2.
  • Cover direct supported launcher, generated shebang, and packaged consumer execution, including stdout/stderr and -- boundaries.

Validation

Run the reproduced ops-cli command and a standard scaffold through the exact repository launcher. Assert logs as well as result globals. Run launcher, app, reference-app BATS and full validation.

Non-Goals

No breaking wrapper flag reinterpretation without a compatibility decision. No changes to application data output under --quiet.

Project Fields

  • Status: Triage
  • Priority: P2
  • Area: CLI
  • Initiative: Adoption Polish
  • Size: M
  • Milestone: v2.2.0
  • Target date: unset; no delivery date has been committed.

Agent Assignment

  • Assignee: codeforester
  • Decision required before implementation; no agent is currently implementing this issue.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething is not working

Type

Projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions