Found in the adversarial review of #120.
The rewritten HabitatMech → CultureMech reference no longer has a consumer, but the arrow still points at one
Where: _fleet/mechs_template.md:126
The section says 'Arrows point at the Mech that consumes', and the PR says it fixed the arrows that pointed away from the consumer. The rewrite of HabitatMech → CultureMech removed the old 'handed to CultureMech' claim, correctly, because the source does not support it. It now says only that a HabitatMech decision 'points to CultureMech for related curation'. CultureMech consumes nothing from HabitatMech, so the directed 'practice' arc in XREFS (fleet_fragment.html:466) now points at a Mech that consumes nothing.
Failure scenario. The graph and the cross-reference list tell a reader that CultureMech consumes or adopts something from HabitatMech. The only link is one free-text note in one HabitatMech decisions.tsv row.
Evidence. HabitatMech b16e309 curation/decisions.tsv, row habitatmech:GOLD.1d91123b55: 'BTO:0000316 culture medium is the exact concept. Related curation lives in the sibling CultureMech repo.' git -C .../CultureMech grep -l -i habitatmech faaf033 returns nothing. The template line 116 legend reads 'Arrows point at the Mech that consumes.'
Verifier (confirmed, low). I reproduced every part of the finding. The rewrite correctly drops the unsupported "handed to CultureMech" wording. The new text is accurate, but it is kept as a directed "practice" arc that points at CultureMech, and both legends define the arrow as "who consumes". The template legend also frames "practice" references as curation practices a Mech adopts from another.
At the pinned revision faaf033, CultureMech never mentions HabitatMech. It consumes nothing from HabitatMech and adopts no HabitatMech practice. The only link is one free-text note in a single HabitatMech decision row, copied into one record. So the arrowhead and the pair line (HabitatMech → CultureMech) tell a reader that CultureMech takes something from HabitatMech, and nothing supports that. Under the page's own "consumer" reading, the note points the other way, if anywhere: HabitatMech defers to curation that lives in CultureMech.
The arc is older than this PR. What the PR changed was the text: it removed the only wording that justified the direction while leaving the direction in place. The PR also presents cross-reference direction as audited, and its new skill requires checking direction. That puts the defect inside this PR's scope.
Severity stays low. It is one weak, dashed practice arc plus one list item. The prose itself is true, and nothing breaks; only the direction the arc implies is wrong. Fixes: drop the entry, reverse it or make it undirected, or widen both legends (template line 116 and fragment line 429) so an arrow can also mean "names". The reviewer suggests CellStructureMech → ProteinTraitsMech has the same shape. I did not verify that pair; it would need its own check.
Suggested fix. Drop the reference, or recast it as an undirected mention. Otherwise loosen the legend so arrows can mean 'names' as well as 'consumes' (CellStructureMech → ProteinTraitsMech has the same shape).
Found in the adversarial review of #120.
The rewritten HabitatMech → CultureMech reference no longer has a consumer, but the arrow still points at one
Where:
_fleet/mechs_template.md:126The section says 'Arrows point at the Mech that consumes', and the PR says it fixed the arrows that pointed away from the consumer. The rewrite of HabitatMech → CultureMech removed the old 'handed to CultureMech' claim, correctly, because the source does not support it. It now says only that a HabitatMech decision 'points to CultureMech for related curation'. CultureMech consumes nothing from HabitatMech, so the directed 'practice' arc in XREFS (fleet_fragment.html:466) now points at a Mech that consumes nothing.
Failure scenario. The graph and the cross-reference list tell a reader that CultureMech consumes or adopts something from HabitatMech. The only link is one free-text note in one HabitatMech decisions.tsv row.
Evidence. HabitatMech b16e309 curation/decisions.tsv, row habitatmech:GOLD.1d91123b55: 'BTO:0000316 culture medium is the exact concept. Related curation lives in the sibling CultureMech repo.'
git -C .../CultureMech grep -l -i habitatmech faaf033returns nothing. The template line 116 legend reads 'Arrows point at the Mech that consumes.'Verifier (confirmed, low). I reproduced every part of the finding. The rewrite correctly drops the unsupported "handed to CultureMech" wording. The new text is accurate, but it is kept as a directed "practice" arc that points at CultureMech, and both legends define the arrow as "who consumes". The template legend also frames "practice" references as curation practices a Mech adopts from another.
At the pinned revision faaf033, CultureMech never mentions HabitatMech. It consumes nothing from HabitatMech and adopts no HabitatMech practice. The only link is one free-text note in a single HabitatMech decision row, copied into one record. So the arrowhead and the pair line (HabitatMech → CultureMech) tell a reader that CultureMech takes something from HabitatMech, and nothing supports that. Under the page's own "consumer" reading, the note points the other way, if anywhere: HabitatMech defers to curation that lives in CultureMech.
The arc is older than this PR. What the PR changed was the text: it removed the only wording that justified the direction while leaving the direction in place. The PR also presents cross-reference direction as audited, and its new skill requires checking direction. That puts the defect inside this PR's scope.
Severity stays low. It is one weak, dashed practice arc plus one list item. The prose itself is true, and nothing breaks; only the direction the arc implies is wrong. Fixes: drop the entry, reverse it or make it undirected, or widen both legends (template line 116 and fragment line 429) so an arrow can also mean "names". The reviewer suggests CellStructureMech → ProteinTraitsMech has the same shape. I did not verify that pair; it would need its own check.
Suggested fix. Drop the reference, or recast it as an undirected mention. Otherwise loosen the legend so arrows can mean 'names' as well as 'consumes' (CellStructureMech → ProteinTraitsMech has the same shape).