'ts-floor' on its own collapses four distinguishable situations, and an
attribution API that cannot separate a bug from a choice is not doing its
job. The four:
createCausl() ran before
preloadCauslWasm() resolved. A BUG in the adopter's boot ordering.{ fallbackToTs: true } — the caller asked for wasm and did not get
it. An intent that was not honoured.This subpath can only attribute (3), and it is honest about the boundary
rather than guessing at the rest. The reason is stamped where the graph
object is produced, and in cases (1), (2) and (4) it is ../src/graph.ts
that produces it, not this file: createWasmSyncIfPreloaded returns
undefined (../src/wasm-registry.ts:427,431 for (1), :437-adjacent
catch for (4)) and createCausl then builds the floor graph itself
(../src/graph.ts:1135), while (2) never enters this subpath at all
(../src/graph.ts:1113). This module never holds those graph objects, so
it has nothing to stamp them with. Reporting the reason for those would
require a stamping seam in ../src/graph.ts and ../src/wasm-registry.ts
— two files outside this change — and #123's own record is process-scoped
("first pre-preload site"), not per-graph, so it would not transfer as-is.
Consequently:
'wasm-fallback' — the caller ASKED for the wasm engine on
one of this subpath's factories and opted into the soft degrade
(fallbackToTs / its fallbackToJs alias, #150). The wasm path failed
and this graph is the consolation. The one case worth alerting on: the
intent is recorded in the call, so the gap between what was asked for
and what was delivered is a fact, not an inference.'unattributed' — everything else. Deliberately
phrased as what was OBSERVED rather than as a category, because the
observation ("no wasm factory in this module built this graph") is all
that is known. It covers (1), (2) and (4) and does not pretend to tell
them apart.
WHY a graph is on the TS floor, to the precision this subpath can actually establish (#295).