Laravibe Standards Laravel Package

Getting Started

v0.5.0 is a breaking release, so start with the upgrade guide (linked from the release notes) before touching code — especially if you are coming from softpulze/laravibe-standards, since the package now lives under thesoftpulze.

Minimal path for a new project:

1. composer require thesoftpulze/laravibe-standards --dev (or as appropriate for your setup).
2. Publish the package assets you need: config, stubs, collections, Boost guideline, and skills. Prefer publishing only what the project uses rather than everything.
3. Open the published config first. It is the primary map of what the package provides and what can be overridden.
4. Run the package’s install/publish command from the README, then generate one artifact (a class, collection, or guideline) to confirm stubs and collections resolve correctly.

First practical use case: use the package as the project’s standards layer — publish its stubs and Boost/AI guideline into a fresh Laravel app, commit the published files, and verify that generated code matches the team’s expected conventions.

Where to look first:

• The upgrade guide for v0.5.0.
• The published config file.
• The resources/stubs (or equivalent) directory.
• The Boost guideline and split skill directories.
• The package’s own tests/examples for collection usage.

Implementation Patterns

Treat the package as a versioned standards dependency, not as vendor code you edit in place.

Publish once, commit, review on upgrade. Publish config, stubs, guidelines, and skills into the repo, commit them, and review the diff on every package upgrade. This makes standards changes visible in pull requests instead of silently changing generated output.

Customize stubs after publishing. Keep project-specific stub changes small and documented. Because v0.5.0 includes stub and collection fixes, diff the newly published stubs against your committed versions before replacing anything.

Use the split skills deliberately. v0.5.0 splits skills into separate units. Publish and wire only the skill sets the team actually uses (for example, one set for backend conventions, one for AI/Boost workflows), and keep the mapping in the README so onboarding is repeatable.

Extend collections rather than editing them. Use the package collections as a base and add project-specific items in your own collection classes/config. This keeps upgrades from overwriting local customizations.

Integrate into CI. Pin the package version, run the package’s standards/lint checks in the pipeline, and fail builds on generated-code drift. Add a step that regenerates a sample artifact and checks it matches the committed stub output.

Upgrade workflow. Create a branch, update the package, read the upgrade guide, republish assets into a temporary directory, diff against committed files, then merge selectively. Run the test suite and regenerate one or two representative artifacts before merging.

Team and AI tooling consistency. Commit the Boost guideline and published skills so every developer and AI assistant works from the same conventions. Document which guideline file is authoritative to avoid duplicate or conflicting instructions.

Gotchas and Tips

• Breaking change: split skills. Publish tags, paths, and expected directory layout likely changed. Old publish commands or scripts may publish stale or partial skill sets. Re-read the publish section of the README and update scripts accordingly.
• Vendor rename. The upgrade guide references moving from softpulze/laravibe-standards to thesoftpulze/laravibe-standards. Remove the old requirement, update composer.json/lock files, and search the repo for the old vendor string in published configs, docs, and CI scripts.
• Duplicate Boost guidelines. If you previously published a guideline under the old package, remove the old file before publishing the v0.5.0 version. Two guidelines can produce conflicting AI/tooling behavior.
• Stub and collection fixes cause diffs. Regenerated code may differ from what you committed previously. Do not blindly --force publish over customized stubs; back up and diff first.
• Publish tags can be destructive. Use --force only after reviewing what will be overwritten, and prefer publishing to a temp path for comparison.
• Clear caches after publishing. Run php artisan config:clear and any relevant cache clears after changing published config or guideline paths.
• Pin versions in CI. A floating constraint can pull a breaking minor release like v0.5.0 into builds unexpectedly. Use a fixed version or a constrained range.
• Extension points to prefer: published config values, configurable stub paths, custom collection registration, and package discovery. Avoid editing files under vendor/ directly.
• Debugging tip: if a generated artifact looks wrong, check the resolved stub path first (published vs package default), then the collection definition, then the config cache. Most issues come from a stale published stub or an old guideline still being loaded.