Addon Development Overview

Purpose

Addon Development explains how to build a governed addon in Amvionlie.

A governed addon is not a folder with a button and a wish. It has identity, contracts, permissions, routes, runtime ownership, verification, and clear boundaries.

What a governed addon owns

A governed addon owns its declared feature area. That may include admin screens, public routes, data tables, permissions, public target providers, assets, tests, and documentation.

It does not own Core helpers, the Admin shell, Menu Manager storage, global permissions, Dashboard widget placement, or other addons' data.

Required contract shape

A normal governed addon should include:

• `manifest.php`
• `bootstrap/install_contract.php`
• `src/schema_contract.php` when it owns tables
• `src/permissions_contract.php` when it exposes protected behavior
• `routes/routes.php` when it registers public or admin routes
• `src/admin_runtime.php` or a clearly named runtime owner
• `src/public_targets.php` when Menu Manager should link to frontend targets
• `README.md`
• smoke tests when the pattern supports them

Runtime rule

Runtime files own behavior. Admin runtime renders admin surfaces. Public runtime renders frontend surfaces. Keep behavior scoped to the owning addon and consume central helpers instead of duplicating them.

Integration rule

Integrate through narrow contracts: routes, public target providers, hooks/events, permissions, schema contracts, and central helper APIs. Do not reach sideways into another addon because the table is nearby and looks friendly.