Prezet Laravel Package

Technical Evaluation

Baseline context: No prior assessment exists, so v1.4.0 is the first data point in this record. The package is prezet/prezet, a Laravel markdown-content package (file-based markdown with front matter, indexed into the database and served through Eloquent models and Blade/markdown rendering, plus sitemap generation). The assessment below is written as a TPM evaluation of adopting it, using v1.4.0 as the entry point.

Architecture fit

• Prezet sits in the "content site in a Laravel app" niche: markdown files in the repo as the authoring surface, a database index for querying/listing, and Laravel routing/views for presentation. This is a good fit if we want content versioned alongside code and reviewed via PR, and a poor fit if non-technical editors need a WYSIWYG workflow.
• It is additive rather than invasive: config publishing, migrations, a console command for indexing, and route/view conventions. Low coupling to our domain code.
• The dual source of truth (files on disk + rows in the database) is the central architectural characteristic to design around. The files are canonical; the index is derived and must be rebuilt on deploy.

Integration feasibility

• Composer-installable, standard Laravel package conventions, no external services implied. Integration effort is dominated by process work (index step in the pipeline, route/theme decision), not code.
• v1.4.0's feat: add Laravel 13 support (#220) is the most consequential line for us: it tells us the maintainer tracks framework majors promptly, which reduces the risk of being pinned to an EOL Laravel version.
• The "boost skill" (#223) is an AI-agent guidance artifact (Laravel Boost-style skill/guidelines). It does not affect runtime; it lowers ramp-up cost for teams using AI-assisted development and is a soft signal of modern maintainer practice.

Technical risk

• Low, but non-zero, per semver. v1.4.0 is a minor release with no declared breaking changes or deprecations. The changelog is dominated by dependency updates, docs/sitemap changes, and two narrowly scoped fixes.
• fix implicit conversion from float (#209) is the only behavioural item. Type-coercion fixes can subtly change rendered output or validation paths; we should confirm whether any of our content or front matter carries numeric values.
• update sitemap (#221) and update dependencies (#222) both touch generated output or the dependency tree. The dependency bump deserves a lockfile diff review and a supply-chain sanity check, not blind trust in a patch release.
• Two first-time contributors (#220, #209) merged within one release: healthy for bus factor, but it raises a question about review depth on the release, particularly on the Laravel 13 support commit.

Key questions

1. Does v1.4.0's Composer constraint still support our current Laravel version, or does adding Laravel 13 come with an implicit floor raise?
2. Is the float-conversion fix observable in rendered markdown, sitemap XML, or front-matter parsing?
3. What exactly changed in the dependency update (#222), and does it move any transitive constraint we care about?
4. Is prezet:index idempotent and safe to run on every deploy, including concurrent deploys?
5. What is the maintainer's release cadence and historical time-to-support for new Laravel majors?

Integration Approach

Stack fit

• Target: an existing Laravel application that needs a blog, docs, changelog, or knowledge base. Excellent fit for a monolith where content lives in the same repo as the app and ships through the same CI.
• Poor fit for multi-tenant editorial platforms, content needing per-field access control, or teams without PHP developers authoring content.

Migration path

• Greenfield: composer require, publish config and migrations, create the content directory, add an index step to deploy, wire routes and views. Expect a few days of engineering for a themed, styled result.
• Brownfield: if we are replacing an existing CMS or a hand-rolled markdown route, migrate content in batches, keep the old route alive behind a flag, and diff rendered output page-by-page before cutover. Preserve URLs or add redirects, especially if the sitemap change in #221 alters URL formatting.

Compatibility

• Pin to a specific minor (^1.4) rather than floating. Record the Laravel version matrix in the dependency policy.
• Verify PHP version support and DB driver expectations (the index step typically writes to the app's default connection — confirm it does not require a separate database).
• Because Laravel 13 support landed here, any future upgrade of the host app to Laravel 13 should be gated on this package version or later.

Sequencing

1. Lockfile diff and dependency review of #222; read the #209 and #220 diffs directly.
2. Spike install in a throwaway branch; run prezet:index twice to confirm idempotency.
3. Confirm Composer constraint compatibility with our current framework version.
4. Add indexing to the deploy pipeline with a post-deploy verification step (count of indexed documents vs files, or a smoke-test request).
5. Theme and route integration; URL/redirect mapping if replacing existing content.
6. Adopt the boost skill in the repo's contributor docs as an optional onboarding aid.

Operational Impact

Maintenance

• Low steady-state effort: content changes are PRs, code changes arrive as occasional minor releases. The real maintenance surface is the deploy-time index step and the theme layer, both of which we own.
• Budget a recurring review cycle for dependency PRs; this release shows dependencies move in the same train as features, so we cannot skip minors indefinitely.

Support

• Single-maintainer-plus-contributors project. Bus factor is the main support risk. Mitigation: our fork-and-patch capability is realistic because the package is small and does not reach into exotic infrastructure.
• No commercial support implied; internal ownership must be named explicitly.

Scaling

• Content is effectively static and cache-friendly. Put a CDN or response cache in front of rendered pages and the database index stops being a hot path.
• The index command's runtime scales with the number of markdown files. At hundreds of documents this is a non-issue; at tens of thousands, measure before assuming.
• Search and listing queries are database-backed; if full-text search is required at scale, plan for an external search service rather than scaling the index table.

Failure modes

• Stale or empty index: deploy runs before content is present, or the index step is skipped. Symptom: 404s or missing listings in production with a green build. Mitigation: post-deploy assertion on document count and a smoke test on a known URL.
• Schema drift: a release adds a migration we did not run. Mitigation: make migrate --force order-of-operations explicit relative to indexing.
• Rendered-output regression: the #209 float fix changes formatting in edge cases. Mitigation: golden-file comparison of a sample of rendered pages in CI.
• Sitemap drift: the #221 sitemap change may alter emitted URLs. Mitigation: snapshot the sitemap and diff on upgrade; verify against Search Console after release.
• Concurrent deploy race: two deploy jobs indexing simultaneously. Mitigation: single-writer lock or index only from the primary release job.

Ramp-up

• A Laravel-comfortable engineer can be productive in a day: markdown plus front matter is a low-cognitive-load authoring model.
• Non-engineer authors need a documented front-matter schema and a content template; without that, front-matter drift becomes the most common source of broken pages.
• The boost skill (#223) is a genuine accelerator for AI-assisted contributors and should be linked from the onboarding doc, but it is not a substitute for the internal runbook covering the index step and rollback.
• Estimated onboarding: ~0.5 day for an author, ~1–2 days for an engineer owning deployment and theming.