A marked method is not the only one, and a leaf that raises is not th…

[noha]

…e scrape

Two things the exporter and the builder did quietly, both found in the review of 2026-09-20 and both reproduced in image [a] before being touched.

buildComplexProperties ran the marked method only when there was exactly one of them - no else, no complaint. A class with two methods therefore got neither, and "two" is not exotic: it is what a subclass has the moment it adds a branch to the one it inherits. Measured on the old code with an example that declares two: both keys missing, not one. Every marked method is sent now, each once, in pragma order.

It is sent by the method's own selector rather than by #canopyBranch: derived from the pragma name. Identical for all ten declarations in the image - checked, the only one named otherwise is the new example - but only one of the two answers the question "which method did I mark". An override appears twice in the pragma list and both entries name the same selector, so distinct selectors run the override once and never the method it replaces.

visitMetric: evaluated a leaf and let whatever came out of it leave through #format:. One component that cannot answer therefore ended the export where it stood, and every series after it left the scrape too - which reads as a server that stopped reporting rather than as one value that could not be read. On the old code the whole export raised. The guard sits on the ask, because asking is what evaluates: once the holder is in hand the readings are too, so the stream cannot be left carrying a header whose lines never came.

The review note said the filter sat one level too late, and that framing was wrong: it cannot move earlier without giving up the model where the returned holder decides what a leaf contributes. What was wrong was the blast radius, and that is what changed.

Canopy-Core-Tests 91 passed in image [a], the same four stale failures as before - none of those four tests exists on main.