Sky Laravel Package

Technical Evaluation

Architecture fit. lara-zeus/sky is an additive Laravel package: it ships its own Eloquent models, migrations, config, published Blade views, Filament admin resources, and front-end routing for posts, pages, tags, and categories. It does not overlay an existing content model, which is the decision-relevant property — it is a build-vs-buy shortcut for a content surface, not a content platform. It fits cleanly where the team is already on Laravel + Filament and has no CMS today. It fits poorly where content is already load-bearing (existing CMS, bespoke schema, non-Filament stack), because adoption becomes a migration plus an architectural bet on Filament.

One metadata discrepancy must be closed before the fit is treated as settled: the package description describes a Spotlight-style command palette built on Livewire/Alpine/Tailwind, while the release notes and prior assessments describe a CMS with posts/pages/tags/categories. These are different products with different value propositions and different integration steps. A TPM closes this by reading the actual README, service provider, and migration set — not by trusting the summary — and records the answer in the spike ticket.

Integration feasibility. The v5.0.1 surface is small and legible: docs-structure cleanup (#264), three CI action bumps (checkout 5→6, fetch-metadata 2.5.0→3.1.0, composer-install 3→4), and one behavioral fix — content retrieval in posts and pages (#268). Installation is conventional: Composer with Laravel package auto-discovery, publishable config and migrations, and a Filament plugin registration step. Realistic path to a first end-to-end proof (author a page in the panel, render it at a public URL through our template) is a one-to-three-day spike — fundable as discovery, not as a roadmap commitment.

Technical risk.

• Patch risk: low. No API, schema, or config changes described; no migration work from 5.0.0.
• Major-version residual risk: moderate. A functional fix landing immediately after v5.0.0 is a credible signal the major shipped a content-retrieval regression, and the v5.0.0 breaking surface is not enumerated in what we have. That gap belongs in the spike's exit criteria, not in a post-commit surprise.
• Ecosystem coupling: moderate-to-high. Filament is a hard constraint. A Filament major mismatch is a stop, not a workaround, and it silently removes the admin UI.
• Governance risk: moderate. MIT, community-maintained, 213 stars, zero dependent packages. Zero dependents means no downstream validation of upgrades — we would be first to hit breakage.
• Scope risk: high if unmanaged. Sky is a content store plus a rendering helper. SEO/meta, sitemaps, scheduling, editorial workflow, revisions, media transformation pipelines, localization, and multi-tenant publishing are out of scope and must be separately planned backlog items.
• Content-safety risk: unquantified. Rendering authored content through published views raises escaping/XSS and sanitization questions the release notes do not address.

Key questions to resolve before commitment.

1. Which Laravel, PHP, and Filament majors does v5 require, and do those match our floor?
2. What exactly did v5.0.0 break — schema, config keys, published views, or panel plugin registration?
3. Is #268 a retrieval, escaping, or output-formatting change? Does it require cache clears or view republishing?
4. What test coverage exists for the posts/pages retrieval path that #268 touches?
5. Are we greenfield, on v4, or on 5.0.0 today? That single fact changes the estimate by an order of magnitude.
6. Who internally owns the front-end templates, routing, and SEO layer, and is that person staffed for the spike window?
7. Is there any support policy, release cadence commitment, or commercial tier behind Lara Zeus?
8. How is raw content escaped/sanitized on render, and does Sky delegate that to us?

Integration Approach

Stack fit gate (go/no-go, before the spike). Reconcile the package composer.json constraints against our pinned Laravel/PHP/Filament versions. Treat this as a checkpoint, not a task inside the spike. If Filament majors diverge, stop and re-evaluate against a plain Laravel content package or a headless CMS — off-Filament, the value proposition largely evaporates and the comparison set changes entirely.

Migration path.

• Greenfield: require ^5.0.1 explicitly. Do not permit ^5.0.0 as a floor; that admits the release containing the content bug.
• From v4: treat as a project, not a version bump. Walk the v5 upgrade guide, diff published migrations/config/views against what is in the repo, and assume post/page output may render differently after #268.
• From 5.0.0: mechanical patch plus a targeted regression check. Verify rendered posts and pages rather than trusting a green build; confirm whether #268 is retrieval- or output-level before deciding if view republishing is needed.

Compatibility. Two dependency axes matter: the Filament major (hard stop if mismatched) and Laravel/PHP floors. Because Sky publishes views and config into our repo, compatibility is not just Composer-resolved — it also includes our local view overrides surviving an upgrade. If the command-palette variant turns out to be the real product, add Livewire/Alpine/Tailwind to the compatibility check and re-scope the spike, since that is a UI-surface integration rather than a data-model one.

Sequencing.

1. Gate (0.5 day): resolve the description discrepancy, confirm version matrix, name the front-end owner.
2. Spike (1–3 days): install, publish config/migrations, register the Filament plugin, author one real post and one real page, render both through our templates at a public URL. Exit criteria: Posts/Pages appear in admin nav, both render correctly, content renders unescaped/escaped as intended, and a CI smoke test covering one post and one page is green.
3. Abstraction boundary (parallel): wrap content access in our own service/repository; keep view overrides shallow and documented. This is the reversibility insurance that makes the decision cheap to unwind.
4. Front-end build-out (sprint): templates, routing, SEO/meta, image handling, permissions — explicitly ours, explicitly estimated.
5. Deferred backlog (separate tickets): scheduling, revisions/approvals, media pipelines, localization, multi-tenancy. Naming these up front is what prevents the "we installed a CMS, why can't marketing schedule posts?" gap.

Rollout. Ship behind a feature flag on a low-traffic surface (changelog or internal announcements) before a marketing-facing one. That gives a real content-volume signal without executive visibility on the first release.

Operational Impact

Maintenance. The recurring cost is not the package; it is the surface we now own: templates, SEO/meta, image handling, permissions, and content backup/export. Published views and config drift on every upgrade unless overrides are shallow and documented from day one. Assign a named owner for that layer before adoption — an unowned front-end is the most common way a cheap integration becomes an expensive one.

Support. Community-maintained, MIT, no SLA, small contributor base. Sustained Dependabot activity (the substance of v5.0.1) is hygiene evidence, not capacity evidence. There is no commercial tier evident, so plan for "we fix or we fork" as the escalation path, and record that assumption in the risk register rather than discovering it during an incident.

Scaling. Content volume is not the constraint — SQL-backed models with standard caching scale with whatever we put in front of them. Constraints sit elsewhere: rendering performance is our responsibility (response caching, query tuning for tag/category listings), and there is no media transformation pipeline, so image resizing, CDN, and responsive variants are external work. Multi-tenant publishing or paywalled content is out of scope; if those appear on the roadmap, that is the signal to re-platform, not to extend Sky.

Failure modes and mitigations.

• Filament major mismatch on upgrade — admin UI disappears silently. Mitigate: CI job that boots the panel and asserts Posts/Pages routes resolve; pin the Filament major explicitly.
• Upgrade breaks published views or content retrieval (the #268 class of bug) — mitigate with the two-page render smoke test in CI, run on every dependency bump.
• Zero dependents means we are the canary — no external signal that an upgrade is safe. Mitigate by tracking latest on a schedule with the smoke test as the gate, not by delaying upgrades until the ecosystem catches up (it won't).
• Abandonment / bus factor — mitigate by keeping the repository boundary thin enough that replacing the content store is a contained piece of work, and by exporting content in a portable format on a schedule.
• XSS or unwanted HTML in authored content — resolve the sanitization question during the spike; if Sky delegates it to us, that becomes an explicit deliverable, not an assumption.
• Scope creep into editorial workflow — mitigate by publishing the out-of-scope list alongside the roadmap item.

Ramp-up. Low for any developer already fluent in Laravel and Filament: conventional install, auto-discovery, publishable migrations, and a small API surface. Budget the real ramp-up for the non-obvious work — Blade view overriding and Filament resource customization — and for whoever owns SEO and template design. Docs were restructured in v5.0.1, so quality is improving but should be verified against the source during the spike rather than assumed.

TPM bottom line. Approve a time-boxed spike, not adoption. Fund it with explicit exit criteria, require ^5.0.1, and make the abstraction boundary a deliverable of the spike rather than a follow-up. Commit to Sky as the content layer only if the gate and the smoke test both clear; otherwise the fallback — a plain Laravel content package or a headless CMS — remains live and cheap.