Laravel Video Demos Laravel Package

Technical Evaluation

This release materially improves the package as a TPM-leverageable demo-video pipeline: rehearsal catches broken AI plans before expensive recording, page inspection handles dynamic Laravel/Inertia/API-driven labels, and first-class separate-frontend support extends coverage from monolithic Laravel apps to Vue/React SPA products. From a TPM perspective, the package is evolving from “AI records a demo” into “repeatable demo-as-code with bounded cost and explicit failure semantics.”

• Architecture fit: Best fit is a Laravel app with seeded sample data and a stable demo environment. The new VIDEO_DEMO_FRONTEND_URL mode fits API-first Laravel backends with separate Vue/React frontends, which is a common product architecture. The signed-header sample-data routing avoids CORS changes, reducing integration friction. Rehearsal-on-a-copy-of-sample-DB is the right architectural trade-off: it protects production data, catches plan errors early, and keeps failures inside the repair budget.
• Integration feasibility: High for teams already comfortable with env-driven Laravel package configuration. Auth flexibility is the key unlock: session (including Sanctum cookie SPA), sanctum-token, jwt, and custom via VideoDemo::signInUsing(...) cover most real-world SSO/Passport/custom-session cases. The custom callback is the escape hatch that makes the package viable for enterprise auth without forking. Page checks for SPAs—server errors, 401/403 for the signed-in user, frontend sign-in redirects—are sensible pre-AI gates.
• Technical risk: AI nondeterminism remains the primary risk, but v0.18.0 reduces it with rehearsal and label-aware text-box targeting. Page looks introduce a small, capped AI cost (~1 cent each, max 3 per video by default), but also a data-handling review: headings, links, buttons, field labels, and DOM context are sent to an AI provider, with secrets hidden. The 4xx-fails-the-step behavior is good for plan repair but can amplify auth/CSRF problems—especially 419s—into repeated repair attempts. Videos on production/own data are not rehearsed, so TPMs should treat those as higher-risk and require human review. Sanctum token expiry (1 hour) and recorder token cleanup need operational awareness.
• Key questions: Which Laravel/PHP versions are supported? Which browser automation and AI providers are used, and what are the data residency/retention terms? How is the sample database copied and seeded—snapshot, migration, or fixture? What are the hard limits on video length, resolution, concurrency, and storage? How does the repair budget interact with rehearsal failures and AI planning costs? Are signed links and signed headers scoped, expiring, and audit-logged? Does page inspection redact all secrets, including CSRF tokens, cookies, and hidden inputs? What observability exists for failed rehearsals, page looks, and refused requests? Is there a CI-friendly CLI or only an interactive studio?

Integration Approach

• Stack fit: Strong fit for Laravel monoliths and Laravel-as-API + SPA frontends. The package now explicitly supports separate frontend origins, Vite-style /api proxies, session/cookie Sanctum SPA auth, bearer-token Sanctum, JWT, and custom SSO/Passport sign-in. Teams without a separate frontend see no behavior change, which keeps adoption incremental.
• Migration path: Start in staging or a dedicated demo environment with VIDEO_DEMO_REHEARSE=true and a seeded sample database. Prove one happy-path flow with session auth before enabling frontend mode. Then add VIDEO_DEMO_FRONTEND_URL, choose the correct VIDEO_DEMO_SIGN_IN mode, and validate that API requests from the frontend carry the signed header and land in the video’s sample database. Only then enable page looks for flows with translation keys, database-driven labels, or third-party frontend pages.
• Compatibility: The env-var surface is growing (VIDEO_DEMO_REHEARSE, VIDEO_DEMO_PAGE_LOOKS, VIDEO_DEMO_FRONTEND_URL, VIDEO_DEMO_SIGN_IN, VIDEO_DEMO_TOKEN_KEY), so config drift is a real risk. The custom sign-in callback is the compatibility valve for Passport, SSO, and bespoke session handling. Teams using Sanctum cookie SPA auth should verify CSRF/session behavior end-to-end, because 419 responses now fail steps and can burn repair budget. The label-based text-box fix is a low-risk correctness improvement but should be regression-tested on forms with repeated roles.
• Sequencing: (1) Enable studio only in non-production and seed sample data. (2) Run rehearsal-only plans to validate selectors, labels, and API calls without recording. (3) Add frontend URL and auth mode; verify signed-header routing and token lifecycle. (4) Turn on page looks selectively where static code cannot resolve labels. (5) Integrate video generation into release/launch checklists with human review before publishing. (6) Expand from one flagship flow to per-feature demos only after cost and failure rates are understood.

Operational Impact

• Maintenance: Expect ongoing ownership of demo scenarios, sample-data seeds, env configuration, and AI/browser dependencies. Frontend redesigns, copy changes, auth changes, and schema drift will break plans; rehearsal is the main early-warning system. The package’s growing configuration surface should be version-pinned and documented in a demo runbook.
• Support: Support burden shifts from manual video editing to debugging failed rehearsals, sign-in modes, signed-header routing, and 4xx step failures. The improved error messages—especially “the app refused a request” with method, path, status, and Laravel message—are useful but will generate tickets when auth/CSRF is misconfigured. A TPM should define who triages demo failures and what “good enough to publish” means.
• Scaling: Costs scale per video via AI planning/repair and page looks, plus compute for headless recording and storage for artifacts. The default cap of three page looks per video bounds the obvious AI cost, and rehearsal costs no AI, but repair loops and large sample databases can still add up. Concurrency limits, token cleanup, and per-video database copies need capacity planning. Start with a small number of high-value demos rather than company-wide self-service.
• Failure modes: AI mislabels fields (partially mitigated by rehearsal and the label fix); rehearsal consumes limits.max_repairs; CSRF/419, expired Sanctum tokens, frontend sign-in redirects, and 401/403 page checks can block recording; page inspection may expose sensitive UI text if redaction is incomplete; production-data videos bypass rehearsal and carry higher quality/security risk; custom sign-in callbacks can fail silently without good observability.
• Ramp-up: Low for a TPM to consume—generate demos for release notes, sales enablement, docs, and onboarding—but moderate for engineering to configure auth, sample data, and frontend routing. Plan a short enablement session covering env vars, sign-in modes, rehearsal interpretation, cost caps, and the human review step. The best TPM leverage is treating this as a repeatable “demo pipeline” with owned scenarios, budget, and publishing gates, not as an ad hoc video generator.