bug: honor every accepted FrameworkConfig log level on the user stream #357

Problem

Configuration validates debug, info, warning, error, and critical, but runtime logging only uses the debug distinction. Accepted warning/error/critical values silently behave as info, so commands emit messages the user configured them to suppress.

Verified evidence

Reviewed on 2026-09-17 at 2d67cd24e8d704386f2be7d3a41addc06fb81e17 (local checkout matched GitHub main). Reproduced in isolated macOS environments with Python 3.14.6. Framework default probe environment: Click 8.5.0 and Typer 0.27.2. Demo probes used released base-cli 0.4.3 unless noted.

For each supported level, an isolated batteries-included app loaded log_level: <level> and logged INFO, WARNING and ERROR markers. All five invocations exited 0; every one printed the INFO and WARNING markers. _create_context() computes only debug = ... or log_level == "debug"; configure_logger selects DEBUG/INFO/WARNING from debug/quiet and receives no configured level.

Sources:

• lib/python/base_cli/config.py
• lib/python/base_cli/_app_core.py
• lib/python/base_cli/logging.py
• tests/test_batteries_included_config.py

Acceptance criteria

• Apply all accepted configured severity levels to the user-facing handler, or explicitly narrow the documented accepted contract with migration treatment.
• Define and test precedence with explicit --debug/--quiet and their supported negative forms.
• Keep persistent diagnostic verbosity separate from user-stream filtering according to the logging contract.
• Add parameterized assertions for all five levels in native and attached applications, including JSON logs.

Project fields

• Status: Backlog
• Priority: P2
• Area: CLI
• Initiative: v1.0 Readiness
• Size: S
• Assignee: @codeforester
• Milestone: v1.0.0
• Target date: unscheduled