v0.55.0: the 'Fusing N components' fix reaches the console but not the attestation (components_fused still 10 for 5 inputs) #401

The Fusing N components fix landed on the console line but not on the attestation

v0.55.0 fixed the count I reported on #390 — thank you, and confirmed against the real build. But the corrected number does not reach the attestation, which is the artifact that actually gets shipped, signed and audited.

Measured on five input files (rate, mixer, attitude, position, iekf), --memory shared --pack-rebase:

meld 0.52.0 console "Fusing 10" attestation components_fused=10 modules_merged=5
meld 0.55.0 console "Fusing 5" attestation components_fused=10 modules_merged=5

modules_merged=5 is right in both. So the flattened-list read that produced "Fusing 10" is still live in the attestation metadata, and only the human-facing line was corrected.

That is the wrong way round for the consumer this fix was for. I read the console line once, while building; the attestation is what travels with the artifact and what anyone auditing it later has to reason from. A safety case that cites components_fused now cites a number that disagrees with the tool's own console output for the same run — and the two disagreeing is arguably worse than both being 10, because it looks like two independent facts.

Not urgent for me: I read modules_merged, which was correct throughout.

Separately, and this one is a genuine trade worth documenting

--reproducible (#325) does what it says — two fuses of identical inputs gave me byte-identical output, and I have adopted it. Measured before adopting: without it, two consecutive fuses of the same five inputs produced md5 57a7cefe... then 8123737100.... Every rebuild was a different binary.

What surprised me is that it is not metadata-only. component-provenance changes too:

without --reproducible: .scratch/v1341/iekf.wasm, .scratch/v1341/rate.wasm, ...
with --reproducible: component-8, component-0, ...

The input hashes are preserved in the attestation, which is what matters — and for me the discarded names were local scratch paths, not stable identities, so this is a good trade and I took it. But the flag's help text says "derive the attestation id from the output content and take the timestamp from SOURCE_DATE_EPOCH", which reads as identifier and timestamp only. It does not say input names are replaced by positional placeholders.

Someone whose provenance story depends on those names would lose them by enabling a flag whose documented effect is about ids and timestamps. Worth one sentence in the help text — the behaviour looks deliberate and correct, it just is not what the flag says it does.

For the record on the rest of v0.55.0: on my real inputs the fused code and data are byte-identical across 0.52.0 → 0.55.0 (verified by diffing the module with both metadata sections stripped — 7,949 identical lines), and the lowered ARM objects are byte-identical to my recorded baseline on cortex-m7dp and cortex-m4f. Validation-by-default cost me nothing and I would not have wanted it opt-in.