Statamic Directory Laravel Package

Product Decisions This Supports

• Build vs. buy for team/claim integration: This package sits on top of goldnead/statamic-teams, layering a claim adapter. If your product needs to map Statamic teams onto claim/token semantics (e.g., membership-backed authorization claims), this is a candidate "buy/assemble" component rather than something to build in-house — but only once you have validated the underlying teams package is a fit.
• Feature feasibility on Statamic-based stacks: Confirms that claim-aware team behavior is achievable in a Statamic/Laravel codebase without custom glue. Useful when scoping roadmap items such as team-scoped permissions, SSO/claim propagation, or delegated access.
• Dependency and platform hygiene decisions: The v0.1.1 fix shows the package is tightly coupled to a specific minor line of statamic-teams (^0.4). That is a roadmap input: pinning strategy, lockfile discipline, and how much upgrade surface you inherit by adopting it.
• Prioritization of integration work: Because 0.1.0 pinned ^0.3 (which has no claim adapter), the previous release was functionally unusable for its stated purpose. If you trialed 0.1.0, treat any findings as invalid; re-test on 0.1.1 before making a build/buy call.
• Not a decision driver on its own. Release evidence here is a single patch line item. Use it to unblock a spike, not to justify a committed roadmap line.

When to Consider This Package

Consider it when:

• You are on a Statamic + Laravel application and already use (or are evaluating) goldnead/statamic-teams at ^0.4.
• Your requirement is specifically claim adaptation over team membership — i.e., you need team data exposed as claims for downstream authorization or token issuance.
• You are comfortable with pre-1.0 dependencies. Both this package (0.1.x) and its upstream are early-stage; expect breaking changes and thin documentation.
• You want a short evaluation spike, not a production commitment. The ^0.3 → ^0.4 correction in a patch release signals the integration contract is still settling.

Look elsewhere when:

• You need stable, documented APIs with a support window. There is no 1.x here.
• Your team/authorization model is not Statamic-team-centric — the package's value is entirely inherited from that upstream.
• You require claim formats beyond what statamic-teams 0.4 exposes; you would be extending or forking a very young dependency chain.
• You cannot pin and control transitive versions — the 0.1.0 breakage was purely a constraint mistake, which is a warning about the maintenance surface.
• You are evaluating statamic-teams itself. This package does not help you decide that; assess the upstream first.

Adoption checklist before committing: confirm statamic-teams ^0.4 is already in your dependency tree, verify the claim adapter's output shape against your authorization consumer, and confirm you can absorb a 0.x breaking release mid-quarter.

How to Pitch It (Stakeholders)

To executives: This is a small, early-stage connector that lets a Laravel/Statamic app express team membership as authorization claims. It is a low-cost way to test whether team-based access control can be assembled from existing components instead of built. It is not yet a platform commitment — version 0.1.x, with a dependency-pinning defect fixed in its most recent patch. Recommend funding a time-boxed spike, not a roadmap line.

To engineering: v0.1.1 corrects the goldnead/statamic-teams constraint from ^0.3 to ^0.4, because ^0.3 ships no claim adapter — meaning 0.1.0 could not perform its core function. If anyone prototyped against 0.1.0, discard those results. Pin ^0.4 explicitly, treat the adapter's claim contract as unstable, and budget for a breaking change before 1.0. Worth a one-to-two day evaluation if we are already invested in Statamic teams; otherwise defer until the upstream stabilizes.