README

The one uniform swappable-driver pattern every Vortos deploy/ops concern reuses (roadmap §10). Build it once here so concerns 2–26 never reinvent registry / compiler-pass / capability / TCK subtly differently — the guard against "a mess all over the place."

What's in the box

Adding a concern (the shape every concern follows)

// 1. A port that extends DriverInterface
interface DeployTargetInterface extends DriverInterface { /* ... */ }

// 2. A typed registry
final class DeployTargetRegistry extends TaggedDriverRegistry {
    public function __construct(ContainerInterface $drivers) { parent::__construct('deploy', $drivers); }
    public function target(string $key): DeployTargetInterface { return $this->get($key); }
}

// 3. A collecting pass
final class CollectDeployTargetsPass extends CollectDriversCompilerPass {
    public function __construct() { parent::__construct('vortos.deploy.target', 'vortos.deploy.target_locator', 'deploy'); }
}

// 4. In the concern's DI extension:
//    - register the ServiceLocator (tag container.service_locator) + the registry
//    - registerForAutoconfiguration(DeployTargetInterface::class)->addTag('vortos.deploy.target')
//    - in Package::build(): CollectDriversCompilerPass::register($container, new CollectDeployTargetsPass())

// 5. A conformance TCK base for the port (extends ConformanceTestCase), and an
//    agnosticism test (extends AgnosticismLintTestCase).

A driver is then just: implement the port + #[AsDriver(key: '…')]. vortos:make:driver writes that for you.

Tests

docker compose exec backend ./vendor/bin/phpunit --testsuite OpsKit