Getting Started

Require the package alongside its main package at the same version line; this package releases in lockstep with filamentboot/filamentboot, so always install matching constraints (e.g. "filamentboot/*": "0.5.*") rather than mixing minor versions across the two.
First place to look is now the README — v0.5.3 is the first release where README and LICENSE are shipped in the archive, so the install/config snippets are finally authoritative for this version. Before this, you had to read the main package's docs and infer.
Typical first use case: scaffold a Filament panel/admin surface with the package's opinionated base classes, then publish the config and stubs so your app owns them (php artisan vendor:publish --tag=filamentboot-config, then any -stubs/-views tags listed in the README).
After publishing, run php artisan optimize:clear (or at minimum config:clear and view:clear) before assuming a config change took effect.

Implementation Patterns

Treat the package as scaffolding, not runtime magic. Generate resources/pages with the provided commands, then commit the generated files. Day-to-day work happens in your app's copies, not in vendor/.
Publish-then-extend. Subclass the package's base Resource/Page classes rather than editing vendor stubs; keep the published stubs in stubs/ under version control so regeneration is repeatable across the team.
Lockstep upgrade workflow: bump both packages in one Composer command (composer require filamentboot/filamentboot:0.5.3 <this-package>:0.5.3), then re-publish and diff stubs against what's already in the repo. Because these releases are version-aligned, a mismatched pair is the most common source of confusing "class not found"/signature errors.
Config-driven panels. Keep panel registration in config + a single service provider so multiple panels (admin, tenant, etc.) share the package's defaults and you only override per-panel what differs.
CI check: add a step that asserts both package versions resolve to the same tag (composer show filamentboot/*) so a partial bump fails the build instead of production.

This release is docs-only. v0.5.3 adds README/LICENSE and aligns the version number; there are no code changes, no deprecations, no migrations. Safe drop-in — but also don't expect behavior fixes here.
Pre-1.0, so treat every minor as potentially breaking. Pin exact versions or narrow ranges; ^0.5 is acceptable only if you read each release note, since the project aligns versions rather than promising semver stability.
Lockstep is a trap for partial upgrades. If a colleague bumps only the main package, published stubs may silently lag behind base class signatures. Re-publish and diff after every upgrade.
vendor:publish overwrites silently with --force and does nothing without it when files exist — diff before forcing, or your local stub customizations vanish.
Docs are primarily Chinese. Budget for that on onboarding; the newly shipped README is the best English-adjacent reference you'll get at 0.5.x.
Debugging tip: when a panel renders unexpectedly, check published config/view overrides first, then the cached compiled views — stale published assets are far more often the cause than a package bug.
Extension points: favor published stubs, published config, and subclassing over patching vendor. If you find yourself needing a hook that doesn't exist, that's a candidate to raise upstream rather than fork, given how tightly the version lines are coupled.