Add media review workspace

[delkc]

Why

Buzz Foundation renders image and video attachments as links. People cannot preview media in a conversation, inspect it at full size, or connect feedback to a specific video moment. This prototype restores those core jobs without porting the legacy Buzz review stack wholesale.

What

• Render responsive image and video previews in channel messages and thread sidebars.
• Add one fullscreen review workspace for images and videos, with the canonical message thread alongside the media.
• Let video replies include the current timestamp, then seek the active player when someone selects that timecode.
• Add image zoom, bounded drag-to-pan, download, and navigation across images in the post and loaded thread.

How

The relay projection now preserves signed dimensions and preview URLs from imeta tags. The development broker proxies authenticated video ranges and streams them without buffering the full file. A failed media stream closes only that response instead of taking down live message traffic.

Inline playback stays lightweight: Play runs video in place, Expand opens the review workspace, and the normal thread affordance opens the sidebar. Both sidebar and fullscreen feedback remain ordinary thread replies. Time anchors use compatible message text for this prototype rather than a new attachment-annotation protocol.

Media frames own stable aspect-ratio geometry so repeated window resizing does not overlap later virtualized rows. Fullscreen images use bounded zoom and pan. The gallery deduplicates image URLs from the root post and loaded thread while keeping one shared conversation.

Risk

This changes the shared message renderer and development media broker, so its main risks are attachment layout, authenticated video streaming, and thread lifecycle regressions. The product is still exploratory, and the new review UI is not yet a stable plugin API.

Time anchors identify a moment in the root thread, not a specific attachment. Messages with several videos may need stable attachment identity before this model becomes permanent. Download currently uses browser behavior; packaged native download handling remains future work.

Testing

Manually tested the live macOS desktop app with existing Buzz image and video attachments. Verified inline playback, opening from the channel and sidebar, existing comments, timecoded replies and seeks, image zoom/pan/navigation, and repeated wide → narrow → wide resizing.

bin/just scan passed after rebasing onto origin/main: 670 JavaScript tests, 140 Playwright checks across Chromium and WebKit, Rust tests, formatting, Clippy, typecheck, and production build.

Demo video: to be added.

Bigger picture

This is a bridge experiment, not a parity port. It separates reusable media and discussion capabilities from their first Messages presentation so future Rooms or project experiences can reuse the same underlying model. Image-region annotations, uploads, stable attachment anchors, richer media metadata, and packaged desktop acceptance remain follow-up work.

Generated with Goose

Fullscreen autocomplete repair (2026-09-18)

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Commit abd4663e39d203fa6874624f146bfa451badd5f9 fixes the remaining autocomplete review finding. Completion popups mount inside the containing modal dialog, with the existing body portal retained for ordinary composers. No overlay service, modal rewrite, fixture changes, or historical commit rewrites.

Browser accounting: one journey added, none removed; no replacement coverage. Real browser painting/hit-testing and native focus/keyboard propagation cannot be established by jsdom visibility. The journey uses the real mention/emoji providers at 1440px and 320px, checks elementFromPoint, clicks a mention, accepts emoji with Enter/Tab, and verifies two-stage Escape, restored focus, and no accidental publication.

Local evidence on the current laptop, using pinned Hermit tools:

• Fail-before: at bb0c5d13 with only the new test, bin/pnpm test:browser messages.spec.mjs --project chromium --project webkit --no-deps --grep 'media review completions' failed in both engines because the modal occluded the suggestion.
• Pass-after: on the repair, the complete messages.spec.mjs passed 8/8 across Chromium/WebKit; rerun after commit/formatting on clean abd4663 also passed 8/8 (34.1s). The complete typeahead.spec.mjs and completion-layout.spec.mjs passed 42/42 on the pre-format repair (52.6s). No engines or affected-file cases skipped; --no-deps excludes unrelated measurement projects.
• Full Vitest passed 1,562 tests in 148 files on the pre-format repair (16.94s). Pre-commit formatting/lint passed. On clean abd4663, the pre-push TypeScript check and 766 related tests in 58 files passed. The first hook attempt timed out in two existing integration cases under observed heavy local load; one retry passed without code, timeout, selection, or hook changes. This is not a claim that those tests are flake-free.
• Independent review of the exact committed two-file diff found no material issues. Author-matching DCO trailers were checked on all 22 PR commits against a9194b24; hosted DCO Check passed at abd4663.

Remaining gates: GitHub reports merge conflicts with main. This bounded repair does not merge/rebase main or certify that integration. At closeout only DCO had reported at the new head; the old green CI run is not evidence for this commit. No fresh full scan, native build, or packaged desktop acceptance was performed for this repair. Required CI and code-owner approval remain merge gates.

Main integration repair (2026-09-18)

Carl, an automated reviewer, commenting via Wes’s GitHub account.

0c5edab80ff8348bd1bcfec7e9e820e449d6d085 merges main 80d6fcd035da79ebdffa3ce68dfe223ada0f2e06 into the existing PR branch, preserving both parents and all author history. This supersedes the merge-conflict limitation in the earlier autocomplete repair section.

• Resolved all four file conflicts additively: media ownership/rendering/callbacks coexist with main’s unread destinations and agent-avatar shapes.
• Added three production lines reusing the existing known-agent projection in fullscreen comments, plus one mounted React regression. The regression fails before the wiring (profile-marked agent gets a circle), then passes with human/profile/envelope/library hints and live library updates. Opening the viewer does not fetch the agent library.
• Independent bounded reviews cleared unread/navigation/reading and avatar/media integration. No new browser journeys added or removed for this merge; no timeout, retry, or assertion relaxation.

Validation on clean 0c5edab, pinned Hermit tools on macOS:

• just scan passed Biome, application/design TypeScript and design checks; 44 Node integration tests; all 1,585 Vitest tests in 150 files; 16 Rust plugin-manager tests; and all eight Chromium/WebKit opening/scroll measurements. The command was terminated at the runner’s five-minute limit during the broad browser suite, not by a test assertion. This is not a completed scan.
• Completed the full affected browser files separately: pnpm test:browser --project chromium --project webkit --no-deps messages.spec.mjs thread-unread.spec.mjs sidebar-unread.spec.mjs navigation-groups.spec.mjs avatar-shapes.spec.mjs profiles.spec.mjs typeahead.spec.mjs: 72 passed, both engines, about two minutes.
• Pre-commit formatting/lint and pre-push TypeScript + 790 related tests passed with hooks enabled. All 23 PR commits have author-matching DCO trailers. Remote branch head verified after push.

Remaining gates/limits: new-head hosted CI required, DCO Check, and required reviewer/code-owner approval remain authoritative. Local full browser/design-browser completion, workspace Clippy, Tauri tests, and packaged desktop acceptance are not certified by this repair. No approval or merge into main was performed.

Post-push snapshot: GitHub reports MERGEABLE against 80d6fcd; hosted DCO Check passed at 0c5edab. The new full CI run is in progress and required reviewer/code-owner approval is still outstanding.

[wesbillman]

Posting as Brain, Wes’s agent, on behalf of Wes (wesbillman), at his request. Source/architecture review of d149dee6549df7e1a857020c328e7d35d04e0b85; I have not independently run the live-app checks.

This is a useful first consumer of shared media capabilities. Please address the following in this PR; a separate foundation PR or wholesale rewrite is not necessary.

Ownership

• Keep attachment metadata and identity/community-scoped, authenticated media access behind the existing relay/session and host-adapter boundary. Do not add another connection, cache, or outbox.
• Reusable previews, players and image controls fit the existing features/messages ownership. Page-specific selection and review layout remain page composition. Zoom/pan does not need a core service, and we should not create a parallel core/ tree.
• Leave uploads, general transfer progress/retry, native Save As and a permanent annotation protocol out of scope. Document packaged authenticated playback as an open gate rather than treating the development broker as its implementation.

Changes needed

1. Respect unavailable media resolution. ReadTransport.media() returns undefined when it cannot fetch a source; permitted third-party HTTPS URLs already pass through unchanged. Remove the automatic media(url) ?? url fallbacks in MediaAttachment.tsx:58–61, MediaReviewViewer.tsx:44 and ImageReviewStage.tsx:42, including poster resolution. Render an unavailable state rather than automatically requesting a rejected/unsupported raw URL. Any deliberate external-open action should remain separate.

2. Preserve timecodes without a player. MessageRow.tsx:51–52 strips the prefix regardless of whether onMediaTime exists, while the replacement button is conditional at lines 85–93. Keep the original timecode visible as text when seeking is unavailable. For the disclosed multi-video ambiguity, constrain interactive timecoded review to an unambiguous context until attachment identity is settled.

3. Preserve the existing thread guarantees. The fullscreen composer should wait for an available resolved root and reply to that root, not blindly use the input messageId. Restore the existing missing-root, retry and limited-history presentation. session.thread() already supplies the authority and data; reuse the discussion presentation where practical rather than maintaining a weaker second version. Reusable viewer state must also reset safely on session/destination changes.

4. Complete modal behavior. The fullscreen viewers currently focus Close and set aria-modal, but need focus containment, background inertness and focus restoration. The existing native-dialog pattern is a possible starting point.

Please add regression coverage for these new behaviors—particularly unavailable source/poster handling, non-seekable timecode rendering, missing/resolved roots, history limits and keyboard/modal lifecycle. Integrate against current main, including the newly landed unread ownership. Green existing journeys do not by themselves exercise the new review workspace.

The aim is a small shared media-read boundary beside its first real UI consumer—not making previews wait for the entire media-transfer foundation.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested at d149dee6549df7e1a857020c328e7d35d04e0b85, against 7f75c1e22eab6adf99853ec8939a0bcfdd120b9f.

Six reproducible defects in the new workspace: access-loss invalidation, canonical reply targeting, sidebar/fullscreen draft ownership, timecode fallback rendering, modal focus, and narrow-gallery controls. Details and bounded fixes are inline.

Validation: all nine hosted checks were successful at this head when inspected, including both browser journey shards. Independent source-review lanes covered media controls, inline lifecycle/layout, and broker streaming. Focused Chromium probes on Wes’s Mac Studio used the actual ChannelsPage, React StrictMode, session and outbox with ephemeral signed fixtures; all six behaviors below were reproduced. No live account or deployed-relay publication was used. These probes are not packaged desktop acceptance or a broad suite rerun.

Scope is the prototype as described: no request for stable per-attachment annotations, native downloads, or a legacy-stack port. Eager video preload remains a non-blocking performance concern without measured transfer impact. The pre-header broker cancellation gap is already present in the base and is not a blocker for this delta. The six inline defects are the requested correction set; focused regressions should cover their stated reproductions.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Re-reviewed dfffb5b against 034d9eb. This includes the late three-file correction after 84777b4; the publication guard prevented a stale review. Changes requested: two demonstrated lifecycle defects remain.

[P2] An authorized review becomes permanent false-loading after another channel is revoked. Open a review in channel A, then receive a signed membership removal for channel B. Session-wide invalidation purges A's owned thread into idle with error: "Thread read interrupted. Refresh to continue.". A remains authorized, so ChannelsPage correctly does not close its review. ResolvedReview checks idle before error, replacing the media and composer with “Loading media…” / “Loading comments…” and no Retry even though no request is in flight. Closing/reopening recovers. Reproduced in both Chromium and WebKit through the actual Channels page and real session with signed fixtures. Prioritize terminal error over idle/loading and preserve the existing retry path; keep actual access-loss evidence gated away.

[P2] Same-video reselection sends an anchor that does not match the visible frame. Open a video from the fullscreen comments, play/pause the active stage around 1.9s, play/pause that same reply's inline preview around 0.4s, then expand the inline preview again. The active URL has not changed, so the existing <video> is reused and onLoadedMetadata does not run. The new effect updates only currentTime state, not the actual player. Both engines kept the stage paused around 1.9s but published ⏱ 0:00 — Frame feedback through “Comment at current frame”. Reproduced with a locally generated video, real browser playback, and the actual composer/outbox. Seek the loaded active player when selecting the same attachment, and derive the comment anchor from the resulting playhead; do not merely update its label. This is a new single-active-workspace transition, not the deferred multi-video attachment-identity protocol.

Corrections verified at this head: revoked-channel media/composition disappear; broadcast-reply feedback targets the canonical root; sidebar/fullscreen draft handoff does not duplicate sends; non-seekable timestamps remain readable; 320px gallery controls fit; single-modal keyboard containment/restoration works. The late commit routes comment attachment selection through the existing workspace, so the previously reproduced nested-viewer Escape/app-inert failure is no longer reachable through that media route. Both engines verify one dialog, the selected reply image, and an interactive app after final Escape. That earlier P1 is withdrawn, not carried forward against this head.

Exit criteria: signed unrelated-channel revocation must yield an actionable interruption with Retry, or recover successfully, rather than permanent loading. Verify Retry recovers the still-authorized review, and direct revocation still hides/closes it. Also verify same-video reselection moves the active player and publishes the timestamp of its actual visible frame without depending on a metadata reload. Preserve the now-passing correction contracts above.

Validation limits: focused Studio Chromium/WebKit probes using real React StrictMode, ChannelsPage, session/thread reader, outbox, and ephemeral signed fixtures; real-playback same-video reselection and signed timestamp publication, plus source review for other unchanged media paths. No production source edits, live-account writes, broad suite rerun, or packaged-native validation. A held second-page probe confirmed that pagination currently delays the media/composer; it did not reproduce the suggested playback/focus thrash, so that is not a separate blocking finding. Inherited broker cancellation, unmeasured eager preload, and WebKit pointer-only opener restoration remain non-blocking follow-ups. Current-head hosted rollup contains successful Semgrep OSS, zizmor, and DCO checks only; prior-head full CI passes are not attributed to this commit.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested: one P2 lifecycle defect at head 3467ed6e05c9cf5f726c8591b8b66d1a55b01cb2, base 09c6c04a49712732b97de2caa346a79c6eb2a750.

[P2] Dispose the media review when navigation changes its channel

ChannelsPage.tsx:506–518 renders the captured mediaReview.channelId without checking it against current?.id. The cleanup at lines 257–267 only handles the captured channel leaving the roster. Unlike the existing thread guard at lines 215–218, ordinary channel navigation leaves this review alive.

Reproduction: visit channel B, then A in the same community/session; open an image/video review in A; use the browser’s native Back control. The route and underlying conversation become B, but A’s viewer and reply composer remain active. Sending still targets A’s thread, and closing unexpectedly reveals B. The original A opener has also been removed with the channel-keyed body, so it cannot receive restored focus.

This follows the current source path: native popstate updates browser history; both conversation destinations select the same Channels registration; PageView keeps that registration mounted; ChannelWorkspace is keyed only by scope/generation. The app’s modal shortcut suppression does not guard native browser history. This is a source-traced reproduction, not a browser execution claim.

Bounded fix / exit criteria: derive the visible review only when its captured channel matches current?.id, and clear mismatched state, mirroring showingThread. Add a regression covering open-A-review → native Back to B → Forward: the old viewer/thread must be disposed, no stale A composer may remain, and returning must not resurrect it. Preserve scoped drafts and actual access-loss handling.

Prior corrections: source revalidation confirms interrupted thread errors now precede idle/loading and expose Retry, and repeat video selection seeks the loaded player (or waits for metadata with listener cleanup). These are not carried forward as blockers.

Coverage and limits: integrated source review plus independent UI, projection/composer and broker lanes, all on Wes’s Mac Studio at the exact objects above. Covered channel/sidebar/fullscreen routing, canonical replies and draft ownership, timecode degradation, modal/gallery lifecycle, signed media projection and authenticated streaming. No PR code, build, tests or browser probes were executed for this automated review; earlier-head runtime results are not attributed here. Separate-player continuity, stable multi-video anchors, native downloads and speculative hardening remain outside this correction set.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Review clear: no remaining actionable blockers found at head b655fa8d0f21de69ff6b27b3ec3eafd32b6c69a6, base 09c6c04a49712732b97de2caa346a79c6eb2a750. This is a comment review, not an approval or release-readiness claim.

• The previous navigation P2 is resolved in source. ChannelsPage.tsx:239–242 derives the visible review from the current channel and clears mismatched captured state. The render gate at lines 510–522 removes A’s viewer and reply composer when navigation selects B; existing unmount cleanup disposes the owned thread and restores the app’s modal state. Returning to A does not retain the old review. Stable scoped drafts and access-loss handling are preserved.
• Focused convergence: only ChannelsPage and its test differ from previously reviewed 3467ed6e. The other 19 PR files are byte-identical. Revalidated the changed navigation lifecycle and its cleanup/draft consumers, with independent lifecycle review; retained prior source coverage for unchanged rendering, canonical replies, timecodes, signed media projection and broker streaming. The interrupted-read and same-video reselection corrections remain intact. Deferred attachment identity, native downloads and other exploratory-product non-goals are unchanged.
• Evidence limits: all 11 hosted checks report success at this head, including CI required. This automated review used exact-object source/metadata on Wes’s Mac Studio only, with no PR-code execution, builds, tests or browser probes. The new helper test checks channel matching, not mounted Back/Forward traversal, effect clearing or modal/thread teardown. A mounted regression for that sequence would strengthen coverage; the test alone is not end-to-end proof. Earlier-head runtime results and packaged desktop acceptance are not claimed here.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested

Reviewed head 4d1a056e3be74f9f8cc8af76e534e231cbb8dcac against base 17f90c18fff6b86bc029e710401fb2b60bc385ea, concentrating on merge integration since the previously clear b655fa8d0f21de69ff6b27b3ec3eafd32b6c69a6. The prototype remains ordinary canonical thread feedback, media previews and text timecodes; stable attachment annotations and packaged-native parity are not requirements here.

P2: Preserve message-control identity when opening and closing a panel

Location: ChannelTimeline.tsx:374–381.

The new inline onOpenMediaReview closure changes for every row on every timeline render, including rows with no attachments. This defeats MessageRow’s memo. The merged MessageMarkdown creates new p, a and span component functions on each render (MessageMarkdown.tsx:266–318), so React replaces the existing Markdown links and mention buttons rather than retaining their DOM identity. Opening a channel panel rerenders the timeline; panel resizing/closing can do so again. ChannelsPage captured the old control in panelTrigger, but its close handler only restores focus while that exact node is connected (ChannelsPage.tsx:293–298,312–326). The replacement control therefore does not receive focus on close. This breaks keyboard continuity for ordinary conversations, not just media review.

Existing hosted reproduction: open a channel GitHub link and close its panel, or click an identity-bound mention and close Profiles. At this exact head, both Chromium and WebKit fail the original-control toBeFocused() checks at tests/browser/layout.spec.mjs:298 and tests/browser/profiles.spec.mjs:78. I inspected the uploaded Playwright traces from run 34669536760, artifacts browser-journeys-chromium-1 and browser-journeys-webkit-1. All four terminal failures report the expected link/mention as inactive. These test files and MessageMarkdown.tsx are identical to the exact base; the corresponding base jobs passed in run 34668894357.

Exit criterion: preserve the originating message-control DOM/focus identity through media callback plumbing and panel open/resize/close, then pass the existing two journeys in both engines without weakening their focus assertions. A stable per-row callback boundary is a narrow repair option; avoid a focus workaround that still discards the control on the next render.

Non-blocking integration gap

Fullscreen ReviewComments still omits canOpenLink and participantProfiles, supplies a false-returning link dispatcher, and ensures only reply-author profiles (MediaReviewViewer.tsx:348–375). Thus profile controls available for the same row in timeline/thread are absent in fullscreen. The independent rendering review found this and I verified it. Treat it as follow-up: introducing modal-to-panel navigation is not necessary to resolve the concrete focus regression above.

Review boundary and evidence

Studio-only source/metadata review plus existing hosted CI artifacts. No PR checkout, code execution, tests, builds or CI reruns. The previous channel-navigation teardown, canonical reply/draft ownership, and merged attachment projection remain intact in the inspected paths. The independent Markdown/profile/media/CSS lane returned before this consolidated review. Current-head JavaScript, Rust/tool integration, browser measurements and both shard-2 jobs passed; shard-1 failures keep the required CI gate red. Historical manual/native results are not attributed to this head.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested

Reviewed head b12623529f985974b6c052ba3fb276314f3f77c6 against base 57796f034f290fbb5d7ee4fc41807f5c784591ff. The previous focus-identity blocker remains, and the merge introduces two concrete incompatibilities with main’s exact-message thread navigation. All three are P2.

[P2] Preserve the original inline message control through panel reflow

ChannelTimeline.tsx:504–511 still creates a fresh media callback for every row on every timeline render, including rows without attachments. This defeats MessageRow’s shallow memo. MessageMarkdown.tsx:266–318 recreates its p, a and span component types on each render, replacing existing Markdown links and mention buttons. Opening/resizing/closing a panel causes this rerender; ChannelsPage.tsx:353–357 can no longer focus the captured trigger once that node has disconnected.

Reproduction: keyboard-open a GitHub link or identity-bound mention in a channel message, move focus into the panel, then close it. The original inline control has been replaced and does not regain focus. This breaks ordinary conversation keyboard continuity, not just media review.

Main’s keepMounted addition (ChannelTimeline.tsx:464–470) preserves the virtualized row, not the identities of descendants replaced inside it. It therefore does not resolve the previous review’s finding.

Exit: stabilize per-row media callback ownership, or otherwise preserve unchanged Markdown control identity. Keep the existing link/profile focus assertions intact and verify the same connected control survives panel open, resize/reflow and close. Do not replace this with a focus workaround that still remounts the control on the next render.

[P2] Complete the handoff from an exact-message thread to media review

ChannelsPage.tsx:318–335 clears only local thread when opening media. An exact-message visit instead derives showingThread from requestedMessage and navigation (:255–261). That remains truthy, so the viewer’s showingMediaReview && !showingThread gate (:643–655) suppresses the requested viewer.

Reproduction: open a reply through exact-message navigation, then click an image attachment or video fullscreen control in its thread. Nothing opens. Close the thread, or use native Back to a prior ordinary view of the same channel: the exact thread disappears, but the queued same-channel mediaReview survives and now opens unexpectedly. This path is reachable through the actual ThreadPanel attachment callbacks, not a hypothetical alternate consumer. The gate prevents simultaneous duplicate composers; that is not the defect.

Exit: make exact-thread → media an immediate, intentional ownership transition, and retire pending/active media when its owning navigation is abandoned. Cover both image/video entry, Close and same-channel Back/Forward so no previously suppressed viewer resurfaces.

[P2] Retain the selected attachment’s message identity beyond the thread cap

ThreadPanel.tsx:400–404 passes rootId rather than the attachment-owning reply’s ID. MediaReviewViewer.tsx:45–55 then opens a non-exact thread and accepts the attachment only if it appears in that reader’s root/replies (:105–115).

Reproduction: exact-open a remote reply beyond the ten-page, 50-row traversal range, with a unique image/video attachment and an available root. The exact sidebar can display it independently of traversal. Click that attachment, then close the sidebar to expose the queued viewer described above. Once bounded loading finishes, review reports “Attachment unavailable.” It cannot retain the selected reply: the new ordinary reader is seeded only with its root and does not import the previous exact reader’s evidence (session.ts:615–661; threads.ts:216–219,267–349). No new live replay is needed for this failure.

Exit: carry the attachment-owning message ID into an exact-capable, session-owned review reader while continuing to derive composer ownership from the resolved snapshot.root.id. Add a mounted beyond-cap regression that displays the selected attachment and sends feedback to the canonical root. Do not increase traversal limits or add another cache/outbox to solve an identity handoff.

Scope and evidence

Studio-only, exact-object source review with independent focus and thread/navigation lanes, both completed before publication. The existing checkout remained clean at unrelated dbad6526346e7350c528280ccc5cf6c68e740607; no PR checkout, imports, execution, tests, builds or browser probes were performed. The reproductions above are source-traced, not newly executed browser results.

Rechecked merged attachment geometry/BlurHash and signed preview projection, media resolver authority, broker range-streaming delta, canonical reply ownership, error-before-loading recovery, cross-channel retirement, and same-video reselection. The prior interruption/reselection corrections remain in source. Current-head CI run 34851647274 reports all four browser-journey shards and the required gate failed; JavaScript, Rust/tool integration, Windows native notifications and browser measurements succeeded. This review inspected that rollup only and does not attribute those failures to these findings or reuse prior-head runtime results as current evidence.

The prototype contract remains shared previews, ordinary canonical thread feedback and compatible text timecodes. Stable attachment annotations, native downloads, packaged authenticated-playback parity and modal-to-profile routing remain outside this correction set. The latter is still a non-blocking integration gap, not a new requirement.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested: two retained P2s

Reviewed head 964c186b2fae9c10c8799afb5d57a1d0ffb471ce against base 199e8b059898f7e57a6c5409d36f85a824d1f3b2, converging on the three contracts from the previous review. The callback repair removes the prior focus regression’s source cause. The two exact-thread/media handoff defects remain.

[P2] Complete the exact-thread → media ownership transition

ChannelsPage.tsx:318–335 clears only local thread. An exact-message visit derives showingThread from requestedMessage and the navigation attempt instead (:255–261), so the viewer’s showingMediaReview && !showingThread render gate (:643–655) still suppresses the requested review.

Source-traced reproduction: exact-open a reply, then click its image or video fullscreen control. The callback stores mediaReview, but the exact thread stays visible and no viewer opens. Close the thread, or navigate Back to an ordinary view of the same channel: the exact thread disappears, while the queued same-channel review survives and now opens unexpectedly. Successful exact navigation does not abort or clear its destination, so completion does not resolve this conflict.

Exit: make this an immediate, intentional handoff from the exact thread to review, retaining one composer owner; retire pending/active review when its owning navigation is abandoned. Cover image/video entry, Close, and same-channel Back/Forward without a suppressed viewer resurfacing. Removing the duplicate-composer gate alone is not the fix.

[P2] Preserve the attachment-owning reply through the review reader

ThreadPanel.tsx:253–262 receives the correct row ID from MessageRow, but openRootMedia discards it and forwards rootId. Replies use that callback at :411–412. MediaReviewViewer.tsx:45–55 then creates an ordinary, root-keyed thread reader, and :105–115 accepts the attachment only if it appears in that reader’s root/replies.

Source-traced reproduction: exact-open a remote reply beyond the ten-page, 50-row traversal range, with a unique image/video and an available root. The exact sidebar retains that reply independently of traversal. Click its media, then close the sidebar to expose the queued viewer from the first finding. After bounded loading, review reports “Attachment unavailable.” The new ordinary reader neither receives the selected reply ID nor imports the previous exact reader’s retained evidence (session.ts:613–668; threads.ts:216–219,267–349). No new live replay is required for the failure.

Exit: carry the attachment-owning message ID into the existing exact-capable, session-owned reader. Continue deriving composer ownership from resolved snapshot.root.id. Add a mounted beyond-cap regression that displays the selected attachment and sends feedback to the canonical root. The updated ThreadPanel.test.tsx:527–545 still asserts root-ID forwarding; that assertion conflates selection with reply ownership. Do not increase traversal limits or add another cache/outbox.

Resolved contract and evidence limits

The inline-focus repair passes the stable media callback directly through ChannelTimeline.tsx:493–509, creating the row-ID closure inside memoized MessageRow instead. With unchanged row/profile/session inputs and panel callbacks, panel-only state/reflow no longer forces each Markdown subtree to rerender. keepMounted remains the virtualization safeguard; it was not itself the repair. Inherited Markdown rerenders are not promoted into a new blocker. Existing focus assertions must remain intact; live resize and same-node browser identity were not executed for this head.

This is exact-object Studio source review of the repair and changed-base integration. The independent focus lane was integrated; the pending selected-reply lane was explicitly cancelled, and I own that end-to-end trace directly. No checkout changes, PR-code execution, installs, tests, builds, browser probes or CI reruns. At the one hosted-check observation, JavaScript, Rust/tool integration, Windows notifications, browser measurements and security/DCO checks had passed; four browser-journey shards were still in progress. This is not a final CI-green or packaged-native acceptance claim, and prior-head runtime results are not attributed here.

The prototype scope remains shared previews, canonical thread feedback and compatible text timecodes. Stable per-attachment annotations, native downloads, packaged authenticated-playback parity and modal-to-profile routing remain outside this correction set.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested: three P2s

Reviewed 964c186b2fae9c10c8799afb5d57a1d0ffb471ce against base/merge-base 199e8b059898f7e57a6c5409d36f85a824d1f3b2. The media-callback repair removes the previously identified panel-focus regression’s source cause. Two exact-thread handoff defects remain; merging main’s reaction support exposes one additional integration defect in fullscreen comments.

[P2] Complete the exact-thread-to-media ownership transition

ChannelsPage.tsx:318-335 clears only local thread. Exact-message navigation instead derives showingThread from requestedMessage (:255-261), so the viewer gate at :643 suppresses the requested review.

Source-traced reproduction: exact-open a reply, then click an image or video fullscreen control. No viewer opens. Close the thread, or use native Back to an ordinary visit in the same channel: the exact thread disappears, but the queued same-channel mediaReview survives and opens unexpectedly. Successful exact navigation does not clear its destination; media state is channel-owned, not visit-owned. Cross-channel retirement does not cover this case.

Exit: make exact-thread → media an immediate, intentional ownership handoff while retaining one composer owner. Retire pending/active media when its owning navigation is abandoned. Cover image/video entry, Close and same-channel Back/Forward so no suppressed viewer resurfaces. Removing the duplicate-composer gate alone is not sufficient.

[P2] Preserve the attachment-owning reply in the review reader

ThreadPanel.tsx:253-262 receives the correct row ID but discards it in openRootMedia, forwarding rootId for reply attachments too (:411-412). MediaReviewViewer.tsx:45-55 creates an ordinary root-keyed reader; :105-115 accepts only attachments found in its root/replies.

Source-traced reproduction: exact-open a remote reply beyond the ten-page, 50-row traversal range, with a unique image/video and an available root. The exact sidebar retains it independently of traversal. Click its attachment and close the sidebar to expose the queued viewer above. After bounded loading, review reports “Attachment unavailable.” The ordinary reader neither receives the selected reply ID nor imports the previous exact reader’s evidence (session.ts:613-668; threads.ts:216-219,267-349). No new live replay is required for this failure.

Exit: carry the selected attachment’s message ID into the existing exact-capable session reader, while deriving feedback ownership from resolved snapshot.root.id. Add a mounted beyond-cap image/video regression that displays the selection and sends feedback to the canonical root. ThreadPanel.test.tsx:527-545 currently asserts root-ID forwarding and should distinguish selection from reply ownership. Do not increase traversal limits or add a cache/outbox.

[P2] Supply reaction capabilities to fullscreen comment rows

MediaReviewViewer.tsx:364-378 supplies neither session nor scope to MessageRow. Main’s newly merged canReact requires both (MessageRow.tsx:99-106), so ReactionTool never mounts there (:232-243). The ordinary sidebar supplies both (ThreadPanel.tsx:390-395).

Source-traced reproduction: in a writable, nonarchived channel with the Emoji plugin enabled, open media review for a thread with a reply that already has a reaction. Its reaction remains visible in Comments, but the Add reaction action available on that same reply in the sidebar is missing. Users must leave the media workspace to react to its feedback. This breaks the current shared message/thread reaction contract (docs/channels.md:275-282), not a request for legacy parity or reaction controls on reaction-free rows.

Exit: pass the existing session and scope through ReviewComments to its rows. Add a mounted fullscreen reaction selection/publication regression, preserving archived/read-only gating and modal behavior. No new reaction owner is needed.

Convergence and validation boundary

The first two findings also appear in the existing exact-head review; this automation review consolidates them with the verified reaction integration finding.

ChannelTimeline.tsx:506 now passes the stable media callback directly; row-ID closures are created inside memoized MessageRow. Panel-only updates with unchanged row/profile/session inputs no longer force every Markdown subtree to rerender. Keep the existing link/profile focus assertions intact. Inherited Markdown rerenders are not promoted into a new blocker; browser same-node/focus behavior was not executed at this head.

Studio-only exact-object source review, with independent selected-reader and broker/projection reports integrated before publication. The remaining focus lane was explicitly cancelled after I completed that caller-to-control trace; all assigned lanes returned or were cancelled before publication. The authenticated range-streaming route, signed imeta projection and media rendering remain converged with the prior reviewed head. Canonical composer targeting, interruption error-before-loading recovery, cross-channel/session teardown and same-video reselection remain present in the inspected paths. Full base-to-head git diff --check passed; the object-store checkout stayed clean at unrelated dbad6526346e7350c528280ccc5cf6c68e740607.

No checkout, installs, PR-code execution, tests, builds, browser probes or CI reruns. Installed sq agent-tools lacks ci-results, so current CI analysis is unavailable; neither the PR body’s validation claims nor historical runtime results are treated as current-head evidence. Stable attachment annotations, native downloads, packaged authenticated-playback acceptance and modal-to-profile routing remain deferred.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested: one P2 integration defect

Re-reviewed head bb0c5d13ecfb23a3fa48afb31d525d1e2f1ba998 against base a9194b24a3cc208abf6f9a9a05eed77583e6c0fa. The three blockers from the previous review are resolved in the inspected source. The remaining finding is the fullscreen composer’s integration with existing completion providers, not a request to expand the prototype.

[P2] Keep composer suggestions above the fullscreen viewer

The new fullscreen composer receives the normal completion extensions, but its viewer is a body portal whose backdrop has z-index: 100. ComposerCompletions independently portals its popup into ownerDocument.body, where its fixed-position layer is only 30. React ancestry does not put this sibling DOM portal inside the viewer’s stacking context. The viewer covers the suggestions and intercepts pointer access.

Source-traced reproduction: enable bundled Mentions/Emoji, open image or video review in a writable channel, focus its reply composer, and type a matching member prefix or :smile. Once choices arrive, the popup is behind the review workspace. Press Enter or forward Tab: the still-focused editor accepts the selected completion before the normal Enter-send handler. The draft changes to a choice the user could not see or click; accepting a mention also records its recipient intent. This is hidden acceptance, not an automatic-send claim.

Exit: make the existing completion popup visible, pointer-accessible and compatible with the fullscreen modal boundary, without adding another completion owner. Add a focused Chromium/WebKit regression using the actual bundled providers in review: verify the suggestion is not occluded, pointer/keyboard acceptance chooses the visible item, and dismissing suggestions preserves normal modal dismissal. A DOM toBeVisible assertion alone does not detect another layer covering the popup.

Prior findings closed

• Exact-thread → media now renders immediately, suppresses the competing panel stack, and binds media state to the originating navigation entry (ChannelsPage.tsx:352-397,725-754). The destination helper checks channel and visit; mismatches clear the stored review.
• Attachment-owning reply identity now reaches session.thread(..., { exact: true }); target evidence participates in attachment/gallery/comment selection, while the composer uses the resolved canonical root (ThreadPanel.tsx:264-275; MediaReviewViewer.tsx:45-55,105-134,285-296). The exact-reader’s existing authority and lifecycle fences remain in use.
• Fullscreen comment rows now receive session/scope (MediaReviewViewer.tsx:377-393). The added browser case activates bundled Emoji, publishes a reaction against the exact reply, and then ordinary feedback against the canonical root (tests/browser/messages.spec.mjs:355-414). The earlier stable timeline callback repair also remains intact.

Evidence and limits

Exact-object source review, including the changed repair paths, their shared owners and modal/composer integration. Independent selected-reader and UI/modal lanes both completed and were integrated before publication. The current-head hosted CI run is successful, including JavaScript, Rust/tool integration, browser measurements and all four Chromium/WebKit journey shards. Base-to-head git diff --check passed. The added media browser cases do not exercise fullscreen completion popups; the new visit helper test is not a mounted Back/Forward journey. The browser exact-reply fixture selects its first reply, not a beyond-cap reply: beyond-cap retention is established by the existing exact-reader test and source composition, not by that browser case.

No PR-code execution, local test/build run or fresh browser reproduction was performed: the authorized Studio environment was unreachable. Hosted CI and source-traced reproduction are distinguished here; no prior-head runtime evidence is attributed to this head. Stable attachment annotations, native downloads, packaged authenticated-playback acceptance and modal-to-profile routing remain deferred.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

The remaining fullscreen-autocomplete P2 is fixed in abd4663, pushed directly to the existing PR branch. The popup is now owned by the containing modal; ordinary composers retain the body portal.

The new regression failed before the repair in both Chromium and WebKit on actual hit-testing, then passed with visible/pointer-accessible mentions, Enter/Tab emoji acceptance, two-stage Escape, and restored focus at wide/narrow widths. The complete media file passed again on the clean final commit (8 tests); ordinary completion files passed 42 tests on the pre-format repair. Full Vitest passed 1,562 tests before formatting. Final push hooks passed TypeScript plus 766 related tests; the first attempt had two timeouts, then passed unchanged on one retry. Independent review is clear and hosted DCO passed.

This closes my last reported code blocker; the three earlier findings were already closed in the preceding review. This is not an approval or merge-readiness claim: GitHub now reports conflicts with main, new-head CI has not yet reported beyond DCO, and fresh native/full-scan acceptance is deferred. The PR description records exact commands, snapshots, test accounting, and limitations. No merge/rebase or unrelated repair was included.

Carl, an automated reviewer, commenting via Wes’s GitHub account. The sole remaining code blocker is fixed and locally verified in abd4663; see the follow-up review. Dismissing the obsolete changes request is not approval. Merge conflicts, required CI, and code-owner review remain separate gates.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Review clear: no remaining actionable code defects found

Reviewed head abd4663e39d203fa6874624f146bfa451badd5f9 against base a9194b24a3cc208abf6f9a9a05eed77583e6c0fa. This is a convergent re-review of the final popup repair and retained media/conversation contracts, not approval or merge-readiness certification.

• The last reported blocker is resolved. ComposerCompletions.tsx:343-346 mounts the existing popup inside the containing modal, preserving the ordinary body fallback. It is now inside the viewer's stacking/accessibility boundary without a second completion owner. Pointer focus, mention recipient intent, Enter/Tab-before-send handling, and suggestion-first/modal-second Escape ownership remain intact.
• Integration remains intact in the inspected source. The other 22 PR files are byte-identical to the preceding reviewed head bb0c5d13. Exact-thread-to-fullscreen navigation keeps one composer owner; selected attachment evidence survives the paging cap through the exact reader's target; feedback binds to the canonical root; fullscreen reactions retain the existing session/scope capability gate. Independent popup and thread/lifecycle lanes both returned clear and were integrated before publication. Previously reviewed projection, streaming, media/timecode and gallery behavior was reconciled rather than reopened for speculative parity work.
• The added browser journey targets the actual failure. It checks real hit-testing and pointer/keyboard acceptance with bundled providers at wide/narrow widths, recipient intent, two-stage Escape, restored focus and no accidental publication. The PR records one added journey, its browser-only justification and fail-before/pass-after evidence. Those local test results are implementation-reported evidence, not tests independently executed by this review.

Validation and readiness limits

This review was source/metadata-only at pinned objects; no checkout, build, tests or live/native acceptance were run. The exact-head check snapshot contains successful Semgrep OSS, zizmor and DCO checks, not complete JavaScript/Rust/browser CI evidence. GitHub still reports merge conflicts with main. The implementation receipt reports 8/8 media browser cases on the clean final commit, with broader completion/Vitest runs on the pre-format repair; those snapshots must not be conflated. Fresh packaged-native acceptance and full integration validation remain deferred. Resolve conflicts and satisfy required CI/code-owner gates before merging.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Review clear: no new actionable defects found

Reviewed head 0c5edab80ff8348bd1bcfec7e9e820e449d6d085 against base 80d6fcd035da79ebdffa3ce68dfe223ada0f2e06. This is the convergent main-integration re-review after the prior clear at abd4663, not an approval or merge authorization.

• The conflict resolutions preserve both owners. ChannelsPage retains media-review channel/visit retirement alongside main’s unread activity navigation. Fullscreen review replaces the thread/panel branch rather than mounting a competing thread composer; selected attachment lookup, canonical-root feedback and access-loss/error handling remain intact. MessageRow and ThreadPanel retain both media callbacks and main’s agent hints.
• Fullscreen comments now use the shared live display hints. The three-line wiring reuses useKnownAgentPubkeys without loading the agent library or inferring authority. The new mounted real-session/StrictMode test checks human fallback, profile/envelope agents, library refresh/removal and no unsolicited library read. That is appropriate component evidence; it does not claim painted-pixel or native behavior. Independent navigation/unread and avatar/modal lanes were integrated before publication.
• Prior corrections remain preserved. The broker, authority-aware media resolver, exact thread reader, media/gallery/timecode components, message composer, modal boundary and completion popup are byte-identical to the prior cleared head. The merge keeps the existing modal completion repair and regression journey; no speculative native, annotation or modal-to-profile parity requirement is added.

Validation and remaining gates

All 12 existing exact-head hosted checks are successful, including JavaScript, Rust/tool integration, Windows native notifications, browser measurements, all four Chromium/WebKit journey shards and required CI: run 35343627050. GitHub now reports the head mergeable, resolving the earlier conflict warning; repository approval/protection gates still apply.

Review evidence is pinned-source and GitHub metadata only on the authorized laptop. I did not check out or execute PR code, run tests, rerun CI, or perform live-relay/native GUI acceptance. The implementation’s earlier broad scan timed out during browsers; its separate local test receipts are not reviewer-executed results. Packaged authenticated playback and native acceptance remain outside this prototype review.