Cachelet Query Laravel Package

Technical Evaluation

What shipped: v0.1.0 is the first public tag of Cachelet Query, distributed as a read-only split from the oxhq/cachelet monorepo. That is the entirety of the disclosed change surface — no feature list, no API documentation, no compatibility matrix, no changelog beyond the release title, and no stated stability guarantees.

Architecture fit (unknown, assumed Laravel-native): The naming and packaging convention implies a Composer-installable Laravel package intended to sit in the query/persistence layer (query result caching, cache-key derivation, invalidation). Because it originates inside a monorepo, the split artifact is likely a subtree split or splitsh output — meaning the package's service provider, config publishing, and facade surface are designed for a host application that also consumes sibling Cachelet packages. Two architectural risks follow directly from that: (a) the split may carry undeclared internal coupling to sibling packages that aren't published yet, and (b) the package may assume a monorepo-local directory layout or autoload configuration that doesn't survive the split cleanly. Neither can be verified from the release notes.

Integration feasibility: Low confidence at 0.1.0. Composer will install it, but "installs" and "integrates" are different claims. We cannot confirm Laravel version support (8/9/10/11/12), PHP constraint, whether a service provider is auto-discovered, whether config is publishable, or whether it depends on a cache driver contract beyond PSR-6/PSR-16.

Technical risk — material:

• Pre-1.0 semver. Anything may break at 0.2.0. There is no ^0.1 safety net worth relying on; Composer treats 0.x minors as breaking by convention.
• Read-only split = no local change control. Patches cannot be proposed in the published repo. Any fix we need must go upstream to the monorepo, on the maintainer's timeline, or we maintain a fork.
• Query-layer blast radius. Query caching touches correctness of application reads. A defect here produces stale or wrong data rather than an error — the most expensive failure class to detect.
• Unverifiable provenance. The split repo's CI status, test coverage, and release provenance (signed tags? GitHub Actions attestations?) are unknown.

Key questions for the maintainer (blocking before any adoption decision):

1. What exactly does Cachelet Query do — key generation, result caching, invalidation, or query-builder instrumentation?
2. Is the read-only split the canonical install target, and where is the canonical issue tracker?
3. Which Laravel and PHP versions are supported, and is there a CI matrix we can inspect?
4. Is the split generated deterministically per tag, and are tags signed/attested?
5. What is the documented invalidation contract (TTL, tag-based, model-event-driven)?
6. Are sibling monorepo packages required at runtime, and if so, are they published?
7. What is the intended path to 1.0, and is there a deprecation policy?

Integration Approach

Stack fit: Presumed greenfield-adjacent Laravel. Fit is plausible but unproven — no composer.json constraints, no Laravel package discovery confirmation, no evidence of Octane/Swoole or queue-worker safety. Treat fit as unvalidated rather than positive.

Migration path: There is nothing to migrate from, so the real question is containment, not migration. Sequence:

1. Spike, not adoption. Install 0.1.* in a disposable branch or throwaway app. Read the actual composer.json, src/, and service provider — the release notes are not a substitute for the artifact.
2. Pin exactly. Use an exact version constraint (0.1.0) or a committed composer.lock entry. Do not float within 0.x.
3. Fork-first contingency. Mirror the split repo into our namespace before writing any integration code, so an upstream stall or repo deletion doesn't strand us.
4. Isolate behind a seam. Wrap usage in an internal interface (e.g. a QueryCache contract we own) so replacement with Laravel's native Cache::remember or a first-party solution is a one-file change.
5. Promote only on evidence of a second release, a documented API, and visible CI.

Compatibility: Unknown across Laravel majors, PHP minors, and cache stores (Redis, Memcached, database, array). The cache-store dimension matters most for a query-caching package and is entirely undocumented. Also unverified: interaction with read/write connections, transactions, and multi-tenant cache-key scoping.

Sequencing: Gate progression on artifacts, not on version numbers. Define explicit exits: spike → pilot on one non-critical read path → broader rollout only after the maintainer answers the blocking questions and we've observed at least one subsequent release with a changelog.

Operational Impact

Maintenance: The read-only split arrangement shifts maintenance cost onto us in three ways. We cannot file PRs against the published repo; we cannot rely on its issue tracker; and release cadence is dictated by the monorepo, which we don't control and which may bundle unrelated changes. Budget for a periodic "is the split still in sync with the monorepo?" check — split repos are a well-known source of drift when the generation job silently fails.

Support: Effectively self-support at 0.1.0. There is no versioned documentation, no stated support window, no security disclosure policy, and no evidence of a maintainer response commitment. For a package in the query path, absence of a security contact is a genuine concern — a cache-poisoning or key-collision defect would have no coordinated disclosure route.

Scaling: Unassessable from the release notes. The questions that matter: does the package add per-query overhead (key hashing, serialization) on every read, or only on cache misses? Does it hold query bindings or results in process memory (relevant under Octane, where that memory persists across requests)? Does cache-key derivation stay O(1) with complex where clauses? None of this is documented. Assume unbounded overhead until measured.

Failure modes, ranked by expected cost:

1. Silent staleness — invalidation misses a write path; users see stale reads. Highest cost, lowest detectability. Mitigate with TTL ceilings and a correctness test on the critical read paths.
2. Key collisions — two distinct queries hash to the same key under a naive key strategy; wrong data returned. Mitigate by inspecting the key-derivation code before pilot.
3. Upstream abandonment — split stops being regenerated; the published package rots behind the monorepo. Mitigate with the fork contingency above.
4. Dependency conflict — a 0.x transitive pin blocks a Laravel or PHP upgrade elsewhere in the app. Mitigate by isolating the dependency to the fewest possible services.
5. Hard failure on cache-store swap — Redis in dev, database cache in prod, divergent behavior. Mitigate by testing against the production cache driver specifically.

Ramp-up: Low effort to install, moderate effort to trust. Realistic estimate: half a day to spike and read the source, one to two days to wire a pilot behind an owned interface with a correctness test, and an ongoing low-single-digit-hours-per-month maintenance tax for split-sync checks and fork hygiene. Ramp-up cost is not the risk here — the risk is that the ramp-up produces a "looks fine" signal from a package with no documentation, no visible CI, and no support commitment, and that signal gets read as approval.

Recommendation: Do not adopt for production query paths at 0.1.0. Fund a time-boxed spike to answer the blocking questions, hold the artifact behind an internal interface, and revisit on the next release with a real changelog.