Feature matrix review

Resolved in Phase 5. The marketing defaults below are what FeatureRegistry ships. The signed entitlement list from the API remains the only runtime authority — changing a plan in this file without a matching payload does nothing.

There are no remaining REQUIRES_PLAN_REVIEW cells in docs/FEATURE_MATRIX.md.

Resolved assignments

Key	Shipped plan	Why
notifications.email	Free (exactly one, non-conditional)	A contact form that cannot notify is not a contact form. Cardinality is enforced in DefinitionFeatureScanner via notifications.advanced for a second email.
notifications.advanced	Pro	Multiple emails, HTML, attachments.
notifications.conditional	Pro	Per-action conditions.
actions.redirect	Free	Already part of Free confirmation handling. Gating it would break existing forms.
forms.duplicate	Free	Duplicating a Pro+ form on Free copies and marks contains_locked_features instead of hard-failing.
forms.schedule	Free	starts_at/ends_at already enforced by FormGate; not named as Pro in the spec.
gutenberg	Free	The block is how a Free user inserts a form. Elementor stays Pro.
actions.webhook	Business	Developer-facing outbound HTTP.
actions.wp_user / actions.wp_post	Pro+	Matches wordpress.user_management / wordpress.frontend_post.
integrations.* (Mailchimp, Sheets, Slack, Zapier, ActiveCampaign)	Pro	Transactional / marketing.
integrations.hubspot / integrations.salesforce	Pro+	CRM.
security.recaptcha / hcaptcha / turnstile / akismet / rate_limiting	Pro	Spam defence beyond honeypot.
security.advanced_bot_detection	Business	Spec: advanced security.
fields.standard	Free, boolean	Not a counted entitlement. The "25 fields" gap is a product-scope item, not a licensing one.

Original notes

The reasoning that led to the table, kept for the record.

notifications.email

The specification puts "multiple email actions, conditional email, HTML emails, attachments" in Pro, and separately says of a Free submit: "Email Basic → abhängig vom Entitlement". It never states whether a single plain email notification is a Free feature.

Consequence either way: a Free form that cannot notify anyone of a submission is a contact form that does not contact. Competitors ship one notification in their free tier. Draft assumes Free = exactly one non-conditional email action, with notifications.advanced (multiple recipients, HTML, attachments) and notifications.conditional as Pro.

Needs a decision on the cardinality too: if Free gets one email action, the gate is a count limit inside FormEntitlementValidator, not a boolean — the first quantitative entitlement in the system. That changes the EntitlementManager contract, so it should be settled before Phase 2 rather than Phase 5.

actions.redirect

The specification lists redirect under Pro Automation. The audited code implements redirect as settings.confirmation_type = 'redirect', which is part of the Free confirmation handling and predates any plan split.

Gating it would remove working behaviour from existing Free installations. Draft keeps it Free. If it must be Pro, the downgrade path needs an explicit rule for forms already configured to redirect: fall back to the inline message, or keep redirecting and only block edits.

forms.duplicate

Pro per the specification ("Duplizieren"). The code exposes POST /forms/{id}/duplicate unconditionally, and FormService::duplicate() re-enters create(), so duplicating a Pro+ form on Free would be rejected by the save gate anyway (risk R-03 in the audit).

Two sub-decisions: is duplication itself paid, and what happens when a Free user duplicates a form containing locked config. Draft leaves duplication Free and handles the second case via contains_locked_features rather than a hard refusal.

forms.schedule

starts_at / ends_at are implemented and enforced by FormGate. The specification mentions "Form Restrictions" under Pro but never names scheduling. If scheduling becomes Pro, existing Free forms with a schedule need a defined behaviour — most likely the window stays honoured and only editing is locked.

gutenberg

The specification puts the Gutenberg block in Pro. This is unusual for a WordPress form plugin: the block is how a Free user inserts a form into the block editor at all, and the shortcode is the only alternative. The picker endpoint GET /forms/picker deliberately uses a looser permission (edit_posts / edit_pages) precisely so ordinary editors can insert forms.

Draft marks it R rather than following the specification, because gating it makes Free measurably worse than the shortcode-only baseline while adding no upgrade pressure that the Elementor gate does not already provide.

actions.webhook

Not assigned to any plan in the specification. Pro says "further Pro actions per the final matrix"; Business says "advanced Platform / Developer functionality". A webhook is the classic prosumer integration primitive.

Candidates: Pro (generous, drives adoption), Pro+ (alongside payments and the other server-side actions), Business (treated as developer tooling). Draft leaves Pro/Pro+ unresolved and grants it to Business.

actions.wp_user, actions.wp_post

The specification assigns wordpress.frontend_post and wordpress.user_management to Pro+, but lists actions.wp_post and actions.wp_user as separate keys without a plan.

These look like the same capability expressed twice: the action is the mechanism, the wordpress.* key is the feature. Recommend either collapsing each pair into one key, or defining the action key as the gate and the wordpress.* key as the module. Draft tentatively puts both actions at Pro+ to match their wordpress.* counterparts, marked R because the duplication itself needs resolving.

All integrations.* keys

The specification requires a key per integration so the dashboard can move them between plans, but assigns none of them to a plan. Business includes everything by definition; Pro and Pro+ are open.

The likely split is transactional/marketing integrations (Mailchimp, Slack, Google Sheets, ActiveCampaign, Zapier) at Pro or Pro+, and CRM (HubSpot, Salesforce) at Pro+ or Business. Draft records Salesforce as the one plausible Pro+-and-up outlier and leaves the rest Pro/Pro+ unresolved.

Since none of these exists in code, the cost of deciding later is zero as long as the keys are registered now.

security.recaptcha, security.hcaptcha, security.turnstile

Not assigned. Free gets security.honeypot and security.nonce; Business gets "advanced Security functionality", which the draft reads as security.advanced_bot_detection.

Captcha sits between the two. Note the compliance angle: captcha is often the only practical spam defence for a low-traffic site, and honeypot alone is weak against modern bots. Recommend Pro for all three providers, since gating basic spam protection behind Pro+ invites bad reviews. Marked R pending confirmation.

security.rate_limiting

Not assigned. Arguably a security control rather than a feature, which under the audit's own rule ("security controls are never gated") would make it Free core. Counter-argument: per-form configurable limits are a real feature surface.

Recommend splitting: a non-configurable baseline limit as ungated core, and configurable per-form limits as Pro. That split does not exist in the current key list and needs one new key if adopted.

security.akismet

Not assigned. Requires the customer's own Akismet key, so it costs the platform nothing. Recommend Pro. Marked R.

fields.standard — cardinality

The specification says Free includes "25 standard fields". Eight exist. This is not a plan conflict but a scope gap, recorded here because the matrix would otherwise claim a Free feature the plugin does not have.

Decide whether fields.standard is an uncapped boolean (all shipped standard fields, whatever the count) or a counted entitlement. Draft treats it as a boolean; a counted entitlement would need the same quantitative EntitlementManager support as notifications.email.

Resolved without review

Recorded so the reasoning is not relitigated.

Key	Plan	Basis
forms.multistep	Pro	Explicit in the specification and in the test matrix
forms.conditional_logic	Pro	Explicit in both
forms.calculations	Pro	Explicit in the test matrix
forms.repeater	Pro+	Explicit in the test matrix (Pro locked, Pro+ allowed)
elementor	Pro	Explicit in the test matrix
payments.*	Pro+	Explicit in the payment test matrix
pdf.*	Pro+	Explicit under Pro+
quiz	Pro+	Explicit under Pro+
surveys	Pro	Explicit under Pro
analytics.basic	Pro	Explicit under Pro
analytics.advanced	Pro+	Explicit under Pro+
exports.advanced	Pro+	Explicit under Pro+ Export
i18n.advanced	Pro+	Explicit under Pro+ Internationalization
white_label, team.roles, team.permissions, logging.full	Business	Explicit under Business
developer.api, developer.addons	Business	"advanced Platform / Developer functionality"
security.advanced_bot_detection	Business	"advanced Security functionality"
styling.global, styling.custom_css	Pro	Explicit under Pro Styling
layout.containers, layout.field_groups, layout.section_backgrounds	Pro	Explicit under Pro Layout
fields.advanced, fields.address, fields.file_upload, fields.signature, fields.gdpr	Pro	Explicit under Pro Advanced Fields
fields.product, fields.order	Pro+	Explicit under Pro+ Commerce
forms.templates, forms.import_export	Pro	Explicit under Pro Form Builder
forms.conversational	Pro+	Explicit under Pro+
dynamic.prefill	Pro+	Explicit under Pro+ Dynamic Data
wordpress.frontend_post, wordpress.user_management	Pro+	Explicit under Pro+ WordPress
privacy.gdpr, forms.restrictions	Pro	Explicit under Pro Privacy / Restrictions
validation.live	Free	Explicit under Free Validation
layout.columns, layout.sections, layout.responsive	Free	Explicit under Free Layout
security.honeypot, security.nonce	Free	Explicit under Free Security Core