Demo Kit Laravel Package

Technical Evaluation

Architecture fit. capell-app/demo-kit reads as a demonstration/starter kit for the Capell Laravel CMS ecosystem rather than a runtime library. That places it in the "reference implementation and evaluation harness" tier, not the "production dependency" tier. For a TPM the useful framing is: this package helps us answer questions about Capell cheaply, not ship features to customers.

Integration feasibility. Composer-installable and Laravel-shaped, so a throwaway spike is low-friction. Feasibility as a dependency inside a product codebase is currently undefined — the package is on a beta channel (v1.1.0-beta.51) and the release signal we have is empty.

Technical risk. The v1.1.0-beta.49 → beta.51 release notes contain only a compare link: no changelog, no migration notes, no backwards-compatibility statement, no security note. That is the dominant risk. It means we cannot distinguish a docs typo fix from a schema-breaking change without reading the diff ourselves. Secondary risks: 51 betas on a single minor version signals active churn; the supported Laravel/PHP version matrix is undocumented in what we have; no semver guarantee is expressed during the beta window.

Key questions.

1. Is demo-kit a scaffold (consumed once) or a dependency (consumed continuously)?
2. What are beta.50 and beta.51, specifically — breaking, additive, or cosmetic?
3. What Laravel and PHP versions are supported and tested?
4. What is the semver and deprecation policy while the package is pre-1.1.0-stable?
5. Who maintains it, and is there a security disclosure path?
6. Is there a stable-release date, or is beta the intended long-term channel?

Integration Approach

Stack fit. Laravel-native, Composer-managed, almost certainly service-provider plus migrations/seeders/config-publish. This is a comfortable fit for our existing Laravel tooling and CI shape; nothing exotic to learn.

Migration path. Do not merge into any product path. Stand up an isolated evaluation repository (or a clearly named branch with a guard in CI), pin the exact tag v1.1.0-beta.51, and commit composer.lock. Any future bump is a reviewed commit, never a floating constraint — ^1.1@beta is not acceptable here.

Compatibility. Unverified. Before anything is scheduled, run the package against our actual Laravel and PHP versions and record the result. Until that matrix exists, treat compatibility as unknown rather than assumed-good.

Sequencing.

1. Read the beta.49→beta.51 diff directly on GitHub — this is the only way to recover the missing changelog.
2. Spike install in a disposable environment; capture artisan about, published config, migrations, and routes so we have a baseline fingerprint.
3. Run the compatibility check against our target Laravel/PHP.
4. Decision gate: adopt as internal reference material only, or park.
5. Re-evaluate at the first non-beta release that ships an actual changelog.

Do not place this on a delivery roadmap that has external commitments attached.

Operational Impact

Maintenance. Because releases carry no human-readable notes, every version bump costs a manual diff review. Budget roughly one to two hours per bump during evaluation, and treat that as a permanent tax while the package stays in beta.

Support. No evident commercial support, SLA, or versioned documentation from what we can see. Expect GitHub issues as the only escalation path. That is acceptable for an evaluation artifact and unacceptable for anything customer-facing.

Scaling. Not assessable and largely not applicable. A demo kit's performance characteristics say nothing about production throughput; do not let a smooth local demo be read as a capacity signal.

Failure modes. (a) Silent breaking change on a routine bump; (b) package abandonment mid-beta; (c) incompatibility discovered only at our next Laravel upgrade; (d) a security issue fixed in a beta we cannot identify from release notes; (e) an engineer quietly promoting the spike into a real service because it was easy to install.

Ramp-up. Low for Laravel developers — hours, not days. Low for the TPM: the ongoing cost is diff-reading discipline, not domain learning. The real organisational risk is not skill, it is scope creep, which is best mitigated by naming the evaluation repo explicitly and time-boxing it.

Recommendation. Hold at evaluation tier. The absence of changelog content in this release is itself the finding: it confirms the package cannot yet be managed through normal dependency hygiene. Revisit when a stable release lands with release notes we can read.