@lovett/ui 0.1.0 → 0.2.3

package/src/detail/__tests__/activity-pane.test.tsx

@@ -8,7 +8,7 @@
  */
 import { useState } from 'react'
 import { describe, expect, it, vi } from 'vitest'
-import { render, screen, within } from '@testing-library/react'
+import { cleanup, render, screen, within } from '@testing-library/react'
 import userEvent from '@testing-library/user-event'
 import { ActivityPane } from '../activity-pane'
 import type { ThreadComment } from '../../thread/types'
@@ -184,3 +184,220 @@ describe('without a comment backend', () => {
     expect(screen.getByRole('textbox')).toBeInTheDocument()
   })
 })
+
+/**
+ * FU-0019 — the pane is a conduit, and it used to be a leaky one.
+ *
+ * `ActivityPaneProps` declared `onSubmit` and `onReply` and stopped, so three
+ * mutations `<Thread>` already accepted could not be reached through the pane
+ * at all. Nothing errored, which is why it survived a release: `CommentItem`
+ * draws no control for a callback it was not given, so a host shipped an inert
+ * engagement row and a one-line overflow menu while the routes behind them had
+ * no caller anywhere in the browser.
+ *
+ * These assert at the CONTROL, never at the prop. A prop that arrives and
+ * lands nowhere is the same bug one layer further in.
+ */
+describe('ActivityPane — forwarding the thread callbacks', () => {
+  const WIRED: readonly ThreadComment[] = [
+    {
+      id: 'c1',
+      author: { id: 'u1', name: 'Ada Lovelace' },
+      bodyMd: 'Looks right to me.',
+      createdAt: NOW - 60_000,
+      reactions: [{ key: 'up', count: 7, viewerReacted: true }],
+    },
+    {
+      id: 'c-failed',
+      author: { id: 'u2', name: 'Grace Hopper' },
+      bodyMd: 'This one never left the device.',
+      createdAt: NOW - 30_000,
+      state: 'failed',
+      errorText: 'This comment did not send.',
+    },
+  ]
+
+  /** Mounts the pane and opens Comments, which is where `<Thread>` lives. */
+  async function comments(
+    props: Partial<React.ComponentProps<typeof ActivityPane>> = {},
+  ): Promise<HTMLElement> {
+    render(
+      <ActivityPane
+        comments={WIRED}
+        activity={activity}
+        draft=""
+        onDraftChange={() => {}}
+        onSubmit={() => {}}
+        now={NOW}
+        locale="en-US"
+        {...props}
+      />,
+    )
+    await userEvent.click(screen.getByRole('tab', { name: /Comments/ }))
+    return panel('Comments')
+  }
+
+  it('reports a reaction key from the chip the thread drew', async () => {
+    const onReact = vi.fn()
+    const shown = await comments({ onReact })
+    await userEvent.click(within(shown).getByRole('button', { name: 'Agree — 7' }))
+    expect(onReact).toHaveBeenCalledWith('c1', 'up')
+  })
+
+  it('offers a picker, so a reaction can come into existence at all', async () => {
+    const shown = await comments({ onReact: vi.fn() })
+    expect(within(shown).getByRole('button', { name: 'Add a reaction' })).toBeInTheDocument()
+  })
+
+  it('puts Edit and Delete in the overflow menu and reports the comment id', async () => {
+    const onEdit = vi.fn()
+    const onDelete = vi.fn()
+    const shown = await comments({ onEdit, onDelete })
+    await userEvent.click(
+      within(shown).getByRole('button', { name: "More actions for Ada Lovelace's comment" }),
+    )
+    await userEvent.click(screen.getByRole('menuitem', { name: 'Edit' }))
+    expect(onEdit).toHaveBeenCalledWith('c1')
+
+    await userEvent.click(
+      within(shown).getByRole('button', { name: "More actions for Ada Lovelace's comment" }),
+    )
+    const remove = screen.getByRole('menuitem', { name: 'Delete' })
+    expect(remove.getAttribute('data-variant')).toBe('destructive')
+    await userEvent.click(remove)
+    expect(onDelete).toHaveBeenCalledWith('c1')
+  })
+
+  it('recovers a send that failed in its OWN composer', async () => {
+    const onRetry = vi.fn()
+    const shown = await comments({ onRetry })
+    await userEvent.click(within(shown).getByRole('button', { name: 'Try again' }))
+    expect(onRetry).toHaveBeenCalledWith('c-failed')
+  })
+
+  it('carries a comment’s canEdit / canDelete through to the menu', async () => {
+    // The pane forwards `comments` verbatim, so the capability needs no prop
+    // of its own here — but "needs no plumbing" is a claim, and this is the
+    // assertion behind it. Wiring the two callbacks is not enough on its own.
+    const REFUSED: readonly ThreadComment[] = [
+      {
+        id: 'c1',
+        author: { id: 'u1', name: 'Ada Lovelace' },
+        bodyMd: 'Somebody else wrote this.',
+        createdAt: NOW - 60_000,
+        canEdit: false,
+        canDelete: false,
+      },
+    ]
+    const shown = await comments({ comments: REFUSED, onEdit: vi.fn(), onDelete: vi.fn() })
+    // Both refused, no clipboard under jsdom and the pane never forwards
+    // `onCopyLink`, so there is nothing left to put in a menu and no trigger
+    // is drawn. Which is the point: the two items are gone, not greyed.
+    expect(
+      within(shown).queryByRole('button', { name: "More actions for Ada Lovelace's comment" }),
+    ).toBeNull()
+  })
+
+  it('draws both when a comment states no capability — the 0.2.0 render', async () => {
+    // The other half of the default, at the control. `WIRED` sets neither
+    // flag, so a host that upgrades without mapping them loses nothing.
+    const shown = await comments({ onEdit: vi.fn(), onDelete: vi.fn() })
+    await userEvent.click(
+      within(shown).getByRole('button', { name: "More actions for Ada Lovelace's comment" }),
+    )
+    expect(screen.getByRole('menuitem', { name: 'Edit' })).toBeInTheDocument()
+    expect(screen.getByRole('menuitem', { name: 'Delete' })).toBeInTheDocument()
+  })
+
+  it('draws none of them for a host that wires none — the 0.1.0 render', async () => {
+    const shown = await comments()
+    // What FU-0019 measured in a browser: a written reaction is readable and
+    // inert, and there is no picker, so a reaction can never be created.
+    expect(within(shown).getByRole('button', { name: 'Agree — 7' })).toBeDisabled()
+    expect(within(shown).queryByRole('button', { name: 'Add a reaction' })).toBeNull()
+    expect(within(shown).queryByRole('button', { name: 'Try again' })).toBeNull()
+    // The failure itself is still announced; only the recovery is missing.
+    expect(within(shown).getByText('This comment did not send.')).toBeInTheDocument()
+    // And no overflow menu at all: with no Edit, no Delete, no Copy link and
+    // no clipboard under jsdom, `CommentActions` has nothing to put in one and
+    // renders none. In a real browser it holds exactly one line — "Copy text",
+    // the single item that needs no callback — which is what FU-0019 measured.
+    expect(
+      within(shown).queryByRole('button', { name: "More actions for Ada Lovelace's comment" }),
+    ).toBeNull()
+  })
+})
+
+/**
+ * FU-0032 — the Everything feed draws its own tombstone, and it has to agree
+ * with the one the Comments tab draws for the same comment.
+ */
+describe('ActivityPane — a moderated comment in the merged feed', () => {
+  // One tombstone, two removals. Derived from a single base so the ONLY
+  // difference between the two renders is the field under test.
+  const BASE: ThreadComment = {
+    id: 'c-mod',
+    author: { id: 'u1', name: 'Ada Lovelace' },
+    bodyMd: '',
+    createdAt: NOW - 60_000,
+    deletedAt: NOW - 30_000,
+  }
+
+  const REMOVED: readonly ThreadComment[] = [{ ...BASE, moderated: true }]
+  const SELF: readonly ThreadComment[] = [{ ...BASE, id: 'c-self', moderated: false }]
+
+  function feed(list: readonly ThreadComment[]): HTMLElement {
+    render(
+      <ActivityPane
+        comments={list}
+        activity={[]}
+        draft=""
+        onDraftChange={() => {}}
+        onSubmit={() => {}}
+        now={NOW}
+      />,
+    )
+    return panel('Everything')
+  }
+
+  it('says an admin removed it', () => {
+    expect(feed(REMOVED)).toHaveTextContent('Comment removed by an admin')
+  })
+
+  it('still says "Comment deleted" for an author\'s own delete', () => {
+    const shown = feed(SELF)
+    expect(shown).toHaveTextContent('Comment deleted')
+    expect(shown).not.toHaveTextContent('removed')
+  })
+
+  /**
+   * The feed WITHHOLDS the author of a tombstone, exactly as the thread does.
+   *
+   * Found in review. `FeedLine` was given `author` unconditionally, so the
+   * Everything tab printed "Ada Lovelace commented" beside "Comment removed by
+   * an admin" while the Comments tab one click away replaced her byline with
+   * `[removed]` and dropped her avatar to `?`. The same comment answered "who
+   * wrote this" two different ways depending on which tab you were on.
+   *
+   * It was harmless while the line read "Comment deleted" — a deletion nobody
+   * had to account for. FU-0032 is what made it matter: a name beside "removed
+   * by an admin" is a per-author public record of who got moderated, readable
+   * by everyone in the workspace, and it is the one fact the thread render
+   * deliberately refuses to publish.
+   *
+   * Asserted for BOTH removals, because the leak was never specific to
+   * moderation — only its consequence was.
+   */
+  it('withholds the author of a tombstone, on both kinds of removal', () => {
+    expect(feed(REMOVED)).not.toHaveTextContent('Ada Lovelace')
+    cleanup()
+    expect(feed(SELF)).not.toHaveTextContent('Ada Lovelace')
+  })
+
+  it('still names the author of a comment that is NOT a tombstone', () => {
+    const live: readonly ThreadComment[] = [
+      { ...BASE, id: 'c-live', deletedAt: null, bodyMd: 'Still here.' },
+    ]
+    expect(feed(live)).toHaveTextContent('Ada Lovelace')
+  })
+})

package/src/detail/activity-pane.tsx

@@ -26,6 +26,16 @@
  * change — never derived on the client — so this component has no business
  * inferring history from an item, and does not.
  *
+ * ## It owns no thread behaviour either
+ *
+ * Every comment callback it declares is `ThreadProps`' own, forwarded
+ * unchanged to the `<Thread>` below. The pane decides WHERE a control lives —
+ * one composer, outside the panels — and never what one does. That is not a
+ * style preference: a prop it fails to forward is a control a host cannot draw
+ * at all, and three shipped mutations spent a release unreachable that way
+ * (Lightwork FU-0019). What is still not forwarded, and why, is listed on
+ * `ActivityPaneProps`, so the next gap is chosen rather than discovered.
+ *
  * ## Everything is read-only
  *
  * The merged feed interleaves both by time so you can see what happened in
@@ -43,7 +53,7 @@ import { RelativeTime } from '../thread/relative-time'
 import { Thread } from '../thread/thread'
 import { ThreadComposer } from '../thread/composer'
 import { useNowTick } from '../thread/use-now'
-import type { ThreadAuthor, ThreadComment } from '../thread/types'
+import type { ThreadAuthor, ThreadComment, ThreadReactionKey } from '../thread/types'
 import type { ActivityEntry, FieldPerson } from './types'
 
 export type ActivityTab = 'everything' | 'comments' | 'activity'
@@ -106,6 +116,78 @@ export interface ActivityPaneProps {
   onSubmit?: ((body: string) => void) | undefined
   /** A reply. Omitted, the thread offers no reply control at all. */
   onReply?: ((body: string, parentId: string) => void) | undefined
+
+  /**
+   * Forwarded verbatim to the `<Thread>` the Comments tab already mounts.
+   *
+   * These four are here because the pane used to declare `onSubmit` and
+   * `onReply` and stop. `CommentItem` gates its reaction PICKER on `onReact`
+   * and its overflow MENU ITEMS on `onEdit` / `onDelete`; a menu item whose
+   * callback is absent is not rendered, and the reaction chips still render
+   * DISABLED rather than vanishing. (An earlier draft of this docblock said
+   * the whole bar was "NOT RENDERED". That is the rule from `ThreadProps`'
+   * overflow-menu docblock, and it does not generalise to the engagement row —
+   * `reactions.tsx` renders `disabled={!canReact}`.) So a host composing this
+   * pane shipped an inert
+   * engagement row with no picker to open and a menu holding one line, while
+   * the three routes behind them had no caller in the browser at all. Nothing
+   * errored, which is how it survived a release; Lightwork's FU-0019 found it
+   * by opening the surface rather than by reading the source, and the source
+   * understates it.
+   *
+   * WIRING `onEdit` OR `onDelete` IS HALF THE JOB. The callback says the host
+   * has the mutation; `canEdit` / `canDelete` on each `ThreadComment` say
+   * whether this viewer may use it on THAT comment, and the pane forwards
+   * `comments` verbatim, so they arrive with no plumbing here. Set them, or
+   * every live comment in the feed gets an Edit the server will 404 — which is
+   * what forwarding these two without them shipped as, and the same shape as
+   * the `onHideLinkPreview` note below. Absent means the item is drawn, so
+   * nothing this pane renders today disappears on upgrade; that is a
+   * deliberate default and `ThreadComment` argues it.
+   *
+   * `onRetry` is the same omission with one sharper edge: the failed send it
+   * recovers was posted by THIS pane's own composer, so dropping it left the
+   * pane manufacturing a state and offering nobody a way out of it.
+   *
+   * The signatures are `ThreadProps`', unchanged, because a conduit that
+   * reshapes what passes through it is a second contract to keep in step —
+   * and this one is held by two repos. Absent still means no control, so a
+   * host that passes none renders exactly as it did on 0.1.0.
+   *
+   * STILL NOT FORWARDED, deliberately. This list is EXHAUSTIVE against
+   * `ThreadProps` — check it against that interface before adding one, because
+   * a list whose whole purpose is completeness is worse than no list when it
+   * is short: `onVote`, `onCopyLink`, `onCopyText`, `onSelectAuthor`,
+   * `onSelectMention`, `onOpenAttachment`, `resolveAttachmentUrl`,
+   * `onContinueThread`.
+   *
+   * The line is whether a MUTATION becomes unreachable. `onVote` fails it for
+   * a different reason — the pane never exposes `engagement`, so there is no
+   * vote control to receive it and forwarding it would be a dead prop.
+   * `onCopyText` only reports a clipboard outcome; "Copy text" renders without
+   * it. `onContinueThread` falls back to local state, so the button works
+   * unwired. The rest are reads.
+   *
+   * `onHideLinkPreview` USED to be on this list and should not have been: it is
+   * a write in the same pattern as the other mutations, and `link-preview.tsx`
+   * gates its dismiss control on the callback being present. Since the pane
+   * forwards `comments` verbatim — link previews included — a host got
+   * dismissible-looking rows with no route to the mutation. Same shape as the
+   * defect this whole change fixes, caught in review.
+   */
+  onReact?: ((commentId: string, key: ThreadReactionKey) => void) | undefined
+  onEdit?: ((commentId: string) => void) | undefined
+  onDelete?: ((commentId: string) => void) | undefined
+  onRetry?: ((commentId: string) => void) | undefined
+
+  /**
+   * A write, in the same pattern as the mutations above — `link-preview.tsx`
+   * gates its dismiss control on this being present, and the pane forwards
+   * `comments` verbatim, previews included. Without it a host draws rows that
+   * look dismissible and are not. Added in review, not in the original change.
+   */
+  onHideLinkPreview?: ((commentId: string, urlHash: string) => void) | undefined
+
   sending?: boolean | undefined
   composerAvatar?: ReactNode | undefined
   composerPlaceholder?: string | undefined
@@ -131,6 +213,11 @@ export function ActivityPane({
   onDraftChange,
   onSubmit,
   onReply,
+  onReact,
+  onEdit,
+  onDelete,
+  onRetry,
+  onHideLinkPreview,
   sending = false,
   composerAvatar,
   composerPlaceholder = 'Add a comment…',
@@ -255,7 +342,22 @@ export function ActivityPane({
               item.kind === 'comment' ? (
                 <li key={`comment-${item.comment.id}`}>
                   <FeedLine
-                    author={item.comment.author ?? null}
+                    // WITHHELD on a tombstone, matching the thread's treatment
+                    // exactly. `CommentItem` replaces the byline with the
+                    // tombstone label and drops the avatar to `?`; printing the
+                    // name here would mean the same comment answers "who wrote
+                    // this" differently one tab apart.
+                    //
+                    // It matters more since FU-0032 than it did before. A
+                    // neutral "Comment deleted" beside a name was a deletion
+                    // nobody had to explain; "Comment removed by an admin"
+                    // beside a name is a per-author public record of who got
+                    // moderated, readable by everyone in the workspace.
+                    author={
+                      item.comment.deletedAt === null || item.comment.deletedAt === undefined
+                        ? (item.comment.author ?? null)
+                        : null
+                    }
                     at={item.at}
                     now={clock}
                     locale={locale}
@@ -263,8 +365,15 @@ export function ActivityPane({
                       item.comment.deletedAt === null || item.comment.deletedAt === undefined ? (
                         <CommentBody bodyMd={item.comment.bodyMd} />
                       ) : (
+                        // The feed's register, not the thread's: a line in a
+                        // sentence rather than a bracketed placeholder. The
+                        // DISTINCTION is the same one, and it has to be, or a
+                        // reader gets one answer on Everything and another on
+                        // Comments about the same comment (FU-0032).
                         <span style={{ color: 'rgb(var(--text-tertiary))' }}>
-                          Comment deleted
+                          {item.comment.moderated === true
+                            ? 'Comment removed by an admin'
+                            : 'Comment deleted'}
                         </span>
                       )
                     }
@@ -312,6 +421,11 @@ export function ActivityPane({
                   if (parentId !== undefined) onReply(body, parentId)
                 },
               })}
+          {...(onReact === undefined ? {} : { onReact })}
+          {...(onEdit === undefined ? {} : { onEdit })}
+          {...(onDelete === undefined ? {} : { onDelete })}
+          {...(onRetry === undefined ? {} : { onRetry })}
+          {...(onHideLinkPreview === undefined ? {} : { onHideLinkPreview })}
         />
       </div>
       )}

package/src/display-store.tsx

@@ -21,10 +21,21 @@
  * PERSISTENCE IS PER SCOPE. `scope` is whatever partition the host needs —
  * for a lens that is the brand id, because ADR-116 D10 requires brand A's
  * preferences never to surface on brand B. The key is
- * `workspace:<name>:<scope>:display`, matching CLAUDE.md §3's namespacing
+ * `<prefix>:<name>:<scope>:display`, matching CLAUDE.md §3's namespacing
  * rule. Changing `scope` re-reads: the provider does not remount, so an
  * in-flight draft elsewhere in the tree survives a brand switch.
  *
+ * THE PREFIX IS THE PRODUCT, AND ITS DEFAULT IS FROZEN. This package is a
+ * dependency of more than one app on more than one origin, and `workspace` is
+ * only the right first segment for one of them: a host whose own convention is
+ * `lightwork:<area>:<id>:<key>` was getting the one key on its board that read
+ * as somebody else's. So `prefix` is an option — and its default is `workspace`
+ * FOREVER, not because that name is good but because these keys already exist
+ * in operators' browsers. A store holds a preference the operator set; changing
+ * the default segment would not move that preference to a new key, it would
+ * walk past it and open at the defaults. The suite pins the unprefixed key as a
+ * literal for that reason.
+ *
  * READING IS DEFENSIVE. `localStorage` is untrusted input — a hand-edited
  * value, a key left behind by an older build, a private window that throws on
  * access. Every persisted key is checked against the default's TYPE and, when
@@ -117,6 +128,33 @@ export interface DisplayStore<T extends DisplaySettings> {
   readonly storageKey: (scope: string) => string
 }
 
+/**
+ * Everything about the store that is not its settings.
+ *
+ * An OBJECT rather than a fifth positional string, because `allowed` and
+ * `migrations` are both optional and already both objects: a call reading
+ * `createDisplayStore('board', DEFAULTS, undefined, undefined, 'lightwork')`
+ * puts two bare strings at opposite ends of an argument list and names
+ * neither. `{ prefix: 'lightwork' }` says what it is at the call site, and the
+ * next option that earns its place goes beside it rather than becoming a sixth
+ * positional.
+ */
+export interface DisplayStoreOptions {
+  /**
+   * The key's first segment — the PRODUCT, above the store's own `name`.
+   *
+   * Omit it and the key is `workspace:<name>:<scope>:display`, exactly as it
+   * has always been. Pass one and the store moves wholesale onto it, so two
+   * apps sharing this primitive on one origin under the same `name` cannot
+   * read or overwrite each other.
+   *
+   * It is not a migration seam. A store that changes prefix does not carry its
+   * stored settings across; it opens at its defaults on the new key and leaves
+   * the old one behind. Choose it once, when the store is written.
+   */
+  prefix?: string
+}
+
 function isDisplayValue(value: unknown): value is DisplayValue {
   if (typeof value === 'string' || typeof value === 'boolean') return true
   return typeof value === 'number' && Number.isFinite(value)
@@ -127,8 +165,29 @@ export function createDisplayStore<T extends DisplaySettings>(
   defaults: T,
   allowed?: DisplayAllowed<T>,
   migrations?: DisplayMigrations<T>,
+  options?: DisplayStoreOptions,
 ): DisplayStore<T> {
-  const storageKey = (scope: string) => `workspace:${name}:${scope}:display`
+  // Resolved once, at construction, so the key cannot differ between the read
+  // on mount and the write on the next change.
+  const prefix = options?.prefix ?? 'workspace'
+  // An EMPTY prefix is refused rather than defaulted, and loudly, because both
+  // quieter options are worse. Falling back to `workspace` would hand a caller
+  // who asked for isolation the shared namespace instead — silently, and
+  // discoverable only as two products reading each other's settings. Accepting
+  // it produces `:board:ws_1:display`, whose empty first segment collides with
+  // every other empty-prefix caller: precisely the cross-product this option
+  // exists to prevent, reintroduced by the option itself.
+  //
+  // A throw at CONSTRUCTION is safe where a throw on read would not be: the
+  // store is built once, at module scope, so this fires before any UI exists
+  // rather than under a user mid-session. `useDisplay` outside a Provider
+  // already throws for the same reason.
+  if (prefix === '') {
+    throw new Error(
+      'createDisplayStore: `prefix` cannot be empty — omit the option to use the default.',
+    )
+  }
+  const storageKey = (scope: string) => `${prefix}:${name}:${scope}:display`
 
   /** One key's persisted value, or `null` when it does not hold up. */
   function validate<K extends keyof T & string>(key: K, input: unknown): T[K] | null {

package/src/index.ts

@@ -78,6 +78,12 @@ export { SortableList, SortableItem, DragHandle } from './sortable'
 export {
   MultiSortableList,
   SortableDropZone,
+  // The default `collisionDetection`, exported so a consumer overriding the
+  // prop can COMPOSE with it rather than replace it. Without this, the only way
+  // to add one rule is to reimplement pointer-first resolution — which is how a
+  // component ends up with two collision strategies that disagree.
+  pointerFirstCollision,
+  PREVIEW_SETTLE_MS,
   type MultiSortableListProps,
   type MultiSortableMove,
   type SortableContainers,
@@ -672,6 +678,7 @@ export {
   type DisplayAllowed,
   type DisplayMigrations,
   type DisplayProviderProps,
+  type DisplayStoreOptions,
 } from './display-store'
 // ── ADR-146 — the analytics primitive set ─────────────────────────────
 //