Vibedebug Bundle Laravel Package

Product Decisions This Supports

First, a scoping correction that drives the decision: this is a Symfony bundle, not a Laravel package. It integrates with symfony/ai (Symfony's official AI component). If your product is on Laravel, this is not adoptable as-is — the realistic options are a port, an equivalent Laravel package, or an in-house implementation. Treat everything below as "informative precedent" rather than "candidate dependency" in that case.

Where it does inform decisions:

• The package's shape changed in 0.3.0 — and that's the real signal. It is no longer just "explain this exception." It now exposes Symfony Profiler data as AI tools (vibedebug_profiler_summary, vibedebug_profiler_export_collectors) that an agent can call with a profiler token, over either symfony/ai-agent (internal) or MCP (external agents / AI Mate). That reclassifies it from a novelty DX helper into a small context provider for agentic tooling — worth tracking as a pattern even if we never adopt this implementation.
• MCP as an integration contract. The fact that a ~17-star, single-maintainer bundle shipped an MCP surface within months is a data point about where dev-tool integrations are heading. If we ship any developer-facing product, the roadmap question "should our data be queryable by an agent, and over what protocol?" is now askable. This package is a cheap reference implementation of that answer.
• Build vs. buy vs. wrap. Still MIT, still tiny, still near-zero dependents. "Buy" means "vendor/fork." The build is now slightly larger than before — a wrapper over symfony/ai plus profiler/collector extraction, not just the exception path — but still days, not sprints, if we already have an error/profiling pipeline. Decision hinges on whether symfony/ai is a sanctioned dependency.
• Incident triage / on-call experience. The original use case (plain-language diagnosis of unfamiliar stack traces, for juniors and thin-runbook services) still holds and remains the highest-value framing. The profiler-tool addition extends it from "explain the error" toward "let an agent go fetch surrounding request state" — useful, but it is the part that most increases data-exposure risk.
• Local/dev-only tooling tier. Still a dev-dependency, never a runtime component. 0.3.0 does not change that; if anything, exposing profiler collector data makes the "never in production" line firmer.

When to Consider This Package

Consider it when:

• Your stack is Symfony 7.x+ and symfony/ai is already (or is about to be) a dependency — marginal cost is near zero.
• It is scoped to local development and staging only, never on a production request path, and profiler endpoints are not reachable from anything untrusted.
• You have an approved LLM provider and key management story for engineering tooling, and legal is comfortable with source excerpts, stack traces, and profiler collector payloads leaving your perimeter. 0.3.0 materially widens this surface — profiler collectors can carry DB queries, request parameters, config and environment values — so the review is bigger than it was at 0.2.x.
• You are specifically evaluating MCP as a tool-exposure pattern and want a working, readable reference rather than a spec.
• Your team tolerates pre-1.0 churn and single-maintainer risk — 0.3.0 is a minor bump on a 0.x line, so there is no compatibility promise; a fork is your maintenance plan.

Look elsewhere when:

• You are on Laravel or any non-Symfony framework — adapting this costs more than reimplementing the idea, and that was true before 0.3.0.
• Any part of the flow would touch production traffic, PII, or customer data without a review of what reaches the model provider — now explicitly including profiler exports, not just exceptions.
• You need vendor SLAs, security review artifacts, or an LTS guarantee — none exist here, and an MCP endpoint is an additional thing to threat-model.
• You want APM-grade triage. Note the relationship shifted slightly: 0.3.0 is less a Sentry/Datadog competitor and more a tool layer an agent can query. The overlap is still significant where incumbents already do AI-assisted triage with better context — but "our APM can answer an agent's question over MCP" is now the fairer comparison.
• Your org lacks a sanctioned AI provider relationship — procurement, not engineering, remains the blocker.

How to Pitch It (Stakeholders)

For executives (one paragraph): A small open-source Symfony add-on that gives an AI assistant visibility into runtime debugging context — originally just error explanations, now also request profile data an agent can request on demand. The goal is cutting the time engineers spend diagnosing unfamiliar failures. It is MIT-licensed, free, and contained because it runs only on developer machines — no production exposure and no vendor contract. Two caveats: maturity (17 GitHub stars, one maintainer, no downstream dependents, pre-1.0), and that the new profiler-export capability widens what data could leave our perimeter, so it needs a data-handling review before any pilot beyond a sandbox. Recommendation: timeboxed evaluation in a dev environment only, plus the data-handling review; no production commitment. If our product is on Laravel, this specific package is out of scope — but its MCP tooling pattern is worth copying into a thin internal equivalent.

For engineering leads: 0.3.0 turns the bundle from an exception explainer into a profiler-context tool server: two tools (profiler_summary, profiler_export_collectors) that take a profiler token and return collector data, callable by internal agents via symfony/ai-agent or external agents over MCP. Still a dev-dependency, not runtime. Three things to verify before we spend time: (1) we are on Symfony with symfony/ai available; (2) we have provider keys and a data-handling policy covering profiler payloads, not just stack traces; (3) if we expose MCP, that endpoint is loopback/dev-only and token-scoped. If any fails, the build is a bounded internal task — capture context from our existing error and profiler pipeline, expose it as a tool, render inline. Assume we own maintenance regardless of path given the dependency footprint, and assume the API moves again before 1.0.