This repository is the canonical documentation hub for the Liberu ecosystem. It defines how independently versioned Laravel modules, presentation packages, themes, APIs, applications, testing, and operations fit together.
Start with Liberu architecture for the portfolio view or Module architecture when implementing a package.
| Standard | Purpose |
|---|---|
| Liberu | Ecosystem composition, application boundaries, and portfolio adoption |
| Modules | Independent Composer packages, dependency direction, lifecycle, and implementation process |
| Boilerplate | Shared Laravel application foundation and cross-repository services |
| Themes | Theme packaging, inheritance, assets, accessibility, and visual integration |
| Filament | One-to-one Filament presentation modules, panels, plugins, resources, pages, and widgets |
| Livewire | Livewire 4 component packaging, state, security, registration, and interaction |
| Nuxt | Nuxt 4 API-consuming presentation packages, SSR, routing, typed clients, and deployment |
| React + Inertia | React 19.2 and Inertia 3 API-consuming presentation packages, pages, forms, hooks, SSR, and deployment |
| API | One-to-one API presentation modules, contracts, security, versioning, and composition |
| Testing | Pest/PHPUnit suites, ownership, coverage, compatibility, and CI evidence |
| CI | GitHub Actions workflows, required checks, release gates, environments, and deployment automation |
| Documentation | Documentation structure, quality, validation, and maintenance |
| Repository README standard | Required landing-page content for Liberu repositories |
| Jetstream | Authentication, security features, and Jetstream team integration |
| Socialstream | OAuth provider integration for Jetstream and Filament |
| Policy and permissions | Laravel policies, Spatie Permission, and Filament Shield boundaries |
| Teams | Team context, membership, invitations, and authorization rules |
| Tenancy | Tenant boundaries, team isolation, context lifecycle, jobs, APIs, and verification |
| Settings | Typed, encrypted, multi-scope settings with optional API and presentation adapters |
| PSR standards | PHP-FIG interoperability, coding, autoloading, HTTP, cache, events, and clock standards |
| Installation | Supported prerequisites and local installation workflow |
| Deployment | Standalone, Docker Compose, and Kubernetes deployment paths |
| Contributing | Contribution workflow and engineering quality gates |
| Security | Vulnerability reporting and security response process |
The generated documentation hierarchy expands every independent module listed by an application scope:
- Feature specifications — 517 detailed module documents covering full scope, implementation, security, operations, and verification.
- API module specifications — 517 matching
module-{independent-module-name}-apidocuments covering contracts, audiences, implementation, and API verification. - Filament 5 implementations — 517 matching
module-{independent-module-name}-filamentpresentation implementations with panel/resource/page/widget mappings. - Livewire 4 implementations — 517 matching
module-{independent-module-name}-livewirepresentation implementations with component/state/interaction mappings. - Nuxt 4 implementations — 517 matching
module-{independent-module-name}-nuxtpresentation implementations consuming the corresponding API modules. - React 19.2 + Inertia 3 implementations — 517 matching
module-{independent-module-name}-react-inertiapresentation implementations consuming the corresponding API modules.
Every feature and API document links back to its authoritative application scope. Feature packages remain presentation-neutral; Filament, Livewire, and API behavior belongs in matching optional presentation packages.
| Application | Domain modules | API modules | Filament 5 | Livewire 4 | React + Inertia |
|---|---|---|---|---|---|
| Accounting | 105 | 105 | 105 | 105 | 105 |
| Automation | 11 | 11 | 11 | 11 | 11 |
| Billing | 16 | 16 | 16 | 16 | 16 |
| Browser Game | 15 | 15 | 15 | 15 | 15 |
| CMS | 81 | 81 | 81 | 81 | 81 |
| Control Panel | 15 | 15 | 15 | 15 | 15 |
| CRM | 95 | 95 | 95 | 95 | 95 |
| Ecommerce | 105 | 105 | 105 | 105 | 105 |
| Genealogy | 14 | 14 | 14 | 14 | 14 |
| Maintenance | 14 | 14 | 14 | 14 | 14 |
| Real Estate | 15 | 15 | 15 | 15 | 15 |
| SAP-style Enterprise Suite | 16 | 16 | 16 | 16 | 16 |
| Social Network | 15 | 15 | 15 | 15 | 15 |
- Maintenance defines field-service and asset-maintenance scope.
- Real Estate defines agency, property, sales, and lettings scope.
- Browser Game, Genealogy, and Social Network are independent application scopes.
- Control Panel covers infrastructure and hosting operations.
- Select the application scope and identify the independent module.
- Use its document under
features/as the detailed capability and implementation specification. - Apply
MODULES.mdfor package boundaries and lifecycle. - Add only the required one-to-one presentation packages using
FILAMENT.md,LIVEWIRE.md, andAPI.md. - Implement and verify the package using
TESTING.md,DOCUMENTATION.md, and the module's definition of done.
Changes to package boundaries, public contracts, ownership, or cross-repository policy require corresponding documentation updates and an architecture decision record where specified by the relevant standard.