Laravel Mutable Content Tasks Laravel Package

Product Decisions This Supports

• Lifecycle modeling for time tracking. v0.2.0 introduces an explicit open/closed status on points (Point::FIELD_STATUS, point_status LOV), with new points defaulting to open and status-less points treated as open. This lets product define clear timer semantics — a point is either actively tracking time or stopped — and supports status-based UX (active timers, completed entries, dashboards).
• Feature and UX decisions around start/stop/reopen flows. Points::of($point)->close() stops the running time and closes the point; reopen() reverses it; both emit domain events (PointClosed, PointReopened). PMs can use these to justify scope around pause/resume, corrections, and "reopen a mistakenly closed entry" flows.
• Reporting and filtering. Scopes whereOpen() / whereClosed() plus isClosed() enable product surfaces like "currently running timers," "completed time entries," and open-vs-closed counts without custom query work.
• Build vs. buy. The package now provides the domain layer (status, transitions, events, query scopes) for a time-tracking primitive. That favors buy/adopt for teams that would otherwise hand-roll open/closed state, transition guards, and event hooks.
• Integration and roadmap leverage. PointClosed / PointReopened events are natural hooks for downstream features (notifications, billing triggers, activity feeds, audit trails), reducing the need to couple those features to the core model.
• Risk planning. The "Changed" note that starting time on a closed point now throws DomainException shows the API is hardening around valid state transitions. At v0.2.0, expect further minor-version behavior changes before a stable line; budget maintenance/upgrade time accordingly.

When to Consider This Package

Consider adoption when:

• You are building on Laravel/PHP and need a small, focused time-tracking primitive where points can be started, stopped, closed, and reopened.
• Your product benefits from event-driven integration (close/reopen hooks) rather than polling or bespoke state code.
• You want status-based querying (open/closed) and consistent transition rules (guarded by DomainException) without designing that domain model yourself.
• You are comfortable adopting a pre-1.0 package and can absorb occasional behavior changes on minor releases.

Look elsewhere when:

• You need multi-tenant billing, approvals, timezone/payroll rules, invoicing, or rich reporting — this package appears to cover the core state transitions, not a full time-and-billing suite.
• The "point" abstraction does not map to your domain (e.g., tickets, subtasks, projects) and you would need heavy wrapping or mapping.
• You require stable API/semver guarantees (1.x+) or long-term support commitments.
• You are not on Laravel, or you need an out-of-the-box UI/admin layer rather than a domain package.
• You need concurrency handling for multiple simultaneous timers/users — verify this explicitly before committing; the notes do not describe it.

How to Pitch It (Stakeholders)

For executives: This package gives us a ready-made, event-driven time-tracking core — points that can be opened, closed, and reopened, with proper state guards and query scopes — so we can ship stop/start timer features and status reporting faster and with less custom code. It is early-stage (v0.2.0), so the main trade-off is modest maintenance for upgrades; the integration surface is small and the event hooks keep future features decoupled.

For engineering: v0.2.0 adds an open/closed lifecycle with a status LOV, isClosed(), whereOpen()/whereClosed() scopes, close()/reopen() actions on Points, and PointClosed/PointReopened domain events. Invalid transitions (starting time on a closed point) now raise DomainException, so state rules are enforced at the domain layer. It is straightforward to integrate, testable via events, and a good fit if we want the domain model handled for us — with the expectation of some API churn pre-1.0.