feat: Add chat prompt context - #598

packages/ai-core/src/components/ContextSelector.tsx (1)

454-461: 💤 Low value

Two Object.assign calls can be merged into one.

♻️ Proposed refactor

-export const ContextSelector: ContextSelectorComponent = Object.assign(Root, {
+export const ContextSelector: ContextSelectorComponent = Object.assign(Root, {
   Badge,
   SearchDropdown,
-}) as ContextSelectorComponent;
-
-Object.assign(ContextSelector, {
   [CHAT_CONTEXT_SELECTOR_SLOT]: true,
-});
+}) as ContextSelectorComponent;

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/ai-core/src/components/ContextSelector.tsx` around lines 454 - 461,
Merge the two Object.assign calls into a single assignment: when creating
ContextSelector, assign Root plus the properties Badge and SearchDropdown and
also add the keyed property [CHAT_CONTEXT_SELECTOR_SLOT] in one Object.assign
call so ContextSelector is created with all properties at once; locate the
ContextSelector declaration (currently using Object.assign(Root, { Badge,
SearchDropdown }) and the subsequent Object.assign(ContextSelector, {
[CHAT_CONTEXT_SELECTOR_SLOT]: true }) and combine them into a single
Object.assign(Root, { Badge, SearchDropdown, [CHAT_CONTEXT_SELECTOR_SLOT]: true
}) assigned to ContextSelector.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

packages/ui/src/components/tab-strip.tsx (3)

497-506: 💤 Low value

onDragOver overlay logic flips overlay back on after isDragInsideTabStrip returned true.

The flow is:

1. If !over || isDragInsideTabStrip(event) → setHideSharedDragOverlay(true) and return.
2. Otherwise set hideSharedDragOverlay to (over.data.current.tabStripId === dndScopeId).

Step 2 only runs when the drag is outside this tab strip. In that case tabStripId === dndScopeId would only be true if the user dragged the source tab outside its own strip and hovered some other droppable that happens to declare the same tabStripId — which usually won't happen. So effectively, whenever the drag leaves the strip, hideSharedDragOverlay is set to false, revealing the overlay. That's the intended UX.

However, onDragMove only ever sets it to true (line 494), never back to false. Between an onDragMove (inside) tick and the next onDragOver (outside) tick there can be intermediate frames where hideSharedDragOverlay is stale. Consider unifying overlay visibility into a single derived value computed in one place (e.g., compute it in onDragMove too, mirroring onDragOver).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/ui/src/components/tab-strip.tsx` around lines 497 - 506, The
onDragOver handler flips hideSharedDragOverlay based on tabStripId but
onDragMove only ever sets it to true, causing stale visibility between events;
update onDragMove to apply the same visibility logic used in onDragOver (use
isDragInsideTabStrip(event) and compare event.over?.data.current?.tabStripId ===
dndScopeId when dndMode === 'shared') or extract the logic into a shared helper
used by both onDragMove and onDragOver so both handlers compute and call
setHideSharedDragOverlay consistently.

---

182-188: ⚡ Quick win

Spread order may let user-provided drag data clobber kind.

...getTabDragData?.(tab) is spread between the literal kind: DEFAULT_TAB_DRAG_KIND and the trailing tabId/tabStripId. That ordering correctly protects tabId and tabStripId from being overridden by user data, but the spread can intentionally or accidentally overwrite kind (e.g., ArtifactTabsRoot relies on this to set kind: 'artifact'). If overriding kind is intended, please document it on the getTabDragData prop type (TabStripDragData) so callers know they can flip the discriminator; if not, freeze kind by putting it last.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/ui/src/components/tab-strip.tsx` around lines 182 - 188, The spread
of getTabDragData?.(tab) sits between kind and tabId/tabStripId which allows
user data to overwrite kind; either explicitly document in the TabStripDragData
prop type that callers may override the discriminator, or (preferred) freeze
kind by moving the spread to the front and placing tabId, tabStripId and kind
after it (e.g., data: { ...getTabDragData?.(tab), tabId: tab.id, tabStripId:
dndScopeId, kind: DEFAULT_TAB_DRAG_KIND }) so neither tabId/tabStripId nor kind
can be clobbered.

---

480-518: ⚡ Quick win

Consider consolidating useDndMonitor logic to avoid unnecessary hook registration in 'internal' mode.

useDndMonitor is called unconditionally in TabStripTabs, but in 'internal' mode it serves no purpose since all handlers contain early if (dndMode !== 'shared') return; guards. While useDndMonitor does not throw outside a DndContext (it simply no-ops), registering and maintaining the hook in internal mode is unnecessary overhead. For clarity and efficiency, consider either:

1. Wrapping the useDndMonitor call in a conditional: if (dndMode === 'shared') { useDndMonitor(...) }
2. Extracting the monitor logic into a small inner component rendered only in 'shared' mode

The current code functions correctly but can be streamlined.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/ui/src/components/tab-strip.tsx` around lines 480 - 518, The DnD
monitor is registered unconditionally in TabStripTabs despite only being needed
for dndMode === 'shared'; move the useDndMonitor call and its handlers into a
small inner component (e.g., SharedDndMonitor) that you render only when dndMode
=== 'shared' so React hook rules remain satisfied. Inside SharedDndMonitor, use
useDndMonitor with the existing handlers
(onDragStart/onDragMove/onDragOver/onDragEnd/onDragCancel) and reference the
same helpers and state setters (isDragInsideTabStrip, handleDragEnd,
setActiveDraggedTabId, setHideSharedDragOverlay, dndScopeId) so behavior is
unchanged but the hook is not registered in 'internal' mode.

packages/layout/src/docking/DockingProvider.tsx (1)

29-33: 💤 Low value

Consider documenting the new ancestor DndContext requirement.

DockingProvider previously created its own DndContext; it now uses useDndMonitor, which throws when invoked outside a DndContext. The current wiring works because LayoutRenderer wraps DockingProvider in RoomDndProvider, but consumers reusing DockingProvider directly will hit a confusing runtime error. A short JSDoc note on the component (and/or a dev-time assert) would help.

📝 Suggested doc

+/**
+ * Renders docking preview/overlay for layout panels. Must be rendered inside
+ * a `RoomDndProvider` (or any `@dnd-kit/core` `DndContext`); otherwise
+ * `useDndMonitor` will throw.
+ */
 export const DockingProvider: FC<PropsWithChildren<DockingProviderProps>> = ({

Also applies to: 163-168

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/layout/src/docking/DockingProvider.tsx` around lines 29 - 33,
DockingProvider now calls useDndMonitor and therefore requires to be rendered
inside a DndContext (previously it created its own); add a short JSDoc above the
DockingProvider export describing this requirement (mention DndContext and that
LayoutRenderer wraps it with RoomDndProvider) and add a dev-time assert inside
DockingProvider to surface a clear error when useDndMonitor is missing (e.g.,
detect that useDndMonitor returns undefined/error and throw a descriptive error
like "DockingProvider must be wrapped in a DndContext/RoomDndProvider"). Ensure
references to DockingProvider, useDndMonitor, DndContext, LayoutRenderer and
RoomDndProvider are included in the doc/assert so consumers can find the
intended wrapper.

packages/ai-core/src/components/QueryControls.tsx (1)

122-165: ⚡ Quick win

Consider isolating DnD wiring behind contextDropTarget presence.

useDroppable and useDndMonitor are invoked unconditionally. When contextDropTarget is not provided, this still:

• Registers a droppable using the shared fallback id 'chat-composer-context-drop-target-disabled'. Multiple QueryControls instances mounted simultaneously without DnD will collide on this id and may trigger @dnd-kit duplicate-id warnings.
• Subscribes to every onDragEnd via useDndMonitor only to immediately bail out.

A cleaner pattern is to extract the DnD wiring into a small internal subcomponent that is only rendered when contextDropTarget is provided, and conditionally pass its setNodeRef / isAcceptedContextDropOver to the container. That removes the dummy id and avoids subscribing dnd listeners for the common no-DnD case.

♻️ Sketch of the refactor

// Conditionally render a child that owns useDroppable + useDndMonitor.
function ContextDropTarget({
  target,
  children,
}: {
  target: NonNullable<QueryControlsProps['contextDropTarget']>;
  children: (args: {
    setNodeRef: (el: HTMLElement | null) => void;
    isAcceptedOver: boolean;
  }) => React.ReactNode;
}) {
  const {active, isOver, setNodeRef} = useDroppable({
    id: target.id,
    data: {roomDndPriority: 100},
  });
  const data = active?.data.current;
  const canAccept = Boolean(data && target.canAccept(data));
  useDndMonitor({
    onDragEnd: (event) => {
      if (event.over?.id !== target.id) return;
      if (
        !event.collisions?.some(
          (c) => c.id === target.id && c.data?.pointerWithin === true,
        )
      )
        return;
      const d = event.active.data.current;
      if (target.canAccept(d)) target.onDrop(d);
    },
  });
  return <>{children({setNodeRef, isAcceptedOver: isOver && canAccept})}</>;
}

Then wrap the composer container only when contextDropTarget is defined.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/ai-core/src/components/QueryControls.tsx` around lines 122 - 165,
The current implementation always calls useDroppable and useDndMonitor even when
contextDropTarget is null, causing a shared fallback id and unnecessary DnD
subscriptions; extract the DnD wiring into a small internal component (e.g.,
ContextDropTarget) that is only rendered when contextDropTarget is non-null,
move useDroppable and useDndMonitor there (use the real target.id instead of the
fallback), compute the accepted-over boolean inside that component and pass
setNodeRef (formerly setContextDropTargetRef) and isAcceptedOver (formerly
isAcceptedContextDropOver) back to the parent via a render-prop or children
callback, and remove isPointerWithinContextDropTarget from the outer scope so
the onDragEnd logic lives with the DnD hooks and calls target.onDrop when
appropriate.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes