composite-pack-manifest schema

The newer composite-pack / Country-or-Industry-Pack / Code-Plugin-style manifest contract (contractVersion/publisher/distribution/12 extension-point contributions) — a genuinely different artifact type from an ordinary .spk plugin.json (use 'plugin-manifest' for that).

Pull the full JSON Schema: erp schema pull composite-pack-manifest  ·  MCP: erp_get_schema {"name":"composite-pack-manifest"}

Top-level properties

Property	Type	Required	Notes
contractVersion	—	yes
id	#/$defs/identifier	yes
version	#/$defs/semver	yes
publisher	string	yes
displayNameKey	string	yes
descriptionKey	string	yes
distribution	enum	yes	one of: locked, editable
dependencies	array
contributions	#/$defs/contributions	yes
hasUpgradeMigration	boolean
hasDataErasureHook	boolean
frontendBundle	object		2026-09-03, closes the dynamic-frontend-plugin-loading gap (ai/domains/ai-native-developer-platform-gap-analysis.md): a compiled @erp/* frontend bundle a runtime loader fetches from the real, generic engine-file content endpoint (GET /api/v1/files/{fileId}/content) and dynamically import()s, instead of the code shipping inside a host application's own build. Optional and additive - absent on every manifest that predates this field (every real plugin in the fleet today except this pass's own proof plugin), which a frontend loader must treat as a cheap, silent no-op.

Named sub-definitions

identifier, semver, versionRange, dependency, argKind, actionTypeContribution, functionContribution, idDescription, networkScopedContribution, scheduledJobContribution, themeContribution, menuItemContribution, localeBundleContribution, contributions