Package ecosystem

The PAM binary owns only runtime-level capabilities. Applications grow through ordinary Composer packages with versioned PHP contracts.

pam composer require pushinbr/pam-native-auth
pam composer require pushinbr/pam-native-observability

pam composer is the canonical package interface. Explore official packages in the capability catalog or discover any compatible package on Packagist.

This is how PAM grows without becoming a monolith. The runtime provides the hard systems boundary; packages provide focused application contracts using the dependency manager PHP developers already trust. No parallel ecosystem, custom lockfile, or proprietary package format is required.

Package	Purpose
pushinbr/pam-http	Express-like routing with controller method mapping, Laravel-style validation, Resources, dependency injection and middleware
pushinbr/pam-socket	WebSocket events, rooms, broadcasts, acknowledgements, adapters, and resume support
pushinbr/pam-http-psr	PSR-7, PSR-15, and PSR-17 interoperability using official interfaces
pushinbr/pam-http-testing	In-memory HTTP client and fluent response assertions
pushinbr/pam-contracts	Small contracts for packages that extend PAM
pushinbr/pam-native	PHP authoring and protocol surface for native Android applications
pushinbr/pam-native-nitro	Offline-first, model-driven local data engine on PAM Native SQLite workers
pushinbr/pam-native-ui	Retained-native Material 3 component system for Android and iOS
pushinbr/pam-laravel	Laravel bridge, Octane integration and framework lifecycle contracts
pam/desktop	Typed PHP API and worker loop for PAM Desktop
push-in/pam-skeleton	Versioned API starter consumed by pam init

PAM first. Composer remains Composer.

PAM discovers the normal Composer autoloader, including projects with a custom config.vendor-dir. It does not introduce a package wrapper or alternate lockfile.

Applications and package authors invoke Composer through PAM’s private PHP runtime:

pam composer install
pam composer require vendor/package
pam composer update

Compatibility with Composer does not guarantee compatibility with every package. A package may depend on an unavailable extension, assume FPM or Apache, install process-global handlers, or retain request state in a singleton.

Extension model

Server packages can publish providers through the versioned core contracts. Native plugins may ship PHP providers, components, themes, Android resources, manifests, Maven dependencies, AARs, JNI libraries, native modules, and native view factories.

Protocol and enum identifiers are sequential integers and append-only within a protocol version.

Distribution repositories

pam-native-php and pam-native-ui-php are publication mirrors of their canonical source repositories. They exist so generated and packaged PHP artifacts can be distributed independently; they are not separate products or alternative installation paths. See the distribution mirror contract.