From 78c23c7105914b74ae91c71496265d3b03d7e285 Mon Sep 17 00:00:00 2001
From: nsfisis <nsfisis@gmail.com>
Date: Sun, 9 Aug 2026 19:10:27 +0900
Subject: feat(plugin): let a Rust-implemented plugin cross into the worker

PluginManager::getPluginCapability hands the plugin itself to the
capability constructor. Only a PHP-implemented plugin had an entity the
child could receive, so a Rust-implemented one bailed out; it now crosses
as a handle to an R-table entity behind Shirabe\RustPluginStub, or its
Capable flavour, since `$plugin instanceof Capable` is what decides
whether Composer asks a plugin for capabilities at all.

This is what the two capability tests of PluginInstallerTest were waiting
on: the mocked Capable plugin is Rust-side, and one of them asserts the
identity of the plugin read back out of $capability->args.
---
 .../php/runtime/Shirabe/RustCapablePluginStub.php       | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 crates/shirabe-php-rpc/php/runtime/Shirabe/RustCapablePluginStub.php

(limited to 'crates/shirabe-php-rpc/php/runtime/Shirabe/RustCapablePluginStub.php')

diff --git a/crates/shirabe-php-rpc/php/runtime/Shirabe/RustCapablePluginStub.php b/crates/shirabe-php-rpc/php/runtime/Shirabe/RustCapablePluginStub.php
new file mode 100644
index 00000000..7a7c7eef
--- /dev/null
+++ b/crates/shirabe-php-rpc/php/runtime/Shirabe/RustCapablePluginStub.php
@@ -0,0 +1,17 @@
+<?php
+
+// The Capable flavour of RustPluginStub: `$plugin instanceof Capable` decides whether Composer
+// asks a plugin for capabilities, so the stub class is picked to match what the Rust-side
+// plugin implements.
+
+namespace Shirabe;
+
+use Composer\Plugin\Capable;
+
+class RustCapablePluginStub extends RustPluginStub implements Capable
+{
+    public function getCapabilities()
+    {
+        return \ShirabeRpcRuntime::callRust($this->__rhandle, 'getCapabilities', []);
+    }
+}
-- 
cgit v1.3.1-4-g156e