What a plugin can reach.

• user.creating, user.created, user.updated, user.deleted hook events1.0

Needs a design Hooks on account creation must not expose credentials or let a listener change the role. A read-only notification payload and a narrow, audited mutation contract are needed rather than more filter hooks.

Planned: 0.2.27

Needs a design People records are personal data. A reader must be pinned to the current workspace, checked against relations:read for the caller, and able to redact fields.

Planned: 0.2.28

• ExternalAuthProvider and ExternalIdentity types (not yet wired to a registration path)

Needs a design An identity provider decides who an account belongs to. It needs a trust tier, operator-only enablement and binding per workspace. Sign-in events must be observe-only so no plugin can capture credentials or block sign-in.

Planned: later

• tenant.creating to tenant.deleted hook events1.0
• Veto a workspace deletion inside its transaction1.15
• Owned tables cascade on workspace deletion (PluginTablesInterface)1.20

Needs a design Install-wide plugins see every workspace's events. Hook subscriptions scoped to a workspace need a design before more workspace data is exposed.

Planned: 0.2.28

• Route requiredPermission enforced by the host1.2
• PermissionResolver: read-only permission checks1.16
• Permission checks scoped to one record1.17
• Plugin-declared resource types1.18
• Role checks scoped to one record1.22
• Declared permissions and seeded roles (PluginRolesInterface)1.0

Needs a design Anything that grants authority can escalate privilege. Role seeding and grants must be limited to the plugin's own roles and permissions, and every check must be bound to the caller's workspace by the host.

Planned: 0.2.27

Needs a design Delegation transfers authority, so plugins may observe and refuse it but must never create it.

Planned: later

• Plugin rule kinds in groups and routing (RoutingRuleResolverInterface)1.37
• Audience rule vocabulary shared with groups1.38

Needs a design A plugin rule resolver returns people for a workspace. The host must drop anyone who is not an active member of that workspace rather than trusting the resolver.

Planned: 0.2.28

• ou.* hook events, including role assignment and a delete veto1.0
• Plugin OU types an admin adopts1.30
• ouScopePicker block1.32

Planned: 0.2.28

Needs a design A registration check may accept or reject, never set the role or unit, or it becomes an escalation path.

Planned: 0.2.27

Needs a design Relations hold family and guardian links. Writes need permission-checked contracts.

Planned: later

Planned: 0.2.28

• documentViewer block1.36
• document.issuing (veto and checks), document.issued, document.rendered events1.49
• Issue documents as the person (Documents::issue)1.56
• Issue in the background where the workspace allows it1.58
• PluginDocumentStore, QR verification links and tracking1.63
• Document numbering rules and document.numbered1.65
• Preflight an issue without writing1.66
• document.revised1.68

Needs a design Document visibility depends on the caller and the route. A reader must apply the host's visibility policy per caller, and withdraw or revise must keep the audit trail intact.

Planned: 0.2.27

• Template slots in plugin.json1.55
• Template slots and merge-field providers for code plugins1.56

Needs a design Merge fields and editor blocks end up in printed, immutable documents. Providers must be held to the caller's workspace and permissions by the host, and plugin block markup needs a sandbox and server-side schema checks.

Planned: later

• DocumentRenderer, FlowDocument, PageSpec1.41
• Inline runs in flowing text1.44

Needs a design HTML or CSS input to the renderer would be an injection and server-side request surface. Keep input structured.

Planned: 0.2.28

• Plugin routing rules that resolve recipients1.37

Needs a design Acting on a route is an approval on a person's behalf. It needs the actor bound by the host and the agent proposal policy.

Planned: later

• form block and input blocks1.8
• Form preload from the plugin's own GET (dataSource)1.40
• Discriminated sub-forms (variant)1.42
• Anonymous form posts ('public' => 'form', PublicForm)1.67
• Anonymous link reads ('public' => 'read', PublicRead)1.69

Planned: later

Needs a design Submissions hold personal data and anonymous input. Readers must respect member and reviewer scope, events should carry ids only, and a plugin field type on a public form needs the same gate public forms already have.

Planned: 0.2.27

Needs a design Attendance, quorum and decisions are legal facts. Writes need a host-bound actor and audit.

Planned: later

• inbox and timeline blocks for the plugin's own items1.31

Needs a design Each source must answer only for the caller in the current workspace. The host has to enforce that rather than trust the source.

Planned: 0.2.28

• Plugin window types an admin adopts1.39

Needs a design A closed period is a bookkeeping rule. Writes into it need a host-enforced guard.

Planned: later

• plugin.json manifest1.47
• Manifest expressions1.48
• Record types1.50
• Record rules, defaults, computed and locked fields1.51
• Automations1.53
• Manifest tests1.54
• issue_document automation step1.57

Needs a design Triggers from another area's events must carry ids and re-read under the run's permissions. send_webhook needs an egress allowlist.

Planned: later

• Plugin-owned data types with generic admin screens1.20
• Lifecycle writes and guards1.24

Planned: later

Needs a design A report aggregates across records, so row visibility per caller must be enforced by the host or totals leak across units.

Planned: 0.2.28

• Data types that declare search are found by /api/search

Needs a design Results must be filtered by what the caller can see. The declarative path is safe; a free-form source needs host-side scoping.

Planned: 0.2.28

• Declared, typed, namespaced settings keys1.21

Needs a design The internal settings service also covers core and install-wide keys. The SDK reader must be limited to the plugin's own keys in the current workspace.

Planned: 0.2.27

• PluginSecrets: encrypted per plugin and workspace1.60

Needs a design The host, not the caller, must decide which plugin and workspace a store belongs to.

Planned: 0.2.27

• Multipart uploads1.5
• PluginFiles and ready-made file routes1.63

Needs a design The host must decide which plugin and workspace a store belongs to.

Planned: 0.2.28

• NotificationTransport contract (not yet discovered from plugins)1.14

Needs a design Sending must be bound to the current workspace, reach only its members, and respect opt-outs; a plugin must not be able to pose as a security or billing notice.

Planned: 0.2.27

• English and Arabic labels on settings, data types, manifest screens and agents1.21

Planned: 0.2.27

• Theme token override from a plugin route1.12

Needs a design The theme route is public and runs on every page. Per-workspace overrides need a design.

Planned: later

• Frontend features become sidebar items; navigation.register hook1.2

Needs a design Navigation listeners receive the whole menu. Contributions should be append-only with links checked as internal paths.

Planned: 0.2.27

• One home card per plugin1.62

Planned: 0.2.28

• Declared audited plugin events1.29
• timeline block1.31

Needs a design Audit rows must be attributed by the host to the plugin that wrote them, so one plugin cannot write rows under another's or core's name.

Planned: 0.2.27

• Plugin job handlers1.28

Needs a design Enqueueing must accept only the plugin's own job names in the current workspace.

Planned: 0.2.27

• Plugin health probes on the status page1.19

Planned: later

• Declared sellable limits in the plan catalogue (PluginEntitlementsInterface)

Needs a design Charging moves money. It needs consent, the ledger, idempotency and webhook trust; meters must stay bound to the workspace.

Planned: 0.2.28

• Frontend features (crud, action, custom)1.2
• Server-driven blocks1.6
• Data blocks1.7
• chart block1.10
• Sort, filter and paging1.11
• Embedded screens1.13
• dataRecord and recordFields blocks1.33
• visibleWhen and accessGate1.34
• flow block1.35

Needs a design Embedded screens are not isolated from the app. Third-party UI needs a separate origin, a message bridge and a scoped token first.

Planned: later

Needs a design A slot receives the record it sits on. It needs per-record permission checks and the same own-routes rule blocks have.

Planned: 0.2.28

• Plugins run under the offline desktop PHP host1.27

Planned: later

• Plugin routes become MCP tools
• Hand-authored tools1.43
• Tool annotations1.45
• Tool context1.46
• Toolsets, visibility, agent policy and undo windows1.52
• Caller identity: person, agent or system1.59

Needs a design Whether an agent must ask first has to come from the host's view of the operation, never from a hint the plugin declares.

Planned: 0.2.27

• Plugin prompts1.9

Needs a design Prompt text goes straight into an agent's context. Third-party prompts should be limited to verified plugins and gated by permission.

Planned: later

• Agent presets1.61
• Plugin agents1.64

Planned: later

• agentPolicy propose and suggest-only on plugin tools1.52

Needs a design Only the granting person decides a proposal. Any plugin view must be read-only.

Planned: 0.2.28

Needs a design Outbound calls need a guard against private addresses, signing secrets kept in PluginSecrets, a workspace check per event and id-only payloads.

Planned: later

• SDK version constraint1.1
• Core version constraint1.4

Needs a design Installing and enabling stay operator-only. A lifecycle callback must not let a plugin enable others.

Planned: 0.2.28

Needs a design Plugin payloads must pass through the same scrubber before they reach logs or the error tracker.

Planned: 0.2.28

• Migrations1.0
• Tenant-isolation conformance kit1.3
• SchemaInspector1.23
• Upsert and SequenceAllocator1.25
• Undeclared-reference linter1.26
• Offline-host conformance kit1.27

Needs a design Workspace isolation is checked by lint and tests, not enforced. A connection bound to the workspace is a design question.

Planned: later

• Request and Response1.0
• Multipart requests1.5
• Route schemas in the OpenAPI document

Needs a design Routes cannot tell an agent from a person today, so they cannot apply stricter rules to agents.

Planned: 0.2.27

• Events catalogue1.0
• Veto exception1.15

Needs a design Every listener can rewrite the payload today. Observe-only listeners, and a per-event list of what may change, are needed before more events are published.

Planned: 0.2.27

Needs a design Commands run with full database rights outside RBAC. A plugin command must be operator-only and name its workspace explicitly.

Planned: later

Planned: 0.2.27