Start Here
What Extensions Can And Cannot Do
Extension v1 is a local, source-controlled SDK for adding bounded capabilities to a MyronCMS install. It is strongest when an extension contributes a namespaced action, optional isolated storage, or a small admin route that operates inside its own package boundary.
It is not a general plugin marketplace, public rendering hook system, or core override mechanism.
Human Path
A developer should first classify the extension idea:
- If it adds a new scoped API action under
/api/v1/x/{vendor}/..., it fits the current stable path. - If it needs local extension files, a manifest, a bootstrap payload, or isolated
{vendor}_*storage, it fits the current local authoring model. - If it needs marketplace installation, signing, sandboxing, dependency resolution, public render hooks, design token groups, snapshot sections, or core admin rail injection, it does not fit extension v1.
AI Path
An AI coding agent can help author a local extension package in the repository and run verification. It must obey the same constraints as a human developer: manifest validation, vendor naming, required scopes, namespace rules, and isolated storage.
An installed MCP client can only interact with loaded runtime actions. It cannot write extension PHP files and cannot grant itself trust. MCP access begins after a human/operator path has registered the extension, enabled it, granted scopes, and exposed the action.
Current Capability Matrix
| Surface | Current support | Notes |
|---|---|---|
| Local extension package | Stable current | Place files under app/extensions/{vendor}/; hyphenated directories normalize to snake_case vendors. |
manifest.json | Stable current | Requires vendor, name, version, requiredScopes, hasMigrations, and adminRoutes. |
| Bootstrap payload | Stable current | bootstrap.php can return actions directly or arrays with actions, micElementTypes, and mailTransports. Slice 1 focuses on actions. |
| Scoped actions | Stable current | Implement MyronAction; loader registers valid actions through ActionRegistry::registerExtension(). |
| Action API namespace | Stable current | Extension URIs must start with /api/v1/x/{vendor}/. |
| Action domain namespace | Stable current | Extension metadata domains must start with x.{vendor}.. |
| Non-empty schemas | Stable current | Extension action inputSchema and outputSchema cannot be empty arrays. |
| Scope grants | Stable current | Operators register, enable, disable, and grant scopes for extensions. |
| MCP exposure | Stable current | Actions with exposeToMcp: true can appear in tools/list when the caller holds the required scope. |
| Extension admin routes | Stable current | Routes can be declared in the manifest and mounted under /x/{vendor}/...; detailed route authoring belongs to a later guide. |
| Isolated migrations | Stable current | Migrations may operate on {vendor}_* tables; detailed migration authoring belongs to a later guide. |
| Load error capture | Stable current | Manifest, migration, and bootstrap failures are recorded without taking core requests down. |
Prohibited-Current Matrix
| Requested behavior | Current status | Why it is not documented as available |
|---|---|---|
| PHP event hooks | Prohibited current | Extension v1 does not provide an event hook API. |
| Marketplace browsing | Future/planned, not current | Admin/product direction may reserve this space, but runtime install support is not present. |
| Marketplace install | Future/planned, not current | Extension v1 is local/manual install only. |
| Design token group registration | Prohibited current | Extensions cannot add design token groups. |
| Public rendering hooks | Prohibited current | Extensions cannot hook public rendering in v1. |
| Snapshot contribution | Prohibited current | Extensions cannot contribute snapshot sections. |
| Core admin rail injection | Prohibited current | Extensions can mount isolated routes, not inject new core rail sections. |
| Code signing | Prohibited current | No signing contract exists in extension v1. |
| Sandbox isolation | Prohibited current | No sandbox isolation contract exists in extension v1. |
| Dependency resolution | Prohibited current | Extensions cannot rely on package dependency resolution. |
| Core table mutation | Prohibited current | Extension SQL migrations may only operate within the {vendor}_* table boundary. |
Scopes
Extension manifests must declare required scopes from the base scope vocabulary. The loader skips unregistered or disabled extensions, and rejects under-granted extensions. API and MCP callers still need the action's required scope at call time.
Safety Boundary
If a desired extension requires one of the prohibited-current surfaces, do not work around the runtime. Treat it as future evaluation work and start a new MCD cycle before changing platform behavior.
For the deeper Core Concepts policy treatment, see Current boundaries.
Verification
Use the verification guide after authoring an extension. A valid extension idea should be checkable through:
- local CLI verification,
- action dispatch through
/api/v1/x/{vendor}/..., and - MCP discovery/call behavior when the action is exposed and the caller has scope.