What problem does it solve? When building Effect applications, developers struggle to decide whether a dependency should be modeled as a simple witness (a value that exists in the environment) or a full capability (a service with operations), and whether fields belong in the domain schema or should be injected via Context. Wrong choices lead to bloated schemas, hard coupling, and difficult testing. ## Core Features & Use Cases - Witness vs Capability Decision Framework: Provides a decision table mapping needs (presence, operations, mocking, side effects) to the correct Context.Service pattern. - Hard vs Soft Coupling Guidance: Shows how to remove non-persisted fields (correlation IDs, request IDs, timestamps) from Schema definitions and inject them as witnesses instead. - Testing Implications: Demonstrates how witnesses are trivially provided with Effect.provideService while capabilities require full implementations. - Use Case: When modeling an Order or PaymentIntent, keep only persisted data in the Schema and inject CorrelationId, RequestId, and Clock values through Context, yielding explicit dependencies in the Effect type signature. ## Quick Start Ask the assistant to review your Effect service definitions and decide whether each dependency should be a witness or a capability using the effect-context-witness guidance.
