Atp Schema Laravel Package

Product Decisions This Supports

• Build vs. buy on AT Protocol data modeling. SocialDept\AtpSchema (formerly SocialDept\Schema) gives Laravel teams a schema/lexicon layer for AT Protocol records — the shapes behind Bluesky posts, profiles, feeds, and labels. If your roadmap touches the AT Protocol at all (cross-posting, custom feeds, labelers, PDS-adjacent tooling), this package decides whether you write record validation and typing yourself or inherit it.
• Roadmap sequencing for anything AT Proto–shaped. Because the package is at v0.3.0 and pre-1.0, it should be treated as an evaluation-stage dependency. It supports "prototype and learn" decisions, not "commit the core data layer" decisions. Plan a spike, not a platform bet.
• Feature scoping conversations. Adoption lets you say yes to schema-driven features (record validation, typed accessors for protocol objects, lexicon conformance) without a bespoke implementation estimate — but only if the team accepts a moving API surface.
• Ecosystem alignment. The rename to SocialDept\AtpSchema signals the maintainer is standardizing naming across their AT Protocol package family. That consistency is a mild positive signal for teams intending to adopt more than one package from the same vendor — it reduces the "each package has its own conventions" tax.

When to Consider This Package

Consider it when:

• You are already a Laravel/PHP shop building against the AT Protocol and want schema/lexicon handling that fits Laravel conventions rather than porting a TypeScript reference implementation.
• You need record validation and typed structures for AT Protocol objects and want to avoid hand-rolling and maintaining them.
• You can pin an exact version in composer.json and afford a migration pass when the namespace moves again.
• Your team is comfortable with pre-1.0 churn — no SemVer stability guarantees, breaking changes shipped in minor bumps.

Look elsewhere (or defer) when:

• You need API stability. v0.3.0 with a major breaking rename is a clear signal that the surface is still forming. If this package would sit under production-critical write paths, wait for 1.0 or wrap it behind your own adapter layer so the namespace change is a one-file edit.
• Your stack isn't PHP/Laravel. The TypeScript AT Protocol ecosystem (@atproto/*) is the reference implementation and moves faster; bridging across languages is real cost.
• You only need trivial interaction (posting via HTTP). A thin HTTP client is cheaper than a schema dependency.
• You can't absorb the migration right now. The SocialDept\Schema → SocialDept\AtpSchema rename touches every use statement and any string-based class references (config, container bindings, serialized class names in queues). Scope that before committing.

Migration note for anyone already on v0.2.x: this is a hard rename, not an alias. Expect a find-and-replace across use declarations, plus a check for class names in config/, container bindings, cached/serialized payloads, and any database rows storing fully-qualified class names. Do not let queued jobs with serialized class names straddle the deploy.

How to Pitch It (Stakeholders)

For executives: This is a small, pre-1.0 open-source Laravel package that handles AT Protocol schema definitions — useful if we pursue anything on Bluesky's protocol, but not production-hardened. Recommendation: fund a short spike (days, not weeks), not a platform commitment. The v0.3.0 release is a package rename with explicit breaking changes, which confirms it's still stabilizing; we should not put it under critical paths yet.

For engineering: SocialDept\Schema is now SocialDept\AtpSchema as of v0.3.0 — a deliberate namespace standardization across the maintainer's AT Protocol package family. The rename is breaking and there's no published alias, so any existing code needs a mechanical migration plus a sweep for string-referenced class names. Given pre-1.0 status, adopt behind a thin internal adapter: we get schema handling for free, and when the namespace or API shifts again we change one file instead of the codebase. Pin the exact version — do not use a caret constraint.