Framework Laravel Package

Technical Evaluation

Architecture fit The package is a Laravel/PHP framework distributed via Composer, now with an npm-distributed companion (@salasolucoes/mcp) that implies a Model Context Protocol server for developer/AI tooling integration. The v1.2.0 change extracts sala/console and @salasolucoes/mcp out of the monorepo and consumes both from registries instead of local file:../mcp and mcp/sala paths. Architecturally this is the right direction: it replaces path-based coupling with versioned contracts and gives each artifact an independent release cadence. The cost is that the framework now has two external runtime-adjacent dependencies rather than zero.

Integration feasibility Entry point is composer create-project sala/framework. Feasibility is gated almost entirely on the rename being resolvable for existing consumers. The release notes rename the Composer package (salaab/framework → sala/framework) and the repository (abraaosala/tchiowa → salasolucoes/framework), but say nothing about a migration affordance: no mention of a replace declaration, a metapackage, a Packagist abandonment flag, or a redirect package. GitHub redirects renamed repositories; Composer and Packagist do not redirect renamed packages. Any downstream composer.json pinned to salaab/framework or abraaosala/tchiowa will fail to resolve after this release, not degrade gracefully.

Technical risk

1. Semver violation. A vendor/package rename is a breaking change, yet it ships as v1.2.0. Consumers on ^1.0 either never see it or, if they force-update, get an unresolvable dependency name.
2. PHP namespace ambiguity. The notes rename composer.json/package.json identifiers only. If the PSR-4 namespace also moved (Salaab\ → Sala\), every use statement and published config reference in downstream code breaks; if it did not move, the rename is cosmetic and the two names will coexist confusingly. This is the single largest unknown.
3. Namespace collision / squatting. sala/framework and sala/console are extremely generic vendor names on Packagist. Ownership of the sala vendor and the @salasolucoes npm scope is unverified, and generic names raise a real typosquat/supply-chain exposure.
4. Project-root heuristic. Universal findProjectRoot() plus a SALA_PROJECT_ROOT override, mirroring bin/console, is a filesystem-walking heuristic in two places. Duplicate implementations drift, and monorepos, nested projects, vendor/ trees, CI checkouts, and container mounts are the classic failure cases for exactly this pattern.
5. Contributor dev-loop regression. Removing the local file: links means cross-package changes now require publishing or manual path repository linkage — a real friction increase for anyone working on console/MCP and framework together.
6. Docs fragility. Moving the ecosystem map to docs/packages.md under .gitignore: /docs/* + !/docs/packages.md means every future doc requires a .gitignore edit or it is silently untracked. The README is deliberately no longer authoritative.

Key questions

• What is the Packagist story for salaab/framework and abraaosala/tchiowa — deprecation notice, replace, metapackage, or nothing?
• Did the PHP namespace change, or only the Composer package name? Same question for service provider and config publish tags.
• Is the sala vendor namespace and @salasolucoes npm scope under the team's control today, and are they defensively registered?
• What is the supported PHP/Laravel version matrix for v1.2.0, and is it CI-enforced?
• Was the minor version bump intentional, or is this logically a 2.0.0?
• Is @salasolucoes/mcp optional for runtime, or required by the framework?

Confidence: low-to-moderate. This assessment is derived solely from the v1.2.0 release notes; no dependency inventory, CI configuration, Packagist metadata, or prior assessment was supplied. Several risks above are "unverified" rather than "confirmed absent."

Integration Approach

Stack fit PHP 8.x / Laravel on Composer is the primary surface; Node/npm enters the picture only through @salasolucoes/mcp. Teams that currently run a PHP-only CI pipeline acquire a second toolchain. Before committing, confirm whether MCP is a developer-tooling convenience or a runtime requirement — that single answer determines whether Node belongs in production images.

Migration path Treat this as a rename-plus-extraction migration, not a patch upgrade. A practical sequence per consuming application:

1. Snapshot the current composer.lock and the resolved salaab/framework version.
2. Diff the published config/asset tags and the artisan command list produced by sala/console against what the app currently references.
3. Rewrite composer.json requires and any package.json references to the new names.
4. Only then resolve and re-lock.
5. Validate composer create-project sala/framework in a scratch app as the reference baseline.

If a replace-style shim is published later, steps 3–4 collapse into a single advisory bump. Without one, every consumer performs a manual edit.

Compatibility

• Git remotes: safe — GitHub redirects the renamed repo.
• Composer package names: unsafe — no redirect, hard failure.
• npm: unsafe — moving from an unscoped local path to a scoped registry package changes the install contract.
• PHP namespace / publish tags / command signatures: unknown; treat as unsafe until confirmed.
• Laravel/PHP version constraints: not stated in the notes; cannot be assessed.

Sequencing

1. Verify registry availability and namespace ownership before anything else — this is a blocker, not a task.
2. Stand up a scratch Laravel app via composer create-project sala/framework; diff its public surface against the last salaab/framework release.
3. Pilot on one non-critical service, with SALA_PROJECT_ROOT pinned explicitly to remove heuristic variability.
4. Publish the migration note and update the old package's README with a pointer forward.
5. Roll out to remaining services; retire all references to the old names in internal docs and templates.
6. Defer the docs relocation (docs/packages.md) until the .gitignore exception pattern is proven — it is a discoverability change with no functional upside during the migration window.

Operational Impact

Maintenance Release surface grows from one artifact to three (sala/framework, sala/console ^1.0, @salasolucoes/mcp ^1.0.0) that must be kept in lockstep. The caret constraints are loose, which invites silent drift: framework can pull a console minor that changes CLI behavior with no framework release. Publish an explicit compatibility matrix and consider tightening to a tested range. Docs maintenance also gets harder — the ecosystem map is now outside the README, so it will be read less and stale faster.

Support Expect an immediate volume of "package not found" and "class not found" reports keyed to the rename. Mitigate with a single migration FAQ, a prominent deprecation banner on the old README, and error text that names the new package. Support triage now spans three repositories; designate one issue tracker as the entry point or reports will fragment.

Scaling Registry-based consumption scales better than file: paths — no assumptions about sibling directory layout, which is what previously constrained CI and containerized builds. The MCP server introduces a per-developer and per-CI process; confirm its idle resource profile and whether it can be skipped entirely in build pipelines.

Failure modes

• composer require salaab/framework fails post-rename with an opaque resolver error.
• findProjectRoot() misidentifies the root in a monorepo or CI checkout; MCP silently reads the wrong tree rather than failing loudly.
• SALA_PROJECT_ROOT unset in a container triggers a fallback filesystem scan that is slow or wrong.
• The two root-resolution implementations (framework and bin/console) diverge, producing inconsistent behavior across tooling.
• npm scope unavailable or unowned blocks install for the whole framework.
• A new doc file lands in docs/ and is silently dropped by the ignore rule.
• A typosquatted sala/* package is installed by a mistyped requirement.

Each of these is cheap to detect with a smoke test and expensive to diagnose from a user report — add root-resolution and install-path assertions to CI.

Ramp-up Low for the Laravel surface: composer create-project sala/framework is a familiar motion for any Laravel developer. Medium for MCP: onboarding docs must cover SALA_PROJECT_ROOT, the precedence order against findProjectRoot(), and per-editor integration. Budget roughly half a day per engineer for the first integration and near-zero thereafter, assuming the migration note is accurate. If the PHP namespace did change, multiply the first number.