@get-bb/plugin-sdk 0.5.31 → 0.6.9

package/README.md

@@ -13,9 +13,13 @@ the built-in `bb-plugin-authoring` skill synchronized with those declarations.
 
 Composer UI extensions register through `app.composer.customize(...)`. A
 `ComposerCustomization` can contribute React action and banner components,
-host-rendered `ComposerPlusMenuItem` rows, and `ComposerRichTextSpec` rules.
-Mounted components use `useComposer()` for writes, effects, and input locking,
-and `useComposerView()` for the reactive scope, layout, draft, and run state.
+host-rendered `ComposerPlusMenuItem` and `ComposerSendMenuItem` rows, and
+`ComposerRichTextSpec` rules. Mounted components use `useComposer()`: one
+stable handle for the composer's text, mentions, picker selection, scope,
+layout, run and submit state, writes, effects, and input locking. Selection is
+reactive and is `null` for composers without pickers. Panels and pages that
+write into a composer the user picks use `useComposers()`, one handle per
+composer on screen.
 Any mounted plugin component can use
 `useBbNavigate().openThreadPanel(...)` to request one of the
 same plugin's registered thread-panel actions; it returns false when the
@@ -70,7 +74,7 @@ app-wide floating React UI. BB mounts the component once per app window through
 the normal plugin slot boundary, so SDK hooks and plugin CSS work and React
 context survives portals. This app-level boundary includes the sidebar thread
 data and action hooks. Hooks whose contract requires a particular surface,
-including `useComposer` and `useComposerView`, remain limited to that surface.
+including `useComposer`, remain limited to that surface.
 The plugin owns the overlay's chrome, positioning, visibility, focus, and
 responsive behavior; a crashing overlay is hidden without affecting siblings.
 Use a content script for app-wide DOM behavior that does not need React context.