--fastqc is silently ignored on the specialty modes and the interleaved-uBAM paired arm

[FelixKrueger]

--fastqc is accepted but silently ignored on five dispatch paths: --hardtrim5, --hardtrim3, --clock, --implicon, and paired FASTQ output from a single interleaved uBAM. The run exits 0, writes its normal output, and produces no QC report and no message explaining why. Nothing in the CLI rejects the combination either, so a wrapper that passes --fastqc unconditionally gets no QC and no warning.

Reproduced at dev @ 3008b37:

$ trim_galore --hardtrim5 20 --fastqc a.fastq   # exit 0
a.20bp_5prime.fq                                # no _fastqc.zip, no _fastqc.html
$ ... 2>&1 | grep -ci fastqc
0                                               # not mentioned at all

Same on --clock --paired --fastqc and on --paired --fastqc one_interleaved.bam.

Either wiring FastQC into these arms or refusing the combination at the CLI would be an improvement on silence; refusing is the smaller change and matches how the other unsupported combinations behave.

AI-assisted analysis

Found independently by both plan reviewers while reviewing #414's tripwire plan, then reproduced directly.

fastqc::run is called from main.rs:1459 (run_single_file), :1778/:1784/:1796 (run_paired, including the --passthrough carrier), :2242 (run_ubam_output_single), :2399 (run_ubam_output_paired_two_files), :2522 (run_ubam_output_paired_single_file), plus the cli.fastqc pass-through into the clump_only drivers. src/specialty.rs contains no reference to it, and run_paired_ubam_single_file (main.rs:1810-2003) has none — hence the five arms. A grep over cli.rs finds no conflict rejecting the combination.

The gate at each call site is cli.fastqc || cli.fastqc_args.is_some(), so --fastqc_args alone also triggers FastQC on the supported arms — worth preserving in whichever direction this is fixed.

This surfaced as a plan defect first: #414's tripwire asserted that a --fastqc run must produce FastQC output, which is false on these five arms, so the assertion is now scoped to the arms where fastqc::run is reachable. That scoping is a workaround for the behaviour, not a fix for it.

[FelixKrueger]

Fixed in #432 (285afba). --fastqc is now refused on the five arms that reach no fastqc::run call site — --hardtrim5, --hardtrim3, --clock, --implicon, and paired FASTQ output from a single interleaved uBAM — instead of being accepted and ignored.

The fix went one arm wider than this issue described. Reviewing it turned up the same defect from the other direction: the four --clump_only drivers took a fastqc: bool fed with bare cli.fastqc, so --fastqc_args alone was a silent no-op on a path that is otherwise fully capable. That is now wired, so --fastqc_args' documented "Implies --fastqc" is true everywhere. The predicate lives in one place (Cli::fastqc_requested()) rather than being spelled out at nine sites, and the drivers' parameter is renamed fastqc_requested — a parameter named fastqc is what invited cli.fastqc at the call site in the first place.

Two details worth recording for anyone touching this later. The refusal for the interleaved arm keys on the output format as well as the input shape: --paired --output-format ubam <one.bam> routes above it and does produce a report, so refusing on --paired with one input alone would have removed a working feature. And the guard block is deliberately the last fallible check in Cli::validate — sited any earlier it masks a malformed --hardtrim5 value, an odd input count, a duplicated mate or a malformed --adapter2 spec, all of which are more actionable than "this combination is unsupported".

#422's tripwire loses the fastqc_capable scoping it carried as a workaround for this defect; its rule that a FastQC-flagged run must write artefacts is now unconditional, and a new case puts the --clump_only --fastqc_args path under it. 663 → 684 tests.