Ozon Support Laravel Package

Technical Evaluation

What a TPM is actually buying (scope reality check)

• The README title is «Модуль техподдержки Ozon» — an Ozon technical-support module, not an Ozon Seller/marketplace API client. The documented surface is: one composer require, one console command that registers a user profile type (baks:users-profile-type:ozon-support), and one tagged PHPUnit group.
• Nothing in the artifacts evidences OAuth2, order/refund flows, inventory sync, webhooks, Ozon Pay, delivery, or rate-limit handling. Any roadmap line item that treats this install as "Ozon marketplace integration" must be corrected before estimation.
• Translation for planning purposes: this is a small classification/plumbing module that lets a host application mark a user or support context as "Ozon" inside the BaksDev users subsystem. Its leverage is support-operations hygiene, not revenue.

Architecture fit

• Not standalone. It is a satellite of the BaksDev ecosystem and presumes a pre-existing users/profile-type subsystem plus a Symfony-style console (bin/console, not artisan). Fit is good only if BaksDev is already in the stack; poor-to-negative for a generic Laravel application.
• The "Laravel/Symfony-compatible" phrasing in the package description is not corroborated by any concrete install or test command — every documented command is Symfony-shaped. Treat Laravel support as a claim to be proven in a spike, not a feature to be planned against.
• Coupling is nominally low (a registered type), so it is removable. That removability is the main architectural virtue here.

Integration feasibility

• The install itself is trivial (composer require); the real cost is environment bootstrap — migrations, profile-type registration, running the command, and the fact that skipping it leaves the module effectively inert.
• Feasibility therefore collapses to one question: is BaksDev already in the stack? If yes, this is days. If no, the package drags in a framework convention you are not otherwise buying.

Technical risk

• Adoption risk: high. 0 stars, 0 dependents, no community, no docs beyond a ~14-line README, no changelog.
• Change-management risk: high. Releases 7.4.13 → 7.4.17 are documented only as the version string repeated. There is no bugfix/feature/breaking-change signal. A 7.4.17 version with a 2026-07-20 release date suggests lockstep monorepo versioning rather than semver for this module alone.
• Platform risk: moderate. Hard php 8.4+ floor constrains hosting, CI base images, and any legacy services in the estate.
• Verification risk: moderate. A test group exists (--group=ozon-support), but there is no badge, no visible CI, and no integration tests against a live Ozon surface.
• Licensing risk: low. MIT, forkable, no vendor lock-in.

Key questions to put to the author or spike owner

1. Does this package make any outbound call to Ozon at all, or is it purely a local profile-type label?
2. Which baks-dev/* packages are hard dependencies, and does installing this force a wider BaksDev footprint?
3. Is it a Symfony bundle, a Laravel package, or framework-agnostic PHP? What does registration look like?
4. What schema does the profile type introduce, and is it reversible?
5. What changed in 7.4.14–7.4.17, and is there a backwards-compatibility policy?
6. Who maintains it, what is the bus factor, and is there any commitment to PHP 8.5 / next major?
7. Are user-facing strings hardcoded Russian, and how are they localized?

Integration Approach

Stack fit

• Symfony-style PHP 8.4+ application with an existing BaksDev user/profile layer: fit. Everything else: not a fit, and the honest TPM recommendation is not to adopt.
• If the real need is "integrate with Ozon as a sales channel," this package does not address it. Scope that separately and do not let this install be reported upward as marketplace readiness.
• Given the brief frames this as a "Laravel/PHP package": the PHP part is real, the Laravel part is unverified. Do not commit to a Laravel integration path until a spike proves the service-provider story.

Migration path

1. Artifact audit before code — read composer.json (requires/conflicts), the service provider/bundle class, and the migrations. Confirm what the profile type actually writes.
2. Timeboxed spike (≤1 sprint) in a disposable branch: install, run the profile-type command, diff the resulting schema, run --group=ozon-support.
3. Wrap, don't leak — if adopted, isolate the vendor type behind an internal adapter/interface so domain code never references baks-dev namespaces directly. Removal then becomes a one-class change.
4. Gate on evidence — proceed to production only after the spike produces a written capability list that matches reality, signed off by engineering.

Compatibility

• Pin the exact version and commit composer.lock; do not float ^7.x given opaque patch releases.
• Validate the PHP 8.4 floor against your CI matrix and container base images before the spike, not after.
• Check for DI container key and namespace collisions with your existing user model.

Sequencing relative to other work

• This is a support-operations enabler. Sequence it behind any actual commerce/API integration work, and only if the support workflow is already a measurable bottleneck.
• Do not block a marketplace roadmap on it. The critical path for Ozon selling capability is a real seller-API integration; this package is at best optional adjacent convenience.
• Recommended order: (a) confirm the business need for Ozon support routing, (b) spike, (c) adapter + tests wired into your own CI, (d) fork-to-private if the spike succeeds but maintenance confidence does not.

Operational Impact

Maintenance

• Assume you own this code from day one. Zero dependents and zero stars means no upstream pressure to fix anything you find; a private fork with a named owner is the realistic steady state.
• Upgrades across baks-dev/* are likely coordinated, not independent — budget a bundle-wide bump rather than a single-package bump. Because release notes carry no content, every upgrade requires a source diff.

Support

• No community, no issue triage history, no English documentation. Internal runbooks must be written during the spike or they will never exist.
• The README is Russian-only; onboarding material for non-Russian-reading engineers is a real, if small, cost.

Scaling

• The module itself is configuration/registration plumbing — runtime load is negligible, and there is no queue, worker, or external-call surface to scale.
• The scaling question that actually matters is the surrounding Ozon support workflow: ticket volume, attachment storage, retention, and PII handling in whatever system consumes the profile type. Plan that capacity independently.

Failure modes

• Silent inertness: command not run → type unregistered → feature simply absent, with no error.
• Opaque regression: a patch bump changes behavior with no changelog; failures surface in production, not in review.
• PHP floor drift: next PHP major or a tightened 8.4 constraint blocks deploys of the whole monorepo cohort.
• Orphaning: maintainer disappears; you are left on a private fork with no upstream security patches.
• Tests outside CI: the ozon-support group is opt-in; if it is not wired into your pipeline, regressions ship unnoticed.
• Scope inflation (organizational, and the most likely here): the install gets logged internally as "Ozon integrated," and downstream planning assumes marketplace capability that does not exist.

Ramp-up

• A mid-level PHP engineer in an existing BaksDev app: roughly 1–2 days to read the module and understand the profile-type registration; ~1 sprint to integrate, test, and adapter-wrap.
• In a non-BaksDev stack: unknown and unbounded — treat this as "requires adopting an entire framework convention," which is a different decision than adopting a package.

TPM bottom line

• Leverage is narrow and operational: it may cheaply standardize how Ozon-related support identities are modeled, if you are already inside BaksDev. It is not a marketplace capability and should not be sequenced as one.
• Confidence in that statement is medium-low: the artifacts let a TPM verify install instructions, not capabilities. The highest-value action is a one-week spike plus written capability confirmation; the second is correcting any internal narrative that equates this package with Ozon seller integration.