Laravel & PHP — first-class

Why Laravel and PHP are hard

Laravel is productive precisely because it is magical — and that magic is exactly what defeats a naive indexer. A tree-sitter parse sees a method call; it has no idea that the method does not exist on the class in front of it, because Laravel resolves it somewhere else at runtime. The hard cases:

• Facades — Storage::disk(), DB::statement(), Log::Info() look like static calls but proxy to a service resolved out of the container at runtime. The “definition” an indexer wants to link to is not where the call is.
• Eloquent dynamic methods — whereDoesntHave(), withTrashed(), whenLoaded(), attach() are never declared on your model; they come from builder mixins, scopes, traits like SoftDeletes, and __call magic.
• The service container — dependencies are bound and resolved indirectly, so “what implements this?” is a runtime question a static parse cannot answer.
• Route and middleware indirection — a request flows through middleware closures and named routes that never appear as a direct call edge.
• Carbon — date handling is a fluent chain of methods like addDay(), diffInHours(), toDateTimeString(), copy() that live in a vendor library, not your code.

The result for every other tool: these symbols land in the “unresolved” bucket. The graph has dangling edges, retrieval misses the real target, and an AI agent ends up guessing about the framework on top of guessing about your code — exactly the blind spot ContextBrain exists to close.

What ContextBrain added for PHP

ContextBrain treats Laravel/PHP as a first-class ingestion target, not a generic fallback. Two pieces do the work:

• A PHP resolver suite — resolver passes plus sweep tooling built specifically for Laravel ingestion, so the parser understands PHP and the resolver can take symbols that a generic pass left dangling and bind them to their real target.
• Framework-signature (“framework-sig”) packs — curated signature sets that teach the resolver what Laravel and its ecosystem actually expose. The packs are versioned and regenerated against real framework releases (for example, a v13 pack built against Laravel 13.15) so the signatures track the framework rather than drifting.
• Vendor indexing — the framework and library code in vendor/ is indexed too, so a call into Carbon or Eloquent resolves to a real definition instead of a dead end.

The framework-sig packs are seeded from observed real-world unresolved symbols and classified by library. They already cover, among others: Eloquent (whereDoesntHave, withTrashed, whenLoaded, attach), the query builder (whereRaw, latest, insert), Carbon (addDay, diffInHours, toDateTimeString, copy, setTimeFromTimeString), facades and core (Storage::disk, DB::statement, Log::Info), schema and migrations (Schema::hasColumn, Blueprint's unsignedInteger), mail and notifications (replyTo, button), and popular packages such as spatie/laravel-activitylog (performedOn) and laravel-restify (restifyJson).

What it can answer about a Laravel codebase

With the resolver suite and framework-sig packs in place, the knowledge graph for a Laravel project actually connects. That means the same questions ContextBrain answers for any codebase finally work on PHP:

• “Where does this Eloquent scope or relationship resolve to?” — instead of a dangling edge into nowhere.
• “What calls this, and what breaks if I change it?” — call/import impact analysis that sees through facades and builder methods.
• “Show me the real flow through this Carbon date logic” — resolved to the vendor methods it actually uses.
• Grounded chat answers and context packs whose code chunks point at the right targets, so an agent reasons over a framework it actually understands.

The honest scope

Being specific cuts both ways. ContextBrain resolves a large and growing set of Laravel, Carbon, query-builder, schema, and popular-package symbols through the framework-sig packs and vendor indexing. But framework-signature coverage is a curated, evolving set, not total: the seed work deliberately leaves genuinely ambiguous names and project-domain verbs in the unresolved bucket rather than mis-binding them, and rare or bespoke runtime magic — heavily dynamic __call tricks, container bindings constructed at runtime, names that collide with PHP built-ins — can still need a new signature before they resolve cleanly. The packs are versioned and regenerated against real framework releases precisely so coverage keeps widening over time.

The claim, stated truthfully: ContextBrain is the first context-management platform that gives real context for Laravel and PHP too — not by pretending the magic does not exist, but by resolving it with a PHP-specific resolver suite, framework-signature packs, and vendor indexing. Other tools index PHP as plain text; this one understands the framework.

Where to go next

See how resolved symbols become a queryable graph in the knowledge graph, or what else feeds a project's understanding in context sources.