docs: web plugin v2.0.0 product brief #233

Open

k9ert wants to merge 1 commit from kn/web-plugin-v2-product-brief into main

k9ert commented

2026-03-08 22:41:09 +00:00

Owner

Summary

BMad-driven product brief for web plugin v2.0.0 and new plugin introspection plugin
Five Web*Provider interfaces (panels, pages, routes, assets, WebSocket) — composition over monolith
Two-tier contribution model: panels = data-driven (~10 lines), pages = handler-driven (full control)
New plugin plugin separates introspection logic from web server, contributes plugin browser
Cookie-based token auth, Pico CSS + HTMX + Starlette stack retained
MVP: three priority interfaces, plugin browser with search/filter, 5+ reference implementations

Next steps

PRD (/bmad-bmm-create-prd)
Architecture (/bmad-bmm-create-architecture)
Epics & stories (/bmad-bmm-create-epics-and-stories)

🤖 Generated with Claude Code

## Summary - BMad-driven product brief for web plugin v2.0.0 and new `plugin` introspection plugin - Five `Web*Provider` interfaces (panels, pages, routes, assets, WebSocket) — composition over monolith - Two-tier contribution model: panels = data-driven (~10 lines), pages = handler-driven (full control) - New `plugin` plugin separates introspection logic from web server, contributes plugin browser - Cookie-based token auth, Pico CSS + HTMX + Starlette stack retained - MVP: three priority interfaces, plugin browser with search/filter, 5+ reference implementations ## Next steps - [ ] PRD (`/bmad-bmm-create-prd`) - [ ] Architecture (`/bmad-bmm-create-architecture`) - [ ] Epics & stories (`/bmad-bmm-create-epics-and-stories`) 🤖 Generated with [Claude Code](https://claude.com/claude-code)

k9ert added 1 commit

2026-03-08 22:41:09 +00:00

docs: web plugin v2.0.0 product brief

CI / lint (pull_request) Successful in 11s

Details

CI / test (3.11) (pull_request) Successful in 24s

Details

CI / test (3.12) (pull_request) Successful in 25s

Details

CI / test (3.13) (pull_request) Successful in 24s

Details

E2E Tests / e2e (pull_request) Successful in 15s

Details

CI / build (pull_request) Successful in 7s

Details

81256de162

BMad-driven product brief for web plugin v2 and new plugin
introspection plugin. Five Web*Provider interfaces, two-tier
contribution model, plugin browser, token auth.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

doxios commented

2026-03-09 05:30:38 +00:00

Collaborator

🦊 PR Review — docs: web plugin v2.0.0 product brief

Scope: Documentation only (new file: docs/decisions/web-plugin-v2/product-brief.md)
Checks: Skipped (docs-only)

Verdict: 🟢 Approve

This is a thorough, well-structured product brief that aligns with Cobot's plugin architecture principles. The five Web*Provider interfaces follow the established ToolProvider pattern, and the separation of the plugin plugin from the web plugin respects Principle 3 (adding a plugin never requires editing another).

🟢 Good

Follows established patterns: The Web*Provider interfaces mirror ToolProvider and use all_with_capability() discovery — exactly how the plugin system is designed to work
Principle 3 compliance: Explicitly addresses that PR #48 violated this principle by using direct method calls, and the new design fixes that
Two-tier contribution model: Panels (~10 lines, data-driven) vs pages (handler-driven, full control) is a smart gradient that lowers the barrier for simple use cases
Clear MVP scope: Good discipline on what's in vs out — WebAssetProvider and WebSocketProvider deferred, settings read-only
Risk awareness: Auth token leakage, circular dependency, interface lock-in all called out with mitigations
BMad frontmatter: Steps tracked, input documents referenced

🟡 Minor

plugin plugin naming: The name plugin for a plugin is self-referential and could be confusing in code (from cobot.plugins.plugin import PluginPlugin?). Consider introspection or registry-browser as alternatives. Not blocking — just worth discussing before implementation.
Settings persistence deferred: Makes sense for MVP, but the brief doesn't mention how plugin settings schemas would be declared (just that they exist). A brief note on the expected schema format would help implementers.
No mention of existing tests: The brief references "all existing tests pass" as success criteria but doesn't mention whether the current web plugin has meaningful test coverage to preserve.

Summary

Solid product brief. The architecture aligns with the plugin design guide, the scope is well-bounded, and the user personas are concrete. Ready to merge as a decision document.

Reviewed by Doxios 🦊 (automated PR review)

## 🦊 PR Review — docs: web plugin v2.0.0 product brief **Scope:** Documentation only (new file: `docs/decisions/web-plugin-v2/product-brief.md`) **Checks:** Skipped (docs-only) --- ### Verdict: 🟢 Approve This is a thorough, well-structured product brief that aligns with Cobot's plugin architecture principles. The five `Web*Provider` interfaces follow the established `ToolProvider` pattern, and the separation of the `plugin` plugin from the web plugin respects Principle 3 (adding a plugin never requires editing another). ### 🟢 Good - **Follows established patterns:** The `Web*Provider` interfaces mirror `ToolProvider` and use `all_with_capability()` discovery — exactly how the plugin system is designed to work - **Principle 3 compliance:** Explicitly addresses that PR #48 violated this principle by using direct method calls, and the new design fixes that - **Two-tier contribution model:** Panels (~10 lines, data-driven) vs pages (handler-driven, full control) is a smart gradient that lowers the barrier for simple use cases - **Clear MVP scope:** Good discipline on what's in vs out — `WebAssetProvider` and `WebSocketProvider` deferred, settings read-only - **Risk awareness:** Auth token leakage, circular dependency, interface lock-in all called out with mitigations - **BMad frontmatter:** Steps tracked, input documents referenced ### 🟡 Minor - **`plugin` plugin naming:** The name `plugin` for a plugin is self-referential and could be confusing in code (`from cobot.plugins.plugin import PluginPlugin`?). Consider `introspection` or `registry-browser` as alternatives. Not blocking — just worth discussing before implementation. - **Settings persistence deferred:** Makes sense for MVP, but the brief doesn't mention how plugin settings schemas would be declared (just that they exist). A brief note on the expected schema format would help implementers. - **No mention of existing tests:** The brief references "all existing tests pass" as success criteria but doesn't mention whether the current web plugin has meaningful test coverage to preserve. ### Summary Solid product brief. The architecture aligns with the plugin design guide, the scope is well-bounded, and the user personas are concrete. Ready to merge as a decision document. --- *Reviewed by Doxios 🦊 (automated PR review)*