read-model: publish the `selected` filter receipt on the progress channel, so a filtered read can be drawn progressively

[pawellisowski]

What

ifc-reference-reader.read-model publishes parse / tessellate / batch / complete on the progress channel (#405). None of them carries the filter receipt (selected), which appears only in the complete node output.

Why it matters

A consumer that draws segments as they arrive cannot, while drawing, tell these two runs apart:

• a bridge that honoured storeys: [L2] and is streaming one floor, and
• a pre-1.2.0 bridge that ignored the filter entirely, exits zero, and is streaming the whole building.

read-model.md is explicit that this is the failure the receipt exists to catch, and that absence-means-cannot-answer applies to the input as well as the output. So a progressive consumer has no honest option but to refuse to draw filtered reads at all.

No count cap substitutes for it. floless's own pre-read estimate documents itself as not an upper bound (a type filter resolves with includeInherited: true while the probe's rows are exact leaf names), and the harm is correctness rather than size anyway — a legitimately large floor and a silently unfiltered building are the same number of objects. Inferring capability from capability ("segments arrived, so the bridge must be new enough to filter") reasons across two independently installed binaries, which is the move frame, selected, colorsAvailable and budget all exist to make unnecessary.

Repro (measured 2026-08-12, CLI 0.121.0, agent 1.4.0, bridge current)

2023-05-09 30 Daldy Street Model.ifc, 65.8 MB, 17,460 objects, batch-size: 100:

• 237 node-progress records — 1 parse, 1 tessellate, 235 batch. Every batch record carries seq, done and an artifact descriptor.
• No record carries selected, at any phase, including complete (which repeats the whole artifact's descriptor only).
• The same run filtered to one storey behaves identically on the channel: nothing distinguishes it.

Suggested shape

Carry the receipt on the tessellate record — it is published once, after the filter has resolved to expressIDs and before the first segment, which is exactly the point at which a consumer must decide whether it may draw:

{ "kind": "node-progress", "node": "read",
  "data": { "phase": "tessellate",
            "selected": { "storeys": ["L2"], "candidates": 3767, "unmatched": [] } } }

A consumer then draws only when the receipt confirms the axes it asked for, and falls back to today's wait-for-complete otherwise. Absent selected on tessellate keeps its current meaning (this bridge cannot answer), so nothing existing changes.

Impact

floless.app ships progressive reference-model import today for unfiltered reads only, for exactly this reason — first geometry drops from ~64 s to ~6 s there. Filtered reads are the case where the wait is most often deliberate (a user narrows precisely because the building is too big), so they are the ones currently left out.

[pawellisowski]

🤖 Picked up by the morning issue routine on cloud-issue-routine-aware at 2026-08-13T04:36:24Z.

Another machine reading this issue will skip it while this claim is live (it expires after 14h). The claim is released when the run finishes, whatever the outcome.

---

Generated by Claude Code

[pawellisowski]

🤖 Morning issue routine on cloud-issue-routine-aware: fixed and merged as #410 (squashed dcb0c209) — Codex reviewed the final commit clean, CI green on the same commit. Labelled qa-ready and left open to TEST, not closed.

What shipped, built to the shape this issue suggested: the selected receipt now rides on the tessellate record, published once after the filter resolves to expressIDs and before the first segment. Absent selected keeps its meaning, so an unfiltered read publishes none and no existing consumer changes. ifc-reference-reader → 1.5.0.

One thing worth knowing before you test it, which the issue did not cover. The runtime drops a progress record over 8 KiB whole rather than truncating it, and does so silently. Since a receipt echoes caller-supplied values — and ids is documented for re-reading a known selection, where a few hundred GlobalIds is ordinary and already over that budget — the literal suggested shape would have deleted its own record precisely when the caller filtered hardest, and a consumer would have read that absence as "old bridge, do not draw". So the echoed lists are dropped largest-first until the record fits, and each one dropped is named in selected.elided:

{ "phase": "tessellate",
  "selected": { "storeys": ["L2"], "candidates": 4980, "elided": ["ids", "unmatched"] } }

candidates always survives. A field named in elided was applied but not echoed — so a consumer must check elided before comparing a list against what it sent, rather than reading the absence as "that axis was not filtered". The response's own selected is never elided, so the complete artifact always carries the full receipt. If you would rather the record were simply omitted when it cannot fit, that is a one-line change — but it puts the feature silently off in exactly the large-filter case it is most wanted.

Worth exercising on a real file (the 65.8 MB / 17,460-object model from the repro is the right one): a storey-filtered progressive read, confirming the receipt lands before the first batch record and matches the response's selected; and an ids read large enough to trip the elision, confirming the record still arrives and names what it dropped.

---

Generated by Claude Code