Download the PHP package milpa/core without Composer

# Milpa Core > The framework-agnostic **contracts core** of Milpa — a modular PHP runtime for applications operable by **both humans and agents**. Not another web framework: the primitives that let modules declare capabilities, expose tools, and gate actions behind verification. [](https://github.com/getmilpa/core/actions/workflows/ci.yml) [](https://packagist.org/packages/milpa/core) [](https://www.php.net/) [](LICENSE) [](https://getmilpa.github.io/core/) `milpa/core` is the dependency-light heart of the framework: the attributes, events, value objects, enums, interfaces, and the verification seam that every Milpa module builds on. **No Doctrine, no HTTP client, no framework kernel** — just the contracts and primitives, so you can depend on them from anywhere. ## Install ## Why Milpa Most PHP frameworks are built for one kind of caller: a human writing code, or a browser sending requests. Milpa is built for **two** — humans *and* agents operating the same application through the same declared surface. Modules don't just register routes and services. They declare the **capabilities** they provide and require, expose **tools** an agent can invoke, and gate mutating actions behind **verification** — deterministic checks, human/agent approvals, or async results. The contract loop that runs through the whole system: Three seams in this package make that loop possible: - **Capability system** — a plugin manifest declares what it *provides*, *requires*, and *suggests*, so the runtime can wire modules together and reason about what's installed. Each entry comes in either real shape `#[PluginMetadata]` sanctions: a bare interface FQCN (legacy) or a structured capability record (`{id, interface, contractVersion, …}`), parsed by the capability value objects' `parse()` — mixing both in one list is the incremental migration path. - **Agent tool-readiness** — `ToolProviderInterface` / `ToolRegistryInterface` let a module publish declarative tools that both humans and agents can discover and call. - **Verification seam** — `VerifierInterface` gates a mutating action behind a deterministic evaluation, a human/agent approval, or a pending async result that resolves through an event. **Be honest about scope:** this package ships the **contracts and primitives only**. It does not run an HTTP server or boot an application by itself. The web tier lives in the sibling **`milpa/http`** package, and the runtime/CLI is **`coa`**. Depend on `milpa/core` when you want to build against those seams without pulling in a framework. ## Quick example Value objects are immutable and self-validating. For instance, `SemanticVersion`: ## What's inside | Namespace | What it provides | |-----------|------------------| | `Milpa\Attributes` | Declarative attributes (`RegisterService`, `BusinessRule`, `Subscribe`, …) | | `Milpa\Interfaces` | Core contracts, grouped by seam: `Di`, `Plugin`, `Event`, `Config`, `Observability`, `Tooling`, `Verification` | | `Milpa\ValueObjects` | Immutable, validated values (`SemanticVersion`, capability & verification VOs, …) | | `Milpa\Enums` | Shared enums (`ApprovalPolicy`, `VerificationStatus`, `DispatcherType`, …) | | `Milpa\Events` | Framework event contracts + dispatch primitives | | `Milpa\DTO` | Data-transfer objects passed across seam boundaries | | `Milpa\Exceptions` | Typed exception hierarchy for the contracts | | `Milpa\Services` | Framework-agnostic service contracts and helpers | | `Milpa\Support` | Small framework-agnostic utilities | Every public symbol carries a DocBlock — the API reference is generated straight from them. ### One law for capability identity `Milpa\Services\CapabilityMatcher` is the single criterion for *"is this provision the thing that requirement is asking for?"*. It lives here, in the package with no dependencies, because everyone who asks that question has to get the same answer: The two are separate because they are asked at different moments. Before boot, nothing knows contract versions yet, and asking whether the capability *exists at all* is a different question from whether the version fits — collapsing them makes a missing provider and an incompatible one look identical to whoever has to fix it. It exists because there were **four** implementations of this comparison in the family and they did not agree. Four comparisons of the same thing are four chances to disagree; the only question is when. ## Requirements - PHP **≥ 8.3** ## Documentation **Full API reference: [getmilpa.github.io/core](https://getmilpa.github.io/core/)** — generated straight from the source DocBlocks and dressed with the Milpa design system. ## Contributing Contributions are welcome — see [CONTRIBUTING.md](CONTRIBUTING.md). Please report security issues via [SECURITY.md](SECURITY.md), and note that this project follows a [Code of Conduct](CODE_OF_CONDUCT.md). ## License [Apache-2.0](LICENSE) © Rodrigo Vicente - TeamX Agency. --- Milpa is designed, built, and maintained by **[Rodrigo Vicente - TeamX Agency](https://teamx.agency/?utm_source=github&utm_medium=readme&utm_campaign=milpa&utm_content=core)**.