Acme Schemas Laravel Package

Product Decisions This Supports

• Reference architecture for schema packaging, not a runtime dependency. acme-schemas is an example/placeholder domain ("Acme") whose real value is showing how to package versioned schemas as a Composer-installable library on top of gdbots/schemas. It informs the "how do we ship contracts" decision rather than the "which contracts" decision.
• Build vs. buy for the schema layer. Use it as the baseline design pattern when deciding whether to hand-roll domain DTOs/validation in application code or extract them into a standalone, versioned schema package. It demonstrates the "extract + version" option concretely.
• Versioning and compatibility policy. The release history (v3.0.2 bumping gdbots/schemas to v3.0.3) models the kind of dependency-pinning discipline you'd want in your own schema packages — useful input to a decision on SemVer policy for message contracts and how breaking schema changes propagate to consumers.
• Message/event contract design for GDBots-based services. If the roadmap includes event-driven features on GDBots messaging, this illustrates the shape of a canonical message set (serialization, validation, exchange) before you commit to a first-party schema repo.
• Test fixture strategy. Because it is explicitly test schemas, it supports a decision to keep a lightweight, non-production schema package for integration tests, CI fixtures, and local dev, isolated from production contracts.
• Roadmap gating: effectively a do-not-invest signal for direct adoption — 0 stars, 0 dependents, no release since June 2023. Any roadmap item that assumes this package is a maintained dependency should be re-scoped.

When to Consider This Package

Consider it only under narrow conditions:

• You are already inside the GDBots ecosystem, already depend on gdbots/schemas (v3.x line), and want a worked example of how to structure your own yourcompany-schemas package — file layout, Composer metadata, version coupling, and release notes.
• You need throwaway test schemas for local development or a proof of concept and want to avoid inventing fixtures from scratch.
• You are evaluating a build-vs-adopt argument for a schema package and need a concrete artifact to compare against a proposed internal design.

Look elsewhere — or build your own — when:

• You need production contracts. The "Acme" domain is a placeholder; nothing here is your domain model, and nothing here is semantically yours.
• You require maintenance guarantees. No release since 2023-06-05, zero stars, zero dependents, and no downstream signals of real-world use. There is no community to absorb bugs or security issues, and Apache-2.0 gives you the right to fork but not the labor to maintain.
• Your stack is not GDBots. The package is framework-agnostic and offers nothing Laravel-specific — no service provider, no config publishing, no facade, no Eloquent integration. A Laravel team gets no framework leverage here.
• You need schema formats outside the GDBots toolchain (e.g., Protobuf/Avro/JSON Schema with mainstream generators). The tooling surface is narrow.
• You want discoverability or hiring signal. Nothing here is searchable, documented beyond a two-line README, or known to candidates.

Adoption criteria, if you proceed: pin exact versions, vendor the source or fork under your org, treat it as read-only reference, and keep it out of any runtime path that production traffic depends on.

How to Pitch It (Stakeholders)

For executives: This is not a dependency proposal — it's a pattern we can copy. gdbots/acme-schemas is a small, unmaintained (last release mid-2023, zero downstream users) example package that shows how to publish domain schemas as a versioned Composer library. It has no commercial value on its own; the value is the template. Recommendation: do not add it as a dependency; instead, budget a small, time-boxed engineering spike to design our own schema package using this as a reference. Cost is low; the real risk is treating an abandoned example as infrastructure.

For engineering: Structurally it's clean and worth borrowing — centralized domain schemas, PHP-ready definitions for validation and serialization, explicit version-aware contracts, Composer-installable, framework-agnostic, and a dependency pin on gdbots/schemas v3.0.3. It is explicitly test schemas for a placeholder "Acme" domain. So: read it as a design document, not a library. Caveats to flag — no Laravel integration at all (no provider, config, or facade), no test suite or CI signal we can see, single-maintainer risk, and a hard coupling to the GDBots v3 line. If we adopt the pattern, we own the package; if we adopt the package, we own a fork we didn't want.

The one-line decision: Adopt the pattern, reject the dependency.