Separate Automations from Extensions - #888
Draft
brsbl wants to merge 14 commits into
Draft
Conversation
brsbl
changed the title
The previous Includes layout kept a full-width header band above each card's items, so every capability spent most of its height and 60-66% of its width on category chrome: a 115px card carried one 44px item, and the label/detail grid left both texts floating in whitespace. Give each card an internal horizontal split instead. The category becomes a fixed left rail — a label on the card's axis, not a peer of its contents — and the width that used to be dead space becomes the item column, with a rule anchoring it. Items lay out as label plus detail on one baseline, so long ids and long summaries wrap as a hanging definition rather than stranding text mid-row. Cards fall to 60px and Includes to 478px from 739px, and the rail stacks above the items below `sm` where there is no horizontal space to use. Release carried the same problem: a bordered fact table with filled label cells for one or two short scalars. Facts now read as a quiet metadata run with no surface of their own. Compatibility leaves that run entirely — it is a blocked update the user may need to act on, not a peer fact — and keeps a warning tone, an icon, and its own details action. Category glosses are tightened to fit the rail without wrapping, which is what lets the cards be short; they still say what the capability adds and where it is encountered. Also cover the Release states that had no story at all: bundled, update available, update failed, and compatibility blocked. Each carries its own plugin id so the seeded source query serves it without a backend request. Validation under Node 22: `turbo run build typecheck lint` 68/68; @bb/app 295 files / 2144 tests, plus @bb/shared-ui and bb-plugin-automations. Reviewed in Ladle at 420/480/620/900/1600px, light and dark, with no horizontal overflow and no failed requests or console errors.
Includes was reaching for a bespoke card per capability category, which is the thing shared-ui already has a primitive for. `ResourceDetailCollection` names capabilities in its own contract and says the section supplies the hierarchy "without introducing another card", and skill Files, automation Run history, and Activity all already use it. Includes was the only holdout, which is why it read as a stack of unrelated objects while Activity — directly below it on the same page — read as a list. A category is a label on a run of rows, not an object. Wrapping each one in its own bordered panel drew a box around what is usually a single row, and the per-category gloss under it was boilerplate that repeated what the category name already said. Categories are now quiet row-group headers inside one collection, and the glosses are gone. Activity gets the same row-group language and loses its own four lines of boilerplate, so the two neighbouring sections stop looking like two different products. Includes 739px → 432px, Activity 489px → 416px, and a fully populated page drops from eight bordered surfaces to two. The bespoke `sm:` grid is gone too — a list reflows on its own, so narrow widths need no special case. `detail-page-recipes.test.tsx` is untouched, and the capability-group count and item-to-heading bindings still hold. Only the three assertions that required per-group card chrome changed; they now assert the single collection surface instead. Validation under Node 22: `turbo run build typecheck lint` 68/68; @bb/app 295 files, @bb/shared-ui, and bb-plugin-automations green; focused contract tests 27/27. Reviewed in Ladle at 560/1600px, light and dark.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
/plugins/automations/automations./tools/automationsand/automationscollection, browse, detail, and edit URLs to the canonical Automations plugin routes.ResourceDetailCollection— one surface, with each capability category as a quiet row-group header over its items.Why
Extensions is the management surface for skills and plugin installations. Plugin-contributed working pages are a different kind of navigation: they belong beside Threads, under an explicit Plugins group that can grow without crowding fixed sidebar chrome. Automations remains a familiar user-facing concept while moving out of the management hub.
Plugin details now distinguish two questions that the previous page mixed together: Includes explains what the plugin adds for the user, while Activity explains whether its background work is healthy or needs attention.
Includes had been reaching for a bespoke card per category.
ResourceDetailCollectionalready exists for exactly this — its own contract names capabilities as a use case and says the section supplies the hierarchy "without introducing another card" — and skill Files, automation Run history, and Activity all already use it. A per-category panel drew a border around what is usually a single row, so Includes read as a stack of unrelated objects while Activity, directly below it, read as a list. Categories are now row groups inside one collection: Includes drops from 739px to 432px and the page goes from eight bordered surfaces to two. Release had the same problem in miniature — a bordered grid with filled label cells for one or two short scalars, heavier than the About paragraph above it while mattering less.Compatibility and constraints
experiments.toolsHubremains default-off and gates Extensions only. Automations and other registered plugin pages remain available in the Plugins section in either experiment state.ResourceDetailFacts/ResourceDetailFactkeep their names and their two call sites; the redesign removed the unusedactionanddetailsprops rather than adding a variant with a dead branch.detail-page-recipes.test.tsxis untouched.ToolsView.plugin-detail.test.tsxstill pins the capability-group count and every item-to-heading binding; only the three assertions that required per-group card chrome changed, and they now assert the single collection surface instead.Validation
Under Node 22 (v22.22.1):
pnpm exec turbo run build typecheck lint— 68/68 tasks passed.pnpm exec turbo run test --filter=@bb/app --filter=@bb/shared-ui --filter=bb-plugin-automations --force— @bb/app 295 files and 2,144 tests passed, with @bb/shared-ui and bb-plugin-automations green.ToolsView.plugin-detail,detail-page-recipes,tools-public-exports, andPluginUpdatesCard: 27/27 passed.Screenshot review in Ladle, driven headlessly over CDP against the real story:
extensions--plugin-detail-statesat 420, 480, 620, 900, and 1600px, in light and dark, in both fullscreen preview and normal Ladle chrome.