Pillars
=======

These pillars define what belongs in ``vendor-fabric``.

Providers Are Data Extensions
-----------------------------

Every provider should feel like an extension of ``ExtendedData``, not a
separate utility island. Provider inputs and outputs should be promoted
into extended containers wherever doing so helps callers transform,
redact, export, sync, or inspect results.

Capability-Driven Dispatch
--------------------------

The fabric should dispatch by capabilities declared by providers.
Repeated hardcoded pass-through methods should be avoided when a
provider can declare support once and the facade can route generically.

Optional Means Discoverable
---------------------------

Optional provider dependencies are normal for this package. Missing
extras should be visible through registry state and clear install
guidance, not through unexpected import failures in ordinary package
imports.

Sync Is A First-Class Capability
--------------------------------

File sync and secret sync are provider capabilities. They should compose
``extended-data`` primitives for redaction, encoding, decoding, and file
handling while delegating canonical SecretSync pipeline semantics to the
``jbcom/secrets-sync`` binding facade.

Agent Runtime Is Out Of Scope
-----------------------------

Agent orchestration, crew discovery, framework selection, and agent
runner fixtures belong in ``agentic-fabric``. This package can expose
provider-backed capability functions, schemas, and metadata, but it
should not own agent runtimes or framework tool factories.

Tests Define Provider Contracts
-------------------------------

Unit tests, mocked provider tests, optional dependency tests, and opt-in
E2E tests are part of the public contract. ``pytest-vendor-fabric``
should make it straightforward for downstream projects to test code
built on this package.