Framework Laravel Package

Product Decisions This Supports

• Adopt vs. build: v1.2.0 modularizes the framework into sala/console and @salasolucoes/mcp, so teams can pilot MCP/agent tooling or CLI automation without adopting the entire framework. This supports a phased build-vs-buy decision: use the extracted packages for narrow needs, adopt sala/framework only where a curated Laravel baseline is valuable.
• Roadmap for AI-assisted workflows: The standalone MCP package and universal findProjectRoot() / SALA_PROJECT_ROOT support make it easier to standardize how tools locate project roots in monorepos, CI, and local environments — a prerequisite for reliable developer-agent integrations.
• Platform standardization: composer create-project sala/framework gives a single scaffolding path for Laravel/PHP services. The package rename from salaab/framework to sala/framework is a migration item, not a feature decision; budget composer/npm reference updates, CI cache invalidation, and onboarding-doc changes.
• Feature and docs prioritization: Moving ecosystem docs to docs/packages.md and using a “discreet” README link improves README focus but may reduce discoverability. Consider a docs task to ensure new adopters can find the package map, especially during the rename.
• Supply-chain and maintenance review: Consuming sala/console and @salasolucoes/mcp from registries instead of local file: paths is better for reproducibility, but adds two external dependencies and an npm package to the support surface. PM should confirm ownership, release cadence, and security-review expectations for both.

When to Consider This Package

• Consider it when you are standardizing multiple Laravel/PHP services and want a curated baseline that includes console tooling and MCP support.
• Consider it when you need MCP integration in a PHP/Laravel context and prefer adopting a maintained package over building custom glue.
• Consider it when modular adoption matters: you can evaluate sala/console or @salasolucoes/mcp independently before committing to sala/framework.
• Consider it when you can absorb a package rename and small-ecosystem churn through a normal dependency-upgrade process.
• Look elsewhere when you require long-term stable package names, enterprise support/SLA, broad community documentation, or strict semantic-versioning guarantees across a large dependency graph.
• Look elsewhere if adding an npm dependency to a PHP toolchain is unacceptable, or if you are not using MCP/custom console capabilities and would be paying migration cost for unused surface area.

How to Pitch It (Stakeholders)

• Executives: This release turns the framework into a more modular ecosystem: console and MCP capabilities are now independently consumable packages. That lowers the commitment for AI-assisted developer-tooling pilots and lets teams adopt incrementally. The main cost is a one-time migration from salaab/framework to sala/framework; no functional regression is indicated in the release notes.
• Engineering: v1.2.0 moves the repo to salasolucoes/framework, renames the Composer package to sala/framework, removes local file: dependencies, and consumes sala/console ^1.0 and @salasolucoes/mcp ^1.0.0 from registries. Update composer.json/package.json, CI scripts, and local bootstrap commands. Use SALA_PROJECT_ROOT or the universal findProjectRoot() where project-root resolution matters. Ecosystem docs now live in docs/packages.md.
• Product/ops: Treat the rename as a migration workstream: update onboarding docs, composer create-project instructions, and internal runbooks. Confirm that the extracted packages have clear ownership and release cadence before making them part of the standard platform.