v3.15.2

Bug Fixes

• @byline/core — buildSearchDocument now indexes prose stored inside container fields. Previously, a search.body entry could only name a top-level field (a scalar or a richText leaf); a collection whose body lived inside a blocks field — like the reference docs collection's content (RichTextBlock prose, PhotoBlock alt text + caption) — had none of that prose indexed. Only the top-level title and summary reached the tsvector, so a search for any term appearing solely in the body (e.g. "reflects") returned no results despite the term being plainly visible in the rendered page and the .md export. A search.body entry may now name a container field (blocks / array / group); the assembler walks it recursively and flattens every nested richText and text (text / textArea) leaf into the searchable body. Nested non-text leaves (select, relation, numbers, booleans, dates, files) are deliberately skipped so block configuration never pollutes the index — the same "content, not configuration" rule the markdown assembler already follows. The walk is block-agnostic: blocks resolve by _type against the field's own blocks list, so adding new block types needs no change to buildSearchDocument.

Migrations

• monorepo — this fix changes only how new index writes are assembled; existing index rows stay stale until re-indexed. After upgrading, reindex each affected collection to pull block-based prose into the index — via the admin Reindex button or client.collection('<path>').reindex(). Collections whose searchable body is entirely top-level are unaffected. The reference webapp's docs collection adds 'content' to its search.body to opt the block prose in.

All other @byline/* packages bumped to 3.15.2 in lockstep with no behavioural changes this cycle.