doctor --fix says nothing in text mode when the consent gate suppresses it -- the customer cannot tell 'nothing to fix' from 'tan declined'

[alpCaner]

Found by running the merged dev freeze in a pristine ubuntu:24.04

Measured against ac79d4c (PR #352 merged), frozen from that tree, run in a container carrying only what the quickstart says to install: ca-certificates, git, python3.

tan doctor --build --fix silently does nothing in text mode when the consent gate suppresses it.

The suppression itself is correct and deliberate (tan-cli#91): a container has no TTY, so can_prompt() is false and --fix must not mutate the host unwatched. The defect is that only the JSON envelope says so.

Reproduction

# pristine ubuntu:24.04, only ca-certificates + git + python3 installed
tan doctor --build --fix --sdk-root ./alp-sdk

Text mode, last lines the customer sees:

[   pass] sdkProvenance: alp-sdk 0.15.0 @ 8af7f28

5 passed, 5 warning(s), 4 failed.

Grepping the entire text output for suppress|--fix|did not run|no repair|not.*interactive|terminal returns no match. The customer typed --fix, got a report, and is never told the repair did not run.

The same invocation with --format json does carry it:

issue codes : ['doctor.boardYaml', 'doctor.workspace', 'doctor.westResolved',
               'doctor.pythonFloor', 'bootstrap.prerequisites-missing',
               'doctor.west', 'doctor.zephyrSdk', 'doctor.setools',
               'doctor.jlink', 'doctor.fix-suppressed']
fix:* checks : 0

doctor.fix-suppressed is emitted; no fix:* check is, which is consistent — nothing was attempted.

Why this matters more than it looks

tan-cli#360's acceptance criteria say, verbatim: "Text and JSON modes both explain that no repair ran." That was written about a missing installer; the same requirement applies to a suppressed run, and text mode meets it in neither case today.

It is also the exact shape #360 was filed for — the least-equipped host gets the least diagnostic behaviour. A customer on a fresh machine, in CI, over SSH without a TTY, or piping output to a file, runs the command tan's own bootstrap message recommends and cannot distinguish "nothing needed fixing" from "tan declined to fix anything".

The bootstrap message that sends them there (tan-cli#355/#370) reads:

Or run `tan doctor --build --fix`: it prints the exact command for each tool
from the SDK's manifest, and runs the ones needing no elevation (tan never
spawns `sudo` itself).

Accurate — but on this host it printed the commands via hostPrerequisites' own fix: line and ran nothing, and said nothing about the second half.

Acceptance criteria

• Text mode states plainly that --fix did not run, and why (no TTY / --non-interactive / --ci / --format json), naming which condition applied.
• The same holds for the missing-installer case doctor --fix silently skips every repair when brew or winget is absent #360 covers.
• A test asserts the text-mode sentence with stdin/stderr not a TTY, so it cannot regress to JSON-only.
• The report still ends with the summary line; the notice must be findable, not buried mid-report.

Related: #91, #355, #360, #370.

[alpCaner]

Fixed in 75647ed on fix/v06-followups, and verified in the same pristine ubuntu:24.04 that found it.

The customer now reads, verbatim:

warning: `--fix` was requested but not run: no interactive terminal (stdin/stderr not a tty -- piped, redirected, or CI). Re-run `tan doctor --fix` from a real, interactive terminal, without --ci/--non-interactive/--format json, to allow it.

Notice at line 24, summary at line 26 — findable, and the summary is still the last thing printed. --ci and --non-interactive name themselves in the same shape, because "not interactive" is useless to someone who did not realise their CI runner has no TTY.

The cause was wider than this issue described

I filed this as "the suppression notice is JSON-only". The real defect: doctor()'s text branch printed the per-check loop and the summary and never read issues at all outside the data is None exception path. So any Issue with no backing Check was JSON-only by construction.

Two producers hit it, not one:

• fix_suppressed_issue — this issue.
• project_pin_issue (tan-cli#263) — a broken ~/.alp sdk-path pin, equally silent in text mode, never reported.

Fixing only the reported symptom would have left the second one shipping. Text mode now prints every issue whose code is not already represented by a printed check, so the class is closed rather than the instance.

Checked, not assumed

doctor.fix-installer-not-found (#360) does not have this gap — it returns a Check, so the existing loop prints it. Verified against its own test rather than presumed.

Suppression stays an Issue rather than synthesised per-tool fix:{tool} checks. run_fix's invariant ("every entry is run or refused, every outcome becomes a check") is about entries in missing; when the gate suppresses, run_fix is never called, so there are no per-tool outcomes to report. Fabricating checks for tools never inspected would be the same dishonesty pointing the other way.

Tests: 505 passed, 3 skipped; fail-before/pass-after confirmed by reverting the source (504 passed, 1 failed). No new Check(...) call, so the gate's hand-declared expected_calls is unchanged — that lockstep pair reddened python and seam1 earlier today when I split it across two commits.