Extensions SDK Overview

The MyronCMS Extensions SDK lets developers add local extension packages under app/extensions/{vendor}/. In extension v1, the stable path is deliberately small: a package can declare a manifest, return runtime contributions from bootstrap.php, and register namespaced MyronAction API verbs that may also be exposed as MCP tools.

This is not a marketplace install system. An extension is authored in the repository, registered by an operator, granted scopes, loaded by MyronExtensionLoader, and then made available through the API action registry when its contracts pass.

Current Model

An extension package is a local directory with a snake_case vendor identity:

app/extensions/{vendor}/
  manifest.json
  bootstrap.php
  actions/
  admin/routes/
  migrations/
  README.md

The manifest declares the extension identity, version, required base scopes, whether migrations are present, and optional admin routes. At load time, MyronExtensionLoader reads extension manifests, checks registration and grants, runs isolated migrations when enabled, requires bootstrap.php, and registers returned actions through ActionRegistry::registerExtension().

The first supported extension outcome is a namespaced action:

• URI: /api/v1/x/{vendor}/...
• domain: x.{vendor}....
• input and output schemas: non-empty arrays
• required scope: one of the core API scopes
• MCP exposure: controlled by action metadata, usually exposeToMcp: true for tool-facing extension actions

Human Path

A developer authors extension files locally, then an operator registers and enables the extension from the Extensions admin surface. Once the extension is enabled and has the scopes its manifest requires, MyronCMS loads its actions and routes.

The Start Here path is:

1. Read What extensions can and cannot do.
2. Build the small Hello World extension.
3. Run the checks in Verify your extension.

After that first working extension, read the Core Concepts pages:

• Extension package anatomy
• Manifest schema
• Vendor namespace rules
• Scopes and grants
• Load lifecycle
• Current boundaries

AI Path

There are two different AI roles, and the docs keep them separate.

An AI coding agent working in the repository can author local files under app/extensions/{vendor}/, follow the manifest and namespace rules, and run local verification commands.

An installed MCP client connected to a running MyronCMS install cannot create those PHP files. It can discover and call exposed tools only after the extension has been registered, enabled, granted scopes, and loaded. MCP tools/list filters actions by exposeToMcp: true and by the caller's held scopes.

Scopes

Extension manifests can request only the six base scopes:

Hello-world uses content.read because it registers a read-only greeting action.

Safety Boundary

The current SDK should be documented as a bounded local SDK. Do not describe unsupported platform behavior as available now. In particular, extension v1 does not provide marketplace install, dependency resolution, signing, sandbox isolation, public render hooks, design token group registration, snapshot contribution, or core admin rail injection.

Verification

The local smoke test for the extension substrate is:

php app/tests/verify-extension-system-foundation.php

That command verifies the implemented foundation: manifest parsing, namespace rejection, scope grants, loader behavior, sample action dispatch, migration isolation, load error capture, admin route mounting, and Extensions rail visibility.