Performist Bundle Laravel Package

Product Decisions This Supports

• Multi-tenant and per-request configuration without schema churn. Custom attributes on context objects let you attach tenant ID, locale, feature-flag cohort, billing plan, or experiment bucket to the request context and read it anywhere in the stack — no new database columns, no config-file sprawl, no service-locator hacks.
• Build vs. buy for cross-cutting context plumbing. Teams routinely hand-roll a Context singleton early and regret it once they need scoping, serialization, or test isolation. This release moves that concern into a maintained dependency, so roadmap time goes to product surface rather than internal infrastructure.
• Feature-flag and experimentation rollout. Arbitrary attributes make it cheap to thread an experiment variant or entitlement set through the request lifecycle, which directly supports staged rollouts and A/B tests without touching domain models.
• Auditability and support tooling. Attaching correlation IDs, actor metadata, or request provenance to context gives support and observability teams a consistent place to read from — reducing the "which log line has the tenant?" class of tickets.
• Roadmap signal: the package is actively investing in extensibility rather than stability-only maintenance, which is a positive signal for a long-lived dependency choice.

When to Consider This Package

Consider adoption when:

• You have multiple contexts in play — web request, queue job, scheduled command, CLI — and need consistent, scoped state across all of them.
• You are already carrying several pieces of ambient request data (tenant, user, locale, flags) and are passing them explicitly through many layers, or reaching for globals.
• You expect tenant/plan/cohort variance to grow, so a fixed schema of context fields would require repeated migrations.
• Your team writes tests that need to swap or isolate context cleanly between cases.
• You want an escape hatch: custom attributes now mean you can model product-specific metadata without forking the package or waiting on upstream.

Look elsewhere if:

• Your needs are a single immutable value (one tenant ID) that a small middleware or container binding already handles — the dependency cost exceeds the benefit.
• You require strict typing and compile-time guarantees on every context field; free-form attribute bags trade type safety for flexibility, so pair this with documented attribute keys and validation or you will get silent typos.
• Your architecture avoids ambient/global state on principle (e.g. strict functional core with explicit dependency passing).
• The package's release cadence or maintainer responsiveness does not meet your dependency policy — verify before committing.

Adoption caveats for this release specifically: custom attributes are a convention, not an enforced contract. Without a naming standard and a single place that documents valid keys, teams will diverge. Treat the attribute namespace as an API you own: define it, validate it at the boundary, and review additions.

How to Pitch It (Stakeholders)

For executives: This dependency removes a recurring category of internal plumbing work — carrying tenant, user, and rollout state through the application. The v1.3.0 release adds the ability to attach custom attributes to that context, which means new product variations (new plans, new markets, new experiment cohorts) can ship as configuration rather than as schema migrations and bespoke code. That shortens time-to-market for segmented features and lowers the carrying cost of multi-tenancy. Risk is low and contained: it is an additive feature with no breaking changes, and it is scoped to request/context handling rather than core domain logic.

For engineering: Custom attributes on context objects let you stop threading ad-hoc parameters through controllers, jobs, and listeners. Attach what you need at the entry point — HTTP middleware, queue worker, console command — and read it downstream. Two conditions for success: (1) publish a short registry of approved attribute keys with types and owners, and validate on write, because the attribute bag is untyped by design; (2) confirm the context is correctly propagated into queued and scheduled work, since that is where ambient state most often leaks. Budget a short spike to prove propagation and test isolation before rolling it across services, then standardize on it and delete the hand-rolled alternatives so you do not end up maintaining both.

Recommendation: Adopt for teams with existing or anticipated multi-context state; pilot on one service, document the attribute registry, and review after the first segmented feature ships.