Getting Started

v1.0.0 is the initial release, so treat the package README, composer.json, service provider, config file, and migrations as the source of truth before building against it.
Install with Composer using the package name confirmed from Packagist/README, then publish config, migrations, and any assets according to the module instructions. Run migrations and seed any required permissions/reference data.
Look first at the module’s service provider and routes to understand what is auto-registered: admin panel resources, API routes, migrations, policies, commands, or events.
If this is a TomatoPHP/Filament-style module, register or verify the admin panel integration, then clear caches and check resource discovery.
First practical use case: create the HR reference data needed by your app (for example departments/job titles), create or link an employee record to a user, then exercise the main CRUD and approval/list views in the admin panel or routes exposed by the module.

Implementation Patterns

Treat package models as the domain core but wrap day-to-day writes in application services/actions so you can add validation, notifications, audit logging, and tenant scoping without editing vendor code.
Add application-specific fields through your own migrations and model extensions/relationships rather than modifying published vendor migrations.
Integrate authorization through Laravel policies/gates and align them with the module’s permission names. For HR data, verify access at both route/controller and query levels.
Use observers/events for onboarding, manager assignment, leave approval, or status changes if the module dispatches them; otherwise wrap create/update flows in your own service layer.
For APIs, expose your own controllers/resources over package models to control payload shape and avoid leaking sensitive HR fields.
Seed reference data idempotently (updateOrCreate) so repeat deploys do not duplicate departments, titles, or permissions.
Add feature tests around the package’s routes and models you depend on most, especially employee CRUD, authorization, and any approval workflow.

The v1.0.0 release notes are only a changelog link, so inspect the actual changelog and package metadata before upgrading; pin a version in composer.json.
Publishing repeatedly can duplicate config, migrations, or permissions. Review published files and avoid blind --force overwrites in existing environments.
Confirm table names, foreign keys, soft deletes, and date casting before writing joins or reports; do not assume the module’s schema.
HR data is sensitive. Check authorization, auditability, and tenant/company scoping early, especially if the module exposes admin routes by default.
If Filament resources are included, clear caches and verify panel registration/resource discovery after install or deploy.
Watch timezone and date handling for attendance/leave-style features, and rounding rules if payroll-like calculations are included.
Main extension points are likely config, published views/migrations, service container bindings, model observers/events, and route middleware. Prefer these over vendor edits.