116 lines
11 KiB
Markdown
116 lines
11 KiB
Markdown
# Plugin Candidate Boundaries
|
|
|
|
> **Plugin runtime gate:** The WASM plugin runtime is staging/foundation only
|
|
> until the external security sign-off in
|
|
> [Plugin Runtime Signoff](security/plugin-runtime-signoff.md) is complete.
|
|
> Plugin candidates remain extraction contracts, not production-enabled
|
|
> third-party plugins.
|
|
|
|
## Purpose
|
|
|
|
This document is the production entrypoint for optional feature surfaces in the boilerplate. It explains which areas are treated as `plugin-candidate` extraction contracts, which areas stay in the pruned core, and which areas are `remove-candidate` pruning targets. A plugin candidate is not an already-packaged plugin: it is a documented boundary that can be extracted later only after ownership, data, secrets, routes, workers, dependencies, and verification are made explicit.
|
|
|
|
Some plugin-candidate surfaces are still active in the versioned Product Core CRM SaaS showcase. That means "active product surface" and "future extraction candidate" can both be true. Do not read this page as proof that Workflow Engine, CRM, Email Marketing, Knowledge Base, or Help Desk have already been packaged as installable production plugins.
|
|
|
|
## Source of Truth Files
|
|
|
|
Use these files as the canonical authority before changing plugin boundaries:
|
|
|
|
- [Feature inventory](feature-inventory.md): human-readable core, plugin-candidate, and remove-candidate classification.
|
|
- [Plugins feature overview](features/plugins.md): product-facing status, capability model, tenant-admin flow, and open implementation slices.
|
|
- [Plugin lifecycle operations](operations/plugin-lifecycle.md): operator install, enable, disable, update, uninstall, worker topology, and auto-disable runbook.
|
|
- [Feature manifest contract](feature-manifests/README.md): machine-readable manifest rules and validation expectations.
|
|
- [Plugin candidate manifest](feature-manifests/plugin-candidates.json): current optional feature groups and their shared extraction guardrails.
|
|
- [Removal candidate manifest](feature-manifests/remove-candidates.json): surfaces that should be deleted or aggressively reviewed instead of packaged as durable plugins.
|
|
- [Porting guide](porting-guide.md): wording rules for current boilerplate documentation, including the rule that plugin candidates must not be described as already extracted.
|
|
|
|
Canonical feature decision reports live under [feature decisions](feature-decisions/):
|
|
|
|
- [CRM decision report](feature-decisions/crm-decision-report.md)
|
|
- [Email Marketing decision report](feature-decisions/email-marketing-decision-report.md)
|
|
- [Portals and Sites decision report](feature-decisions/portals-sites-decision-report.md)
|
|
- [Knowledge Base, Widgets, Workflow, and Marketing decision report](feature-decisions/kb-widgets-workflow-marketing-decision-report.md)
|
|
|
|
## Boundary Terms
|
|
|
|
| Term | Meaning | Documentation rule |
|
|
| --- | --- | --- |
|
|
| `core` | Required default boilerplate surface: auth, accounts, tenants, web app and admin shell, DB/ORM foundation, transactional mail, billing, i18n, and UI primitives. | Keep as present-tense supported boilerplate behavior when the source files confirm it. |
|
|
| `plugin-candidate` | Optional product surface that may become a plugin or separately installable module after dependency review. | Describe as an extraction contract, not as a completed package or installed plugin. |
|
|
| `remove-candidate` | Surface that should be removed or aggressively reviewed because it conflicts with the pruned-core direction. | Do not promise long-term compatibility or package it as an official plugin unless a later decision changes the manifest. |
|
|
|
|
## Current Candidate Groups
|
|
|
|
The current plugin-candidate bundle is defined in [plugin-candidates.json](feature-manifests/plugin-candidates.json) and summarized by [feature-inventory.md](feature-inventory.md). Each group still needs extraction work before it can be treated as an installable plugin.
|
|
|
|
| Candidate group | Canonical status | Primary boundary concern |
|
|
| --- | --- | --- |
|
|
| CRM | Plugin candidate; canonical report: [CRM decision report](feature-decisions/crm-decision-report.md). | Strong vertical coupling to company, contact, opportunity, rows, and Email Marketing data. |
|
|
| Email Marketing and Newsletter | Plugin candidate; canonical report: [Email Marketing decision report](feature-decisions/email-marketing-decision-report.md). | Campaign, sender, audience, consent, tracking, and provider-secret ownership must stay separate from core transactional mail. |
|
|
| Workflow Engine | Active Product Core surface and plugin candidate; canonical report: [Knowledge Base, Widgets, Workflow, and Marketing decision report](feature-decisions/kb-widgets-workflow-marketing-decision-report.md). | Worker, queue, schema, API, route, and dependency boundaries must stay explicit before any extraction. |
|
|
| Knowledge Base | Plugin candidate; canonical report: [Knowledge Base, Widgets, Workflow, and Marketing decision report](feature-decisions/kb-widgets-workflow-marketing-decision-report.md). | Public help visibility, support content, and data access rules are not part of the minimum boilerplate core. |
|
|
| Portals and Sites | Plugin candidate; canonical report: [Portals and Sites decision report](feature-decisions/portals-sites-decision-report.md). | Customer portal and site-builder behavior need public URL, domain, billing, analytics, and persistence boundaries. |
|
|
| Analytics and Metrics | Plugin candidate or review surface per inventory. | Product analytics collection and UI should be opt-in; core observability remains separate. |
|
|
| Events, Webhooks, and Audit Trails | Plugin candidate or advanced integration surface. | Domain events may support integrations, while entity webhook UI and retry operations require explicit API, worker, and permission boundaries. |
|
|
| No-code Entity Builder and Code Generator | Plugin or review-needed surface in the inventory. | Entity metadata, generated code, formulas, JSON properties, and rows coupling must not destabilize core DB foundations. |
|
|
| AI, Chatbot, Prompt Builder, and MCP | Plugin candidate. | Provider costs, model access, prompts, streaming, admin configuration, tenant use, and secret exposure require strict isolation. |
|
|
| Help Desk | Plugin candidate. | Support workflows should couple only to optional Knowledge Base and inbound-channel surfaces. |
|
|
| Onboarding Builder | Plugin candidate. | Public/session onboarding routes and admin configuration need opt-in ownership. |
|
|
| Feature Flags | Plugin candidate or advanced core review surface. | Admin policy, tenant rollout, audit, and runtime fallback semantics must be defined before retention. |
|
|
| Widgets | Plugin candidate; canonical report: [Knowledge Base, Widgets, Workflow, and Marketing decision report](feature-decisions/kb-widgets-workflow-marketing-decision-report.md). | Embedded public and API widgets require public data, tenant ownership, API, and enablement boundaries. |
|
|
| Notifications | Optional surface. | Novu-backed dependencies and notification configuration should not become implicit core requirements. |
|
|
| Storage and Supabase | Optional provider surface. | Core may keep file-storage abstractions, but Supabase-specific provider configuration and secrets must be optional. |
|
|
|
|
## Remove-Candidate Boundary
|
|
|
|
The [removal candidate manifest](feature-manifests/remove-candidates.json) is separate from the plugin-candidate bundle. Marketing and public-site remnants, blog or changelog remnants, playground/demo/debug surfaces, marketing chatbot behavior, and source-product copy/assets/fake data should be removed or reviewed for deletion rather than documented as stable plugin offerings. Heavy editor, drag/drop, syntax, and math dependencies are review targets only until live imports prove their owning features have moved out of core/shared UI. If a later milestone converts one of these areas into a plugin, it must update the inventory, the relevant manifest, and the feature decision evidence first.
|
|
|
|
## Extraction Prerequisites
|
|
|
|
Before any plugin candidate is packaged or described as installed, the owning task must prove all of the following:
|
|
|
|
1. A manifest names the plugin ID, classification, owner, code areas, dependencies, consumers, routes, API surfaces, permissions, audit events, billing impacts, and UAT checks.
|
|
2. Core can run with the candidate disabled or absent without breaking auth, tenancy, admin shell, tenant shell, DB foundations, transactional mail, billing, i18n, or UI primitives.
|
|
3. Tenant, admin, public, and API routes are separated so public URLs are not normalized through tenant-app helpers by accident.
|
|
4. Database schema, migrations, seed data, entity templates, and generated clients are either plugin-owned or explicitly retained as core dependencies until extraction lands.
|
|
5. Worker queues and jobs are declared only when the plugin needs them; optional workers must not become mandatory for local core development.
|
|
6. External dependencies and provider SDKs are moved behind plugin contracts after consumer audits confirm they are not shared core dependencies.
|
|
7. Navigation, feature gates, plan gates, permissions, and empty states define the intended disabled-plugin behavior before extraction; do not describe disabled routes as implemented unless the runtime toggle and tests exist.
|
|
8. The canonical decision report and [feature inventory](feature-inventory.md) are updated in the same change when classification changes.
|
|
|
|
## Secret and Data Boundary Rules
|
|
|
|
- Plugin provider secrets must be platform/admin-owned unless the manifest explicitly declares tenant-owned secrets.
|
|
- Secrets must remain server-side and must not appear in Markdown examples, client bundles, logs, screenshots, or generated diagnostics.
|
|
- Environment variables for optional providers belong to the plugin contract and should not be required for the default core quick start.
|
|
- Widget, help, portal, AI, and webhook surfaces must validate ownership and visibility before reading tenant data.
|
|
- Transactional mail stays core; Email Marketing sender, campaign, list, tracking, and consent data belong to the Email Marketing plugin boundary.
|
|
- CRM, rows, and entity-template coupling must be audited before deleting or extracting shared data models.
|
|
- Removal candidates should not keep provider credentials or long-lived data contracts unless a retained core feature still depends on them.
|
|
|
|
## Failure Modes and Drift Checks
|
|
|
|
Watch for these documentation and implementation failures:
|
|
|
|
- Stale candidate classification between [feature-inventory.md](feature-inventory.md), [plugin-candidates.json](feature-manifests/plugin-candidates.json), and feature decision reports.
|
|
- Links to missing decision reports or manifests.
|
|
- Wording that promises already-extracted plugins, package installation, or default runtime enablement before the code and manifests prove it.
|
|
- Treating remove-candidates as supported legacy plugin surfaces.
|
|
- Adding optional-provider secrets to default setup docs or client-facing examples.
|
|
- Recommending automatic browser or end-to-end runs as part of default non-E2E documentation gates.
|
|
|
|
## Load Profile
|
|
|
|
This document is static Markdown. It adds no runtime code, network calls, browser automation, workers, database access, or production load.
|
|
|
|
## Verification
|
|
|
|
Use non-E2E static checks for this entrypoint:
|
|
|
|
```sh
|
|
pnpm run verify:production-docs
|
|
pnpm run verify:docs-links
|
|
```
|
|
|
|
The documentation verifier and link checker should fail with file-scoped diagnostics when `docs/plugins.md` is missing, empty, contains forbidden placeholder markers, contains broken local links or anchors, or drifts into wording that recommends automatic browser or end-to-end execution for the docs gate.
|