[johnmatthewtennant]

Why

Sending a message failed with "Community emoji isn't ready. Your draft is kept; try sending again shortly." (or "Community emoji unavailable") whenever the community's custom emoji catalog was still loading or had failed. Nothing published. Two things caused it:

• The send waited for optional enrichment. emoji-directory.ts tags() threw while the catalog wasn't ready, so any message with a shortcode candidate was refused, including replies, edits and attachment publications.
• Timestamps looked like shortcodes. The shared matcher read :25Z: in 19:25Z: and :30: in 14:30:00 as emoji references. Agents and people write times like this constantly, so ordinary status messages hit the first problem even though they reference no emoji.

What

• Sending never waits for the catalog. While it is loading or failed, shortcodes are sent as literal text without emoji tags, and a send after a failed read still starts one shared retry. A loaded catalog still pins each code to its original URL. The composer's "Retry message preparation" button is gone because nothing is refused anymore.
• A colon that directly follows a letter, digit or underscore no longer opens a shortcode, as in other emoji tokenizers such as Mastodon's. Standalone (:party:), chained (:party::wave:) and overlapping (:unknown:party:) codes still match. The renderer, tagging, referencedEmoji and agent sends share the matcher, so sent tags and rendering agree. Text such as word:party: now stays plain text.
• Each shortcode on an edited message keeps its latest explicit mapping, from the newest edit or the original that tagged it. An edit sent without emoji tags (for example while the catalog loads) no longer falls back to the original's mapping alone.
• The composer highlights custom emoji with the same matcher, so nice:party: no longer previews an emoji that the send leaves literal.
• Picking a custom emoji from the composer's Emoji tool right after a word inserts a space first (nice :party:), so the picked emoji still renders and is tagged.

Reviewer-reproducible examples

End to end in the web build: run it against a local ghcr.io/block/buzz:main relay, seed one kind 30030 buzz:custom-emoji set containing party, and hold the POST /api/relay/<origin>/query request for that set open (for example with a Playwright route). Then send from the composer and read the channel's kind 9 events back from the relay:

Send	main	This PR
STATUS ~19:25Z: DRAFT. NEXT: check again at 14:30:00. (catalog loading)	"Community emoji isn't ready", nothing published	Published with that content, no emoji tag
:party: hello (catalog loading)	Same error, draft kept	Published literally, no emoji tag
:party: (catalog loaded)		["emoji", "party", <url>]
nice:party: (catalog loaded)		Literal, no tag; the composer shows no emoji image

Human testing: not yet done. John authorized readiness on 2026-11-07 before running the emoji send steps himself, so buzz-review-completed is withheld until he confirms.

Screenshots

Sending timestamp prose while the community emoji catalog is still loading. Before, on main, the send is refused:

After, it publishes immediately and the composer clears:

🤖 Generated with Claude Code

[wesbillman]

🤖 Star Lord’s automated source review via Wes’s account, with independent Rocket, Mantis and Groot coverage.

Reviewed f5c1e8a4899d132f17f112b7edf6b4957bb9e745 against target/merge-base d3d69aaa24628cb43036cfc106f77de140b90c38. No required changes found. The optional Unicode boundary refinement is noted inline; it preserves existing behavior and does not block this fix.

Coverage: catalog loading/retry/disposal and send callers; shared shortcode parsing; edit mapping order/deletion handling; composer preview, edit and recovery paths; changed regression tests. The public description and both screenshots were inspected with no concrete disclosure finding.

Source-only: no tests, builds, app or native/browser workflows were run. The reported web reproduction was not independently verified, and the description explicitly leaves human testing outstanding. This is a COMMENT review, not approval or runtime acceptance.

[wesbillman]

🤖 Star Lord’s automated source follow-up via Wes’s account, with independent Rocket, Mantis and Groot coverage.

Reviewed 5304a1d741a3ac1f4517e0ca87d77d2563c023d6 against target/merge-base d3d69aaa24628cb43036cfc106f77de140b90c38, focusing on the changes since reviewed f5c1e8a4899d132f17f112b7edf6b4957bb9e745. No new actionable findings.

The prior optional Unicode boundary note is addressed in source: the matcher handles full code points and trailing combining marks, with regression cases added. The per-shortcode edit fold preserves the newest valid explicit mapping in the existing authorized, non-deleted edit order, then falls back to the original for other codes. Prior unchanged catalog/retry/send coverage is retained. The current description and unchanged screenshots were checked.

Source-only: no tests, benchmarks, builds or app workflows were executed. The author’s reported testing was not independently verified; native/browser behavior and human acceptance remain unverified. This COMMENT is not approval.

[tellaho]

🤖 Drip design review at 5304a1d741a3ac1f4517e0ca87d77d2563c023d6: no design blockers found in the source and supplied screenshots.

This repairs sending while optional emoji loads or fails, keeps timestamps and embedded word text literal, and preserves each shortcode’s latest image mapping through edits. Both before/after screenshots were inspected; the light-theme after image shows the timestamp message and an empty composer.

Not checked: tests, live/native sending, dark mode, narrow or enlarged layouts, keyboard/focus, long content, or agent-heavy conversations. Human testing remains outstanding per the PR description.

[kalvinnchau]

🤖 One picker regression should be fixed before merge.

[wesbillman]

🤖 Star Lord’s automated source follow-up via Wes’s account, with independent Rocket, Mantis and Groot coverage.

Reviewed e61db030a4d61a07800f2e585df0e804f4af847f against target/merge-base d3d69aaa24628cb43036cfc106f77de140b90c38, focusing on the insertion change since 5304a1d741a3ac1f4517e0ca87d77d2563c023d6. One P2 finding is detailed inline: the picker separator also changes clipboard text through the shared insertion path. Please preserve verbatim paste while retaining picker-after-word spacing.

The shared Unicode matcher, selection/range handling, insertion limits and undo were reviewed. Prior unchanged catalog/retry/send/edit-mapping coverage is retained. The current public description and both unchanged screenshots were checked with no new disclosure finding.

Source-only: no tests, builds or app workflows were executed. The author’s reported tests were not independently verified; native/browser behavior and human acceptance remain unverified. This is a COMMENT review, not approval.

[wesbillman]

🤖 Star Lord’s automated source review via Wes’s account, with independent Rocket, Mantis and Groot coverage.

Reviewed 1d30546a2f58be6fd1021649c5fe77bf9406187c against target/merge-base d3d69aaa24628cb43036cfc106f77de140b90c38, focusing on the delta from e61db030a4d61a07800f2e585df0e804f4af847f and retaining unchanged prior coverage.

The prior clipboard mutation is fixed: normal paste and Paste and Match Style bypass spacing, and explicit inline-code marks now do too. One P2 remains in the code-preservation path: picker insertion inside Markdown code restored for editing still adds a space. Details inline.

Optional cost cleanup: fold.ts computes referencedEmoji(content) inside the mapping filter; computing a referenced-code set once avoids reparsing the same content per historical mapping. Runtime impact was not measured.

Source-only. We did not execute tests, builds or native/browser workflows. The PR description and both attached screenshots were inspected; author-reported tests and human acceptance remain unverified.