library-third-party-decoupling
Library Third-Party Decoupling — Interface + Provider From Day One
Section titled “Library Third-Party Decoupling — Interface + Provider From Day One”Kit-wide, engine-agnostic, decision-authority rule — act on it without re-asking. The third-party arm of library-quality-mandate.md; per-engine mechanics live in docs/: extend it, never fork the principle.
No core library package may hard-reference a third-party dependency (anything not platform-stdlib or first-party/The1Studio). A consumer MUST be able to remove that dependency and still build and run the library.
Design the seam FIRST. The moment you reach for a third-party API, STOP and define a library-owned interface the core depends on; the vendor call lives behind a provider implementing it, discovered via registry/DI/dynamic-import over the library’s own interface — core never names the vendor type. Never write the direct call “for now” — extract-later is tech debt in disguise.
Graceful degradation when no provider is present: warn + skip (tooling / one-shot ops) or a NoOp null-object (hot paths). Never throw by default, never hard-block, never swallow without a logged signal at registration.
Not third-party (hard refs fine): platform-stdlib, engine-shipped, first-party. Also exempt: build-only one-offs never shipped to consumers; test-only targets gated from the runtime build.
Full details
Section titled “Full details”Decision-authority table, canonical pattern, per-engine mechanics map, the 6 objective pass-tests, the Known-Non-Conformant honesty clause, anti-patterns, history: docs/library-third-party-decoupling.md. How-to: skill t1k-library-decoupling.