Link "Submit to gallery" to the plugin intake form - #1358
Conversation
|
🚨 SLOP COP 🚨 · I am the SlopCop. I am now reviewing this pull request for security, code quality, performance, duplication, architecture, and end-to-end behavior. I will post one final review after the parallel checks finish. |
2f13b1c to
0a1d83b
Compare
brsbl
changed the title
SawyerHood
left a comment
SawyerHood
left a comment
There was a problem hiding this comment.
🚨 SLOP COP 🚨 · review
ELI5: This change adds a door to a form. The door works, but agents have no matching door.
The desktop setting also cannot choose where this door opens.
I found two high-severity issues.
-
PluginDetailcannot honor the desktop in-app browser preference from the Tools route. That route has noUrlOpenRoutingProvider.The context stays null. The hook therefore chooses the external browser for every selection.
Supply an in-app opener for Tools routes. Add a click test with the preference enabled.
-
The feature has no SDK or
bbCLI surface. This conflicts with the repository rule for all end-user features.Add a shared SDK method and a
bb plugincommand for the canonical submission URL. Document and test both surfaces.
I also found one low-severity gap. The exhaustive control story omits this new action for direct and local plugins.
The architecture scan found no duplicate submission flow. It found one existing duplicate official-provenance check in PluginDetail.
The imported isOfficialProvenance helper can replace that local check. This existing duplication does not block this pull request.
Security and performance reviews found no issues.
Validation passed:
- The focused app test passed all 31 tests.
- The app typecheck passed.
- The app lint passed with unrelated warnings.
git diff --checkpassed.- The form returned HTTP 200.
- The browser test opened the exact form with the title “Submit a bb plugin.”
- The official plugin menu did not show the submission action.
The final GPT-5.6 review gate returned REQUEST CHANGES. I posted this as a comment-only review, as required.
useOpenUrlByPreference was dead indirection on this route: UrlOpenRoutingProvider only mounts inside ThreadDetailView because the in-app browser is a thread-panel surface, so on /tools the context is always null and the hook could only ever pick the external browser. Call openUrlInExternalBrowser directly — the same behavior every other Tools-route link has — and say so in the comment instead of implying the preference applies. The provenance test now also clicks the action with the in-app link preference enabled and asserts the external window.open, pinning the intended behavior rather than the accident. Review: #1358 (comment) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The submission URL was a client-only constant, so agents had no way to reach the feature — AGENTS.md requires every end-user feature be usable through the bb CLI. The constant moves to @bb/domain (the only package both the app and the CLI already depend on, and a product fact rather than a wire contract), and `bb plugin submit` prints it, with the guide chapter and bb-cli skill documenting the command. This deliberately stays a link-out, matching the app action: the Google Form is the whole submission UI, so there is no server route to expose and nothing for an SDK method to do — that half lands with the real in-app form. The skill entry tells agents to hand the link to the user, since the form asks for details only the author knows, including their email. The guide-coverage CLI test now requires the chapter to mention the subcommand, which is the doc surface worth pinning. Review: #1358 (comment) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2740e9c to
04f3a89
Compare
09ff826 to
07ebd96
Compare
07ebd96 to
643a0b0
Compare
# Conflicts: # packages/templates/src/generated/plugin-sdk-dts.generated.ts
Moves plugin configuration into Settings, where configuration lives — and is the top layer of the native GitHub stack for the Extensions rework (#1358 → #1360 → #1471 → #1472 → #1473 → #1474 → here). - **/settings/plugins/:id** hosts each plugin's settings form, under a Plugins sidebar group where each row uses the plugin's own icon. - **Mirrored anatomies**: the plugin settings page mirrors the Extensions detail page's header (icon + title + one-line description) and section stack; its "Plugin details" section is one sentence linking across to the plugin page, and the detail page's "Configuration" section is one sentence linking here — each page owns its half and points at the other. - The per-plugin settings route participates in Settings route memory like any other section; only the bare /settings/plugins list remains a legacy redirect to Extensions. Bundle budget: this integration layer raises the compressed boot allowance from 435.3 KB to 438.0 KB to account for the persistent plugin rows added to Settings. The final measured boot payload is 436.2 KB Brotli; the raw boot payload remains within its existing limit. BB-Thread-ID: thr_kuixkqt8n2 > AGENT GENERATED: by GPT-5
2 participants
Gives plugin authors a first-class path into BB's marketplace, and gives BB a structured intake instead of ad-hoc requests.
bb plugin submitprints the same intake form link, so authors working from the terminal (or agents) discover the path without opening the app.@bb/domainasPLUGIN_SUBMISSION_FORM_URL; both surfaces read it, so it cannot drift.bb pluginhelp/guide/skill surfaces are updated in the same change.Follow-up commit scopes an old catalog test's "no marketplace" help assertion to command position: the guard is against a
marketplacecommand group returning, not againstsubmit's legitimate mention of the marketplace.BB-Thread-ID: thr_kuixkqt8n2