A GTDB block sits on a plant taxon: NCBITaxon:169215 is Bosea (Amaranthaceae), used for a bacterium

[realmarcin]

Found reviewing PR #364. Pre-existing; no gate can see it.

NCBITaxon:169215 is the plant genus Bosea (Eukaryota → Viridiplantae → Amaranthaceae, rank genus). Two records use it for the alphaproteobacterium and carry a bacterial GTDB block derived from it:

• kb/communities/MSC1_Dominant_Core.yaml — Bosea sp.
• kb/communities/EcoFAB_Ring_Trial_SynCom17.yaml — Bosea sp. OAE506

both with gtdb_lineage: d__Bacteria;p__Pseudomonadota;…;g__Bosea.

The block was produced by a name collision: gtdb_ground.py's higher-rank path matches on the cleaned label string, never on the id, so "Bosea" resolved to the bacterial genus while the id points at a plant.

Invisible to every existing gate. ncbi_source_id == term.id, so the freshness test added in #364 passes. "Bosea" genuinely is NCBITaxon:169215's label, so id↔label correspondence passes. linkml-validate has nothing to say.

Same defect class as the two entries deliberately withheld under #292 — except here the block was written rather than withheld.

Candidate correct ids (a curation call, which is why this is filed rather than fixed): NCBI appears to have renamed the alphaproteobacterial genus — NCBITaxon:85413 is now Allobosea, and NCBITaxon:1871050 is Bosea sp. (in: a-proteobacteria).

Mechanical guard worth adding either way: if gtdb_lineage starts d__Bacteria or d__Archaea, then term.id must sit under NCBITaxon:2 or NCBITaxon:2157. GTDB is prokaryote-only, so a eukaryotic id carrying a prokaryotic lineage is always wrong. That check would have caught this at write time.

[realmarcin]

Reopened — closed by accident, not by a fix. The commit for PR #364 said "Filed rather than fixed: #365", and GitHub parsed the adjacent keyword.

Nothing was implemented. Two records still carry a bacterial GTDB block on NCBITaxon:169215, which is the plant genus Bosea.

This is the fifth accidental close in this repo by the same mechanism (#328, #355, #359, #358, now this). The rule in prompts/backlog-loop.goal.md already covers it — "a keyword beside #N closes it even when negated" — so the failure is in applying it, not in the wording. The safe habit is never to put #N after any form of close/fix/resolve at all: write "Deferred: #N", or name the issue somewhere else in the sentence.

[realmarcin]

Reopened again. Still nothing implemented — two records continue to carry a bacterial GTDB block on NCBITaxon:169215, the plant genus Bosea.

The re-close is instructive. The previous commit message quoted the offending phrase in order to explain the earlier accident, and GitHub parsed the quotation exactly as it parsed the original. Describing the trap re-sprang it.

So the rule needs one more clause than the prompt currently carries: do not write this issue number adjacent to any form of close/fix/resolve even inside quoted text or an explanation of a previous mistake. Reference it by number alone, or restructure the sentence so the keyword is nowhere near it.

Sixth occurrence in this repo (#328, #355, #359, #358, and this one twice).