Bedrock Commands Laravel Package

Product Decisions This Supports

• Content-model velocity: Every new page-builder section currently costs a multi-file change (set entry in blocks.yaml/article.yaml, fieldset, view). make:bedrock-block/make:bedrock-set collapse that into a single command — directly informs how aggressively we can roadmap new block types per sprint.
• Refactor cost, not just scaffold cost: rename:bedrock-* updates the set definition, its fieldset, its view, and all stored entries. That converts "renaming a set" from an estimate-sized migration ticket into an operational chore — a real input to whether we rename/clarify block names as the design system evolves.
• Risk decisions on destructive operations: delete:bedrock-* removes a set from its field and from all entries. This is a data-touching path. It should trigger explicit decisions on staging-first execution, backups, and who is authorized to run it — not just be treated as a dev convenience.
• Build vs. buy: The alternative is in-house Artisan scripts or hand-editing. This package makes "buy" (adopt) the cheaper option for any team already on Bedrock-style YAML block configs.
• Standardization / house style: Publishable config (bedrock-commands-config) and stubs (bedrock-commands-stubs) let us commit our own block scaffolding conventions into the repo and lint them in CI — a governance decision, not just a DX one.
• Dependency policy: v1.0.0 is the first tagged release. Decide now whether we pin exact versions and treat the command surface as an internal API we depend on.

When to Consider This Package

Adopt when:

• We are already using a Bedrock-style block/set system (blocks.yaml, article.yaml, fieldsets, views) inside a Laravel app with Artisan available.
• The block library is actively iterated — multiple sets added, renamed, or retired per quarter.
• More than one developer touches content modeling, so consistency across fieldset/view scaffolding matters.
• We want our own conventions enforced via published stubs/config rather than per-developer habits.

Look elsewhere / don't adopt when:

• We are not on Bedrock-style YAML block config (native Gutenberg, ACF, Nova, custom page builders) — the commands are inert.
• The content model is essentially frozen or tiny (a handful of blocks, single maintainer); the added dependency outweighs the savings.
• Non-developers need to create or rename sets — this is a CLI-only workflow with no GUI or preview step.
• Deletion semantics (removing a set from all entries) conflict with data-retention, audit, or compliance requirements.
• We need a guaranteed-stable command API with a long deprecation policy; v1.0.0 is new and the surface is still settling.

How to Pitch It (Stakeholders)

To executives: Changing our page-building options today means editing several config files, templates, and every stored content entry by hand — slow and easy to get wrong. This package turns adding, renaming, and retiring a block into a single, auditable command, so we can ship page-builder improvements faster with materially less risk of broken pages. Cost is one small, pinnable dependency.

To engineering: Four Artisan commands covering the full lifecycle — make:, rename:, delete: for blocks and sets — plus publishable config and stubs so we can bake in our own conventions and check them in CI. The rename/delete commands mutate stored entries, so treat them as production-affecting operations: run on staging first, back up, and gate who can execute them. It's a v1.0.0, so pin the version and trial it on one real block change before rolling it into the standard workflow.