Runs on Laravel 11
The constraint is ^11.0|^12.0|^13.0 and CI tests all three. Laravel 11 is
past security support, so every published 11.x carries advisories that will
never be fixed and recent Composer refuses to resolve them by default. If your
composer require is blocked, the README says why and what to set — the block
comes from your framework, not from this package, and it applies to every
package you install.
It asks again when the shape of an answer contradicts the question
"Which carrier shipped the most orders" has one answer. Models routinely write
it without the LIMIT, so the top row is right and every row under it is wrong.
Nothing about that is visible before execution, which is why the SQL verifier
cannot catch it — the SQL is valid.
The row count is now inspected on your own server and, when a question that
asks for one thing came back as a list, the query is regenerated once. The retry
prompt carries the question, the schema and one sentence about the shape. No
value, no row, no count.
Semantic dataset matching, off by default
An optional stage between keyword routing and the model: an embedding service
you run is asked which dataset a question is closest to, and a confident answer
skips the model call that would otherwise be spent just placing it.
No model or container ships with this — the client is about 10 KB and adds
no dependency. Exact routing always wins, and a miss, a timeout or an outage
leaves the question on exactly the route it takes today. It can add a route,
never remove one. See semantic_matching in the config.
php artisan jeeves:semantic-corpus writes the descriptions such a service
ranks against, generated from your own schema files — orders and tickets in one
application, patients and claims in another. Nothing about the matching is
specific to any domain, and no corpus is bundled, because a shipped one would
describe nobody's data. It writes names, descriptions and the aliases your users
type, and never opens a database connection.
Fixed
- The security event raised for rejected SQL carried an empty question, so the
one record of an unsafe generation did not say what had been asked. - Feedback corrections are screened again where they are replayed into a prompt,
not only where they are submitted — rows written before that check existed
were reaching prompts unscreened.
Where it is still weak
Measured, not estimated, and unchanged by this release:
| Benchmark | Score |
|---|---|
| Spider dev sample | 30-31/36 (83-86%) |
| This package's own set | 35/46 (76%) |
By join width on that second set:
| Join width | Correct |
|---|---|
| 1 table | 16-17/20 |
| 2 tables | 13/16 |
| 3 tables | 2/6 |
| 4 tables | 3-4/4 |
Three-table joins are the honest weak spot, and they fail consistently rather
than occasionally. It is not a missing-information problem — the prompt carries
the full join path, table by table, and the model still writes the wrong query.
Curating schema descriptions does not fix it either. If your questions are
mostly three-table shapes, measure before you commit:
php artisan jeeves:benchmark runs against your own schema and your own
reference SQL.
Provider conformance, 17 checks per model: Gemini 2.5 Flash, Claude Sonnet 5,
DeepSeek v4 Flash, Mistral Large and the open-weights gpt-oss-20b all scored
17/17. Muse Glimmer 30B and Nemotron 3 Super 120B scored 15/17. A 20B model
passing everything, including multi-step decomposition, is the result worth
knowing: the conversation features are resolved in PHP rather than asked of the
model, which is why they hold up on small local models.
Upgrading from 1.0.0
No breaking changes and no migrations. Semantic matching is off unless you
enable it, so an install that changes nothing behaves exactly as before.
If you published the config before upgrading, note that Laravel's
mergeConfigFrom is one level deep — php artisan jeeves:doctor reports any
setting this version ships that your published config does not have.
composer require jayanta/jeeves:^1.1