Product Auto Up Bundle Laravel Package

Product Decisions This Supports

• Feature: Automating the "product goes live" step — scheduled or event-triggered transitions of a product from draft/out-of-stock/hidden into a listed, purchasable state. This is the capability implied by product-auto-up-bundle (auto up-shelving / auto-publish), packaged as a pluggable bundle rather than a bespoke job.
• Roadmap: Useful as a building block for catalog-lifecycle automation (timed launches, restock-driven relisting, seasonal windows, flash-sale open/close) without committing roadmap capacity to writing another scheduler + state machine.
• Build vs buy: The honest comparison is "adopt a 0.0.1 bundle" vs "write ~a few hundred lines of queued job + state guard." At this version the package only wins if your codebase already sits in the Tourze/Symfony bundle ecosystem and the bundle's conventions match how you register modules. Otherwise internal code is cheaper to own and debug.
• Use cases: marketplaces or multi-seller catalogs with time-boxed listings; ops teams manually flipping product visibility on a calendar; inventory-driven relisting after replenishment.
• Decision it should not drive: do not let this package shape pricing, merchandising rules, or approval workflows. It is a plumbing concern, and at 0.0.1 it should be treated as an implementation detail, not a platform choice.

Caveat on evidence: the 0.0.1 release notes contain no changelog content beyond a link, and no README/API surface was supplied. The scope above is inferred from the package name and its position in the Tourze bundle family — treat it as a hypothesis to validate against the source before it enters a roadmap conversation.

When to Consider This Package

Consider it when:

• You are already running Tourze bundles / Symfony-style bundle auto-registration and want catalog state automation that drops in without new infrastructure.
• The requirement is narrow and mechanical: "flip visibility/listing state on a schedule or trigger," not full merchandising logic.
• You can absorb pre-1.0 churn: a 0.0.1 version number means the public API is not a contract yet, so pin the version and expect to re-read the source on upgrade.
• You have engineering capacity to read the code directly, because the published artifacts (empty changelog, no documented surface) do not yet substitute for that.

Look elsewhere when:

• You need a supported, documented dependency with a maintenance signal — version 0.0.1 with no release notes is an explicit "no stability promises" signal.
• Your requirements include audit trails, approval gates, multi-tenant isolation, or per-channel scheduling semantics. Those are product features, not bundle defaults, and a thin auto-up bundle will not carry them.
• You are on a plain Laravel stack with no intent to adopt the Tourze bundle conventions — the integration cost likely exceeds the value of the abstraction.
• The listing transition must be transactional with checkout/inventory. Coupling money-path state changes to an unversioned third-party bundle is a risk you do not need to take at this stage.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are evaluating a small open-source component that automates putting products live on a schedule, replacing manual merchandising steps. It is a low-cost, low-blast-radius piece of plumbing — not a platform commitment — and the current 0.0.1 release ships without release notes or documentation, so the recommendation is a time-boxed engineering spike with a pinned version rather than adoption. The upside if it fits is removing recurring manual ops work; the downside if it does not is a few days of evaluation, because the fallback is a modest in-house job we would have written anyway. It should not appear on a roadmap as a deliverable until the spike clears.

For engineering: This is a Tourze-family bundle (product-auto-up-bundle) at 0.0.1, published with an empty changelog — version and changelog are the only signals we have, so the spike's first task is reading the source to confirm what the auto-up transition actually guards (idempotency, concurrent transitions, rollback on failure) and whether it assumes a particular product/listing model. Pin the exact version, wrap it behind our own interface so it stays swappable, and confirm test coverage and CI before it touches any environment beyond a sandbox. Assume the API will break before 1.0 and budget for that on every bump.