What problem does it solve? When a consumer and supplier live on the same side of a boundary (in-process), teams often either over-engineer the seam with HTTP/OpenAPI projections or skip the boundary entirely and couple directly to the supplier's domain types. This Skill defines the light variant of a boundary: a code interface plus a contract test, nothing else. ## Core Features & Use Cases - Port as code interface: The consumer depends on a plain code interface and the Adapter implements it, both compiled in the same process, with no generated types or CDC publish/verify. - In-process contract test: The consumer-driven abstract test class is instantiated twice — once on a fake of the port so the consumer is green on its own (D1), and once on the real Adapter over the real supplier to weld the boundary (D2). - Published Language typing: Boundary types stay primitive or shared-kernel rather than the supplier's domain type, preventing coupling even inside one process. - Use Case: When the mismAgent worker-composer builds a block whose manifest pins boundary.projection = in-process, this Skill is loaded alongside realize-port/realize-adapter to keep the seam minimal yet tested. ## Quick Start Ask the worker to build the block whose boundary projection is in-process so the port stays a code interface with an in-process contract test.
