zipavlin/redline
Redline is a lightweight Laravel/PHP package that helps you define and enforce boundaries in your application. With simple configuration and a clean API, it adds practical guard rails and limits without heavy dependencies, making it a good fit for small to mid-sized projects.
{redline.path}/api/mcp exposing eight tools to AI coding agents (Claude Code, Codex, Cursor, VS Code, Gemini CLI, etc.). The fit is still strongest for a session-authenticated Laravel monolith with a clear role model, but v0.3.0 introduces a second consumption model: machine clients authenticating with long-lived bearer tokens (rlm_ prefix) rather than cookies/CSRF. That broadens the addressable use case (agents triaging reports during development) while adding an outbound integration surface that must be governed by the host, not just installed.user_list exists but no assign tool — so member workflows remain dashboard-driven while triage and status changes can be agent-driven. report_get has a deliberate side effect: it leaves a new report untouched unless mark_noticed is passed, which is a useful "agent read doesn't imply human triage" distinction but one support and reporting must understand.REDLINE_DISABLED is replaced by opt-in REDLINE_FEATURES (e.g. screenshots,comments,mcp), and existing installs that do not set it will silently have every feature off. The MCP path additionally requires php artisan redline:enable mcp, php artisan redline:update to apply the new redline_tokens migration, and a token issued via php artisan redline:mcp. None of this is drop-in.--revoke=, --revoke-all). They are shown once and only accepted as Authorization: Bearer. This is a durable secret that will end up in developer laptops, agent config files, CI logs, and screen shares. A misspelled feature name now halts the application rather than being ignored, which converts a config typo into an outage if cached config is not cleared. Agent writes (report_create, comment_create, report_update_status) follow dashboard rules — sanitized HTML, role permissions, status transitions, new-report mail — which limits blast radius but does not eliminate spam, duplication, or unwanted status churn from an autonomous loop.route:cache/optimize from another environment can no longer expose Redline where the guard says it should be off; routes now survive route:cache; forbidden report submissions return 403 instead of a server error. The MCP server instructs agents to treat report content as data, not instructions, which is a correct and necessary mitigation for prompt injection via user-written reports — but it is a behavioral instruction to a third-party agent, not an enforced control, and should be treated as residual risk. Note the documented exception: with LaravelGuardProvider the API/MCP surface cannot 404 before the session stack runs, so it stays token-gated per request instead. Open items: no stated rate limiting on MCP, no audit trail described for token-authenticated reads/writes, no expiry/rotation policy, and no mention of how token issuance is authorized beyond CLI access to the host.developer/admin, and who can legitimately see email PII? Does that change now that agents can call user_list and read report content?--revoke-all part of the incident-response runbook, and is it fast enough given revocation is CLI-only and logout does not revoke?report_list, report_get, comment_list, user_list) until agent behavior is observed?{redline.path}/api/mcp as an authenticated API endpoint?REDLINE_DISABLED values been translated to REDLINE_FEATURES, and is there a pre-deploy check so a typo cannot hard-fail production?post-package-update migrations, or must upgrades run through a controlled redline:update runbook?has_media, and who owns the contract v2 migration plus the new mcp.md contract?User model resolvable by LaravelAuthProvider. The package still introduces a second persistence technology (SQLite) even when the host runs MySQL/Postgres, so persistent writable volume, backups, and monitoring remain prerequisites. The MCP server adds an inbound authenticated API surface that must sit behind the same domain/TLS/proxy posture as the rest of the app, with token auth handled as a distinct path from cookie/CSRF media auth.REDLINE_FEATURES explicitly for every intended capability, run migrations, and verify widget/dashboard injection. Seed users via redline:user. Only if MCP is in scope: redline:enable mcp, redline:update, then redline:mcp to create a token and generate per-agent setup instructions.REDLINE_DISABLED into REDLINE_FEATURES, validating every name against the supported list to avoid the new hard-fail; (4) run redline:update --dry-run, review pending migrations including redline_tokens (and confirm 0008 author-row removal already applied if coming from v0.1.x); (5) run redline:update with backup enabled; (6) re-publish assets and clear config/route/view caches; (7) update frontend/API clients to contract v2 semantics (has_media replaced by screenshot:exists/video:exists, 422 on email PII for non-developer/admin, no user_agent in payloads); (8) decide and execute MCP enablement separately.route:cache/optimize in each environment, and specifically validate the documented LaravelGuardProvider exception (API/MCP token-gated rather than 404). Confirm GET /bootstrap advertises only enabled features and that the widget/dashboard degrade cleanly when a feature is off. Test 403 on forbidden report submission. Re-validate media under cookie/CSRF, origin gating behind proxies, pending-user rejection, TipTap mention preservation, and GET /user exposure. For MCP: test each agent's connection, confirm element >512 chars is rejected over MCP but not in the widget, confirm mark_noticed behavior, and confirm password change invalidates tokens.redline:update --dry-run.GET /user, guard-inactive 404 under route cache.403 negative paths.redline:update.0008 author-row removal is not reversible by code rollback alone. Feature disablement is now the fastest lever: removing a capability from REDLINE_FEATURES (then clearing cached config) turns it off without a code rollback, and REDLINE_FEATURES set to nothing disables Redline's features entirely. MCP can be independently withdrawn by removing mcp from the feature list and running redline:mcp --revoke-all. Note that Laravel downgrade is not a realistic rollback, so the framework upgrade should be treated as one-way.REDLINE_FEATURES, and a typo now stops the app. Treat that variable as reviewed, version-controlled configuration with a pre-deploy validation step. redline:update remains a strong operational asset (idempotent, backup-aware, dry-run, asset re-publish, cache clear) and now applies the redline_tokens migration; the Composer post-package-update hook policy question carries over.Bearer header, wrong base path, feature not enabled, token not revoked-but-reissued), tokens lost because they are shown only once, and revocation requests with no UI. Logout not revoking tokens will surprise people. Agent-generated reports, comments, and status changes will produce duplicate or low-quality artifacts that humans must clean up, and report_create requires the agent to supply a valid CSS selector and viewport pin. Existing support topics persist: author-as-non-member, self-removal, claim auto-assignment, role-based email visibility, pending-account lockout, and media cookie/CSRF/domain failures. Privacy questions about GET /user and user_list are more likely now that an agent can enumerate users.report_list, report_get, and comment_list in loops — which is read-heavy but unthrottled as documented, and can add write bursts via report_create/comment_create. Validate read concurrency, consider rate limiting at the proxy, and monitor SQLite lock contention during agent sessions. Media storage growth, backup windows, and multi-node access remain unvalidated; horizontal scaling is still not demonstrated. Token-authenticated traffic also bypasses the session/cookie path that existing caching and observability may assume.REDLINE_FEATURES unset after upgrade leaving every feature silently off; misspelled feature name hard-failing the app with stale cached config; redline_tokens migration not applied before enabling MCP; MCP token leaked in agent config repos or logs and valid indefinitely; token not revoked on offboarding because the user's password never changed; --revoke-all unavailable or unknown during an incident; agent loop generating duplicate reports or spurious status transitions and mail; prompt injection via report content influencing agent behavior despite the data-not-instructions instruction; guard-inactive exposure via route:cache (now fixed, but LaravelGuardProvider remains token-gated rather than 404); Composer hook migration failure during deploy; SQLite lock, corruption, or disk-full; asset re-publish overwriting customizations; stale config/view/route caches; contract v2 mismatch between backend and clients; old JWT media URLs breaking; non-developer UI not handling email 422; origin gate blocking legitimate custom domains or proxies.mcp.md contract, SQLite operations, session/CSRF media auth, the upgrade runbook, and — new — the MCP tool surface, per-agent setup, and token lifecycle management. A TPM should assign an explicit owner for MCP credential governance (issuance, rotation, revocation, offboarding tie-in), schedule a staging rehearsal that includes the framework upgrade and at least one agent end-to-end, define read-only-vs-read-write scope by environment, and extend smoke tests to cover feature-flag correctness, guard 404 under route cache, MCP token auth and revocation, and agent write hygiene alongside auth, media, members, priorities, due dates, and email PII. Expect ramp-up to grow beyond the previous one-to-two sprints given the coupled Laravel upgrade and the new credential/agent operational model.How can I help you explore Laravel packages today?