In Other Shops Laravel Package

Product Decisions This Supports

• Unblocking a live customer-facing defect (P0 for bianka). Every order show/edit page in bianka's order admin is currently 500ing. This release is the fix, not a workaround — so it directly informs the "ship a hotfix now vs. wait for the next scheduled release" call. Recommendation: cut a patch release and bump bianka immediately; the blast radius of leaving it is an unusable back-office.
• Build vs. buy / single-package vs. per-site forks. The root cause is that the package had silently assumed catalog text lives in columns. That assumption is now removed and codified (docs/periphery.md → "Catalog text is not a column"). This is the deciding evidence that one shared package can serve both column-backed catalogs (in-other-worlds) and translations-table catalogs (bianka) — avoid forking the order admin per consumer.
• Roadmap: schema-agnostic catalog support becomes a supported promise, not an accident. "Model-level access always worked; only query-level reads broke" means the package can now be positioned as compatible with translated/attribute-driven catalogs. That opens the door to onboarding additional stores with i18n catalogs without bespoke patches — a growth argument for the package, not just a maintenance one.
• New public API to standardize on. Support\ModelLabel::for(Model): string (resolves name → title → label → slug → "{alias} #{id}", never null, never empty) is a small, stable primitive. PM decision: mandate it for all display-label rendering in admin, storefront and any outbound comms (emails, exports, receipts) to prevent a class of "blank product name" bugs that are invisible in tests but visible to customers.
• Stability contract for downstream teams. Signatures and the {alias}:{id} option-key format are unchanged, and changes are additive for in-other-worlds. That keeps upgrade cost near zero for column-backed consumers — useful when sequencing upgrades across multiple site teams.
• Testing investment decision. The suite runs on SQLite, which structurally cannot reproduce this failure (double-quoted identifiers degrade to string literals, so missing columns become always-false predicates or no-op sorts instead of errors). Two "passing" tests were green against broken code until fixtures were rearranged. This is a strong argument for funding a MySQL CI lane — the green suite gave false assurance on a bug that reached production.

When to Consider This Package

Adopt / bump now when:

• Your catalog stores name/description in a translations table (or any non-column source) and you use this package's order admin or storefront listing. Without this release those pages 500 — this is mandatory, not optional.
• You maintain multiple storefronts on one shared package and want to stop maintaining per-site patches for schema differences.
• You need a guaranteed-non-empty display label anywhere a product/cartable is rendered, and want a single tested resolver instead of ad-hoc ?? $model->id fallbacks.
• You are already on this package and the bump is additive (column-backed catalogs): low-risk, take it opportunistically to stay current.

Look elsewhere or wait when:

• Your catalog is strictly column-backed and you have no i18n ambition — the fix is a no-op for you, so treat it as routine version hygiene rather than a priority.
• You cannot validate on MySQL (or your production engine) before deploy. The package's own suite cannot catch this class of bug on SQLite. If your pipeline is SQLite-only and you have translated catalogs, do not treat a green build as evidence of correctness — arrange a MySQL verification pass against real consumer data, as the maintainers did.
• You have no order admin or storefront listing surface in use, i.e. you consume only the untouching parts of the package — the urgency disappears.
• You were relying on column names appearing in generated queries (custom query builders, reporting, raw SQL against the same models). The package now resolves labels through getAttribute(); audit any code that assumed where('name', …) worked, since that assumption was never contractual.

How to Pitch It (Stakeholders)

To executives: A live production outage in one of our sites — the order admin is throwing 500s on every order page, which blocks order handling — is fixed by a small, additive package release. The underlying flaw was that the shared package assumed product names live in database columns; one of our catalogs stores them in a translations table, so query-level reads failed. The fix removes that assumption permanently and adds a guaranteed-non-empty label resolver, so we don't re-litigate this per site. Risk is low: no signature changes, nothing removed, and the other site is unaffected. Action: bump the affected site now.

To engineering: Two query-level reads were the fault — pluck('name', 'id') in CommerceSchema::buildOrderableOptions() and where('name'/'description','like') / orderBy('name') in ListBrowsables. Model-level access was always fine; the contract never promised a column. Both are replaced by attribute-based resolution, with Support\ModelLabel::for() as the new public entry point. 1065 tests (+10), including the missing translatable-cartable fixtures and the first tests for ListBrowsables. Critical caveat: SQLite cannot reproduce this failure, so a green suite is not proof — verify against MySQL with real consumer data before closing, and treat a MySQL CI job as follow-up work. Bump bianka immediately; in-other-worlds can take it on the normal cadence.