Product Decisions This Supports

Vocabulary standardization, not features. tourze/operation-system-enum is a small, domain-constant package — it gives PHP code a typed, shared list of operating-system values. The PM-relevant decision it unlocks is consistency of platform categorization across reporting, segmentation, licensing/support tiers, and analytics dimensions, rather than any user-facing capability.
Build vs. buy. Any team can write this in an afternoon; the genuine value is interop with the broader Tourze package set and a maintained, versioned source of truth. Choose it when "one definition of an OS value shared across services" beats "five slightly different string constants."
Dependency hygiene / roadmap housekeeping. Adopting it is a small step in reducing bespoke glue code and string literals that quietly drift between services — a low-cost, low-risk roadmap line item.
Versioning risk posture. The 1.0.0 milestone is the substantive news here: it implies a semver stability commitment (^1.0), whereas 0.0.2 carried no backward-compatibility guarantee. That changes the calculus from "evaluate cautiously, expect churn" to "safe to pin."

When to Consider This Package

Adopt when:

You are already in (or moving toward) the Tourze ecosystem and want consistent typing at the boundaries.
Multiple services or teams need the same OS vocabulary and you want a single, versioned source rather than duplicated constants.
You are on PHP 8.1+ (native enums) and want a semver-stable dependency you can pin without surprises.

Look elsewhere or build in-house when:

You need behavior, not just constants — OS/platform detection from user agents, mapping to icons, license text, EOL dates, or support-tier logic. This package will not do that work for you.
You would be adding a third-party dependency for a handful of enum cases; for a single-service codebase the supply-chain and upgrade surface can outweigh the benefit.
Verification caveat for 1.0.0: the release notes contain only a changelog link, with no described features, fixes, or breaking changes. The 0.0.2 → 1.0.0 jump is large enough that renamed or removed enum cases are plausible. Treat "stabilized API" as likely but unconfirmed — read the compare diff before pinning, and do not assume case names carried over.

To executives: A negligible-cost, negligible-footprint dependency that standardizes how we label operating systems across services and removes a class of copy-paste drift. The 1.0.0 release means the API is now stable and safe to pin — low risk, no migration burden, no customer-visible change.
To engineering: Typed enum replacing ad-hoc OS string constants, now at a semver-stable major version. Pin to ^1.0. Before upgrading anything from 0.0.x, diff the changelog for renamed cases — the release notes are empty, so the upgrade path is verified from the diff, not the announcement. If we need actual platform detection or OS metadata, plan for a separate solution; this package is the vocabulary layer only.