Front-end consumption

Until v0.5 the plugin lived entirely inside /wp-admin/. From v0.6 onwards entities, forms, lists, records and actions can be embedded on any post / page of the public site via the **[pfm_*] shortcodes**. The same React mounts that power the admin SPA render client-side, but talk to a relaxed REST layer that delegates authorisation to the permissions resolver.

The four shortcodes

Shortcode	Renders	Required attrs	Optional attrs
`[pfm_form]`	Create / edit form	`entity`	`sys_id`, `return_url`, `success_message`
`[pfm_list]`	Records table	`entity`	`filter`, `columns`, `page_size`, `view`, `saved_view`
`[pfm_record]`	One record card	`entity`, `sys_id`	`template`
`[pfm_action]`	Single action button	`action` (as `entity.slug`), `sys_id`	`label`, `style`

The bundle (assets/dist/assets/frontend-.js + frontend-.css) is enqueued only on pages that actually contain one of these shortcodes — detected via has_shortcode() for classic content and has_block() for block themes. The admin SPA bundle is never loaded on the front-end.

Worked example — public lead-capture form

Create an entity, e.g. lead, with the fields you want (name, email, message).
In PF Manage → Schemas → lead → Permissions, tick public in the create row. Leave the other rows on data_writer / data_reader so submissions are not publicly visible.
Create a new WP page and paste [pfm_form entity="lead" success_message="Thanks!"].
Open the page logged out. The form renders, submits, and the record appears in the admin list immediately.

For a complete recipe with directory listings + the demo seed script see demo.