Found while fixing #350. cli.py has two --communities-dir options. audit-network's defaulted to the literal "kb/communities" and silently overrode the auditor's own default — that one is a defect and is fixed in the #350 PR.
The other is on generate-umap:
@cli.command(name="generate-umap")
@click.option(
"--communities-dir",
...
default="kb/communities",
)So the UMAP is built from 312 records and the 4 in data/isolates are absent from it. Unlike the audit, this is not obviously wrong, which is why it is a question rather than a fix:
- For including them: they are
MicrobialCommunity records by target class, they are validated, term-checked and (now) network-audited alongside communities, and a reader looking at the published UMAP has no way to tell that four records simply aren't plotted.
- For leaving them out: every isolate has exactly one taxon. Whatever the embedding is measuring about community composition, a 1-taxon record is a degenerate case, and four of them may land as an artefactual cluster that reads as a finding.
I did not change it, because widening a gate's coverage is a correctness fix while changing a visualisation's inputs is a modelling decision, and the second one is not mine to make from inside a #350 PR. The test added there (test_the_cli_does_not_override_the_default) is deliberately scoped to audit_network's decorators so it does not force the answer either way — with a comment pointing here.
Whichever way it goes, the outcome should be visible in the rendered page rather than in a default: if isolates are excluded, the UMAP should say so.
Found while fixing #350.
cli.pyhas two--communities-diroptions.audit-network's defaulted to the literal"kb/communities"and silently overrode the auditor's own default — that one is a defect and is fixed in the #350 PR.The other is on
generate-umap:So the UMAP is built from 312 records and the 4 in
data/isolatesare absent from it. Unlike the audit, this is not obviously wrong, which is why it is a question rather than a fix:MicrobialCommunityrecords by target class, they are validated, term-checked and (now) network-audited alongside communities, and a reader looking at the published UMAP has no way to tell that four records simply aren't plotted.I did not change it, because widening a gate's coverage is a correctness fix while changing a visualisation's inputs is a modelling decision, and the second one is not mine to make from inside a #350 PR. The test added there (
test_the_cli_does_not_override_the_default) is deliberately scoped toaudit_network's decorators so it does not force the answer either way — with a comment pointing here.Whichever way it goes, the outcome should be visible in the rendered page rather than in a default: if isolates are excluded, the UMAP should say so.