@@ -12,26 +12,27 @@ Pure computation, in-memory state, no I/O. Always deepenable: merge the modules
 
 ### 2. Local-substitutable
 
-Dependencies that have local test stand-ins (PGLite for Postgres, in-memory filesystem). Deepenable if the stand-in exists. The deepened module is tested with the stand-in running in the test suite. The seam is internal; no port at the module's external interface.
+Dependencies you can run for real in a test: Postgres, Redis, the filesystem. Deepenable. The seam is internal; no port at the module's external interface. Verify the deepened module against the real dependency (a `*.integration.ts` suite on real Postgres/Redis) or end to end, never against a hand-built stand-in.
 
 ### 3. Remote but owned (Ports & Adapters)
 
-Your own services across a network boundary (microservices, internal APIs). Define a **port** (interface) at the seam. The deep module owns the logic; the transport is injected as an **adapter**. Tests use an in-memory adapter. Production uses an HTTP/gRPC/queue adapter.
+Your own services across a network boundary (microservices, internal APIs). Define a **port** (interface) at the seam. The deep module owns the logic; the transport is injected as an **adapter**. Production uses an HTTP/gRPC/queue adapter. Prove the module end to end over the real transport (`apps/sim/scripts/test-*-e2e.ts`) rather than through an in-memory adapter written only for tests.
 
-Recommendation shape: *"Define a port at the seam, implement an HTTP adapter for production and an in-memory adapter for testing, so the logic sits in one deep module even though it's deployed across a network."*
+Recommendation shape: *"Define a port at the seam and implement the production adapter there, so the logic sits in one deep module even though it's deployed across a network."*
 
 ### 4. True external (Mock)
 
-Third-party services (Stripe, Twilio, etc.) you don't control. The deepened module takes the external dependency as an injected port; tests provide a mock adapter.
+Third-party services (Stripe, Twilio, etc.) you don't control. The deepened module takes the external dependency as an injected port. Where an isolated test is unavoidable, use the shared mocks in `@sim/testing` and `apps/sim/vitest.setup.ts` rather than hand-rolling one.
 
 ## Seam discipline
 
-- **One adapter means a hypothetical seam. Two adapters means a real one.** Don't introduce a port unless at least two adapters are justified (typically production + test). A single-adapter seam is just indirection.
+- **One adapter means a hypothetical seam. Two adapters means a real one.** Don't introduce a port unless at least two adapters are justified. A single-adapter seam is just indirection.
 - **Internal seams vs external seams.** A deep module can have internal seams (private to its implementation, used by its own tests) as well as the external seam at its interface. Don't expose internal seams through the interface just because tests use them.
 
 ## Testing strategy: replace, don't layer
 
-- Old unit tests on shallow modules become waste once tests at the deepened module's interface exist; delete them.
-- Write new tests at the deepened module's interface. The **interface is the test surface**.
-- Tests assert on observable outcomes through the interface, not internal state.
-- Tests should survive internal refactors, since they describe behaviour, not implementation. If a test has to change when the implementation changes, it's testing past the interface.
+Testing follows the repo's rules in `CLAUDE.md` ("Testing") and the `test-audit` skill; this section only says how they apply to deepening.
+
+- Old unit tests on shallow modules become waste once the deepened module exists; delete them. Deleting a test that only restated a pass-through is a win, not lost coverage.
+- Don't write new unit tests at the deepened interface after the fact. Prove the change through the real boundary: a `*.integration.ts` suite on real Postgres/Redis, or an end-to-end run.
+- Whatever tests remain assert on observable outcomes through the interface, not internal state. If a test has to change when the implementation changes, it's testing past the interface.
@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Matt Pocock
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
@@ -75,10 +75,10 @@ Good interfaces make testing natural:
 
    ```typescript
    // Testable
-   function processOrder(order, paymentGateway) {}
+   function processOrder(order: Order, paymentGateway: PaymentGateway): Promise<Receipt> {}
 
    // Hard to test
-   function processOrder(order) {
+   function processOrder(order: Order): Promise<Receipt> {
      const gateway = new StripeGateway();
    }
    ```
@@ -87,10 +87,10 @@ Good interfaces make testing natural:
 
    ```typescript
    // Testable
-   function calculateDiscount(cart): Discount {}
+   function calculateDiscount(cart: Cart): Discount {}
 
    // Hard to test
-   function applyDiscount(cart): void {
+   function applyDiscount(cart: Cart): void {
      cart.total -= discount;
    }
    ```
@@ -113,5 +113,5 @@ Good interfaces make testing natural:
 
 ## Going deeper
 
-- **Deepening a cluster given its dependencies**, see [DEEPENING.md](DEEPENING.md): dependency categories, seam discipline, and replace-don't-layer testing.
+- **Deepening a cluster given its dependencies**, see [DEEPENING.md](DEEPENING.md): dependency categories, seam discipline, and replace-don't-layer testing (which defers to `CLAUDE.md` "Testing" and the `test-audit` skill).
 - **Exploring alternative interfaces**, see [DESIGN-IT-TWICE.md](DESIGN-IT-TWICE.md): spin up parallel sub-agents to design the interface several radically different ways, then compare on depth, locality, and seam placement.