Brain Laravel Package

Product Decisions This Supports

• Greenlighting PII/credential-bearing workflows. The 4.1.4 #[Sensitive] work is the difference between "we can put this in a workflow that touches passwords, tokens, or customer data" and "we can't." Redaction now holds across the workflow lifecycle — skipped, cancelled, and earlier events, validation errors, nested workflows, and exception messages in failure events and brain:run. That closes the class of bug most likely to cause a reportable data exposure.
• Encryption-at-rest for queued work. Sensitive values are now encrypted with APP_KEY at queue time. This is a compliance answer, not just a feature: queued payloads in Redis/SQS/database no longer carry plaintext secrets.
• Build vs. buy for orchestration. The case for buying/adopting strengthens: first-class redaction, queued actions (#[OnQueue]), nested workflows, run history, and a CLI (brain:run, brain:show, brain:migrate) is a meaningful head start on a bespoke state machine, and the parts you'd hand-roll worst (secret handling, audit output) are the parts now hardened.
• Roadmap sequencing. This unlocks positioning workflows for regulated or enterprise-adjacent customers — but only after we ship an operational story for APP_KEY rotation (see below). Treat key-rotation guidance as a release dependency, not documentation debt.
• Upgrade as a scheduled work item, not a drive-by. No breaking API changes and jobs queued before this release still run, including SensitiveValue payloads queued pre-encryption. But the APP_KEY dependency makes this operationally significant: rotating keys before draining queued jobs will strand payloads. That is a deployment-runbook change and a support-readiness item.
• Regression scope to fund. Two behavior changes deserve QA attention: rules() now validates real values (previously redacted ones), and exception messages in failure events are now redacted. Anything downstream that parsed failure-event text or relied on validating masked input needs a pass. Also confirm APP_KEY/APP_PREVIOUS_KEYS handling in every environment, including ephemeral CI and preview environments that regenerate keys.
• Vendor-risk signal for the buy side. 100% coverage enforced, cyclomatic complexity capped at 10, CRAP capped at 30, plus internal refactors (printer/Workflow/Process split) and Laravel 13.34 / Testbench 11.5 compatibility. This is the profile of a maintained dependency rather than an abandoned one — useful evidence when justifying adoption over an internal build.

When to Consider This Package

Consider it when:

• You're on Laravel and modeling multi-step business processes (approvals, onboarding, fulfillment, provisioning) where steps are actions/events and some steps carry secrets.
• Steps are long-running or need to be queued, and you can't accept plaintext secrets sitting in a queue backend.
• You need an audit trail of runs and a way for operators to execute/inspect workflows from the CLI — brain:run with hidden-input prompts and masked previews means support staff can trigger workflows without seeing or leaking secrets.
• You want redaction declared at the domain level (#[Sensitive], inherited from parent classes, dot notation like user.password) rather than sprinkled through logging code by hand.
• You have, or will build, a disciplined deploy process that includes key-rotation procedure (APP_PREVIOUS_KEYS) and a drain-queues-before-rotation step.

Look elsewhere when:

• You aren't on Laravel, or you need cross-language orchestration and durable execution as a platform concern (Temporal-style). Don't adopt a PHP workflow engine to solve a polyglot problem.
• You need a vendor with a commercial SLA, indemnity, and named support — a community package with strong internal quality gates is still not a contract.
• You need BPMN-standard modeling or a visual designer for non-technical authors. This is a code-first, developer-facing tool.
• You require per-tenant or per-customer encryption keys. Secrets here are bound to a single application APP_KEY; multi-tenant key isolation would need to be built around it.
• Your org can't commit to applying security-driven patch releases promptly. The value of this release evaporates if you pin and forget — the previous versions have known redaction leaks.

How to Pitch It (Stakeholders)

For executives: Release 4.1.4 closes a set of redaction gaps in how the workflow engine handles sensitive values. Sensitive data is now encrypted with the application key before it enters a queue, and it stays masked across the full workflow — including steps that were skipped or cancelled, nested workflows, validation errors, failure events, and CLI output. In plain terms: the two highest-risk leak paths for this class of software — secrets sitting in a queue, and secrets surfacing in error output an engineer reads at 2am — are now addressed.

What we're asking for: (1) schedule the upgrade — it's non-breaking and in-flight jobs keep working; (2) update the deployment runbook so APP_KEY rotation retains the old key in APP_PREVIOUS_KEYS until queued jobs drain; (3) fund one regression pass on validation behavior (rules() now sees real values) and on any alerting or log parsing that touches failure-event messages.

For engineering: Treat this as a security release with an operational tail rather than a routine patch bump. The encryption-at-rest behavior is a durable improvement, but it converts APP_KEY into a runtime dependency for in-flight work — that coupling belongs in your rotation and disaster-recovery docs, not just the changelog. The maintainer is also enforcing 100% coverage, capped complexity, and CRAP thresholds, so expect the codebase to stay readable and the upgrade surface to stay predictable; that's a reason to keep this dependency current rather than fork it.