Update

.github/copilot-instructions.md

@@ -0,0 +1,21 @@
+### Review Comment Linking Guidelines
+
+When writing review comments based on custom instructions located in .github/instructions/**.instructions.md, include a direct GitHub link to the exact violated guideline in the respective instruction file. Use the following format:
+
+    Refer: https://github.com/rdkcentral/entservices-peripherals/blob/develop/.github/instructions/<instruction-file>.instructions.md#guideline-section-name
+
+## Examples
+
+Refer: https://github.com/rdkcentral/entservices-peripherals/blob/develop/.github/instructions/Plugin.instructions.md#interface-implementation 
+
+Refer: https://github.com/rdkcentral/entservices-peripherals/blob/develop/.github/instructions/Pluginlifecycle.instructions.md#deactivated
+
+Refer: https://github.com/rdkcentral/entservices-peripherals/blob/develop/.github/instructions/Pluginimplementation.instructions.md#inter-plugin-communication 
+
+Refer: https://github.com/rdkcentral/entservices-peripherals/blob/develop/.github/instructions/Pluginmodule.instructions.md#module-name-convention
+
+Refer: https://github.com/rdkcentral/entservices-peripherals/blob/develop/.github/instructions/Pluginconfig.instructions.md#plugin-configuration
+
+Refer: https://github.com/rdkcentral/entservices-peripherals/blob/develop/.github/instructions/Plugincmake.instructions.md#namespace-usage
+
+Refer: https://github.com/rdkcentral/entservices-peripherals/blob/develop/.github/instructions/PluginOnboardingCompliance.instructions.md#coverity-scan-inclusion-and-test-workflow-updates-for-new-plugins

.github/instructions/Plugin.instructions.md

@@ -0,0 +1,203 @@
+---
+description: Guidelines for C++ files and header files that share the same name as their parent folder.
+applyTo: "**/*.cpp,**/*.h"
+---
+
+# Instructions summary
+  1. [Interface Implementation](https://github.com/rdkcentral/entservices-peripherals/blob/develop/.github/instructions/Plugin.instructions.md#interface-implementation)
+  2. [Service Registration](https://github.com/rdkcentral/entservices-peripherals/blob/develop/.github/instructions/Plugin.instructions.md#service-registration)
+  3. [JSON-RPC Stub Registration](https://github.com/rdkcentral/entservices-peripherals/blob/develop/.github/instructions/Plugin.instructions.md#json-rpc-stub-registration)
+  4. [Handling Out-of-Process Plugin Failures](https://github.com/rdkcentral/entservices-peripherals/blob/develop/.github/instructions/Plugin.instructions.md#handling-out-of-process-plugin-failures)
+
+### Interface Implementation
+
+### Requirement
+
+Each plugin must implement the appropriate Thunder interfaces.
+
+-> PluginHost::IPlugin – Mandatory for all plugins.
+
+-> PluginHost::IDispatcher or derive from PluginHost::JSONRPC – Mandatory If the plugin handles JSON-RPC.
+
+-> Custom interfaces (like IHdcpProfile for HdcpProfile plugin) must be added to ThunderInterfaces for RPC.
+
+-> PluginHost::IWeb – If the plugin handles web requests.
+
+
+### Example
+
+```cpp
+BEGIN_INTERFACE_MAP(HdcpProfile)
+    INTERFACE_ENTRY(PluginHost::IPlugin)
+    INTERFACE_ENTRY(PluginHost::IDispatcher)
+    INTERFACE_AGGREGATE(Exchange::IHdcpProfile, _hdcpProfile)
+END_INTERFACE_MAP
+```
+
+### Service Registration
+
+### Requirement
+
+All Thunder services must be registered using the SERVICE_REGISTRATION macro with name, major, minor and patch versions of service. Register the service using the following macro:
+
+```
+SERVICE_REGISTRATION(ServiceName, MAJOR, MINOR, PATCH)
+```
+
+For better readability, it is always good to define the following plugin metadata which is not mandatory:
+
+- **Precondition** - List of Thunder subsystems that must be active in order for the plugin to activate. This can also be set in Plugin.conf.in file.
+
+- **Terminations** - List of Thunder subsystems that will cause the plugin to deactivate if they are marked inactive whilst the plugin is running.
+
+- **Controls** - List of the subsystems that are controlled by the plugin.
+
+### Example
+
+```cpp
+namespace WPEFramework {
+    namespace {
+        static Plugin::Metadata<Plugin::HdcpProfile> metadata(
+            API_VERSION_NUMBER_MAJOR,
+            API_VERSION_NUMBER_MINOR,
+            API_VERSION_NUMBER_PATCH,
+            {}, // Preconditions
+            {}, // Terminations
+            {}  // Controls
+        );
+    }
+
+    namespace Plugin {
+        // Register HdcpProfile service with Thunder
+        SERVICE_REGISTRATION(HdcpProfile,API_VERSION_NUMBER_MAJOR,API_VERSION_NUMBER_MINOR,API_VERSION_NUMBER_PATCH);
+    }
+}
+```
+
+### JSON-RPC Stub Registration
+
+### Requirement
+
+If the plugin includes <interfaces/IPluginName*.h>, <interfaces/JsonData_PluginName.h>, and <interfaces/JPluginName.h> and inherits from PluginHost::JsonRPC, then it provides JSON‑RPC support and uses autogenerated JSON‑RPC stubs.
+
+These autogenerated stubs are the Exchange::J* C++ classes (for example, Exchange::JHdcpProfile and JsonData_HdcpProfile.h) that are produced by the Thunder JSON‑RPC code generator from the IPluginName* interface headers; they expose the C++ interface over JSON‑RPC so you do not have to call Register() for each method manually.
+
+Plugins using autogenerated JSON-RPC stubs (Exchange::J* classes) must register and unregister them in Initialize() and Deinitialize() methods.It should not be done in constructor and destructor.
+
+In Initialize():
+
+```cpp
+Exchange::JHdcpProfile::Register(*this, _hdcpProfile);
+```
+
+In Deinitialize():
+
+```cpp
+Exchange::JHdcpProfile::Unregister(*this);
+```
+
+It is strongly recommended to use the autogenerated JSON-RPC stubs rather than registering the json-rpc methods manually as below.
+
+```cpp
+RDKShell::RDKShell()
+    ...
+{
+    .....
+    Register(RDKSHELL_METHOD_MOVE_TO_FRONT, &RDKShell::moveToFrontWrapper, this);
+    Register(RDKSHELL_METHOD_MOVE_TO_BACK, &RDKShell::moveToBackWrapper, this);
+    ...
+}
+```
+
+### Handling Out-of-Process Plugin Failures
+
+### Requirement
+
+-  If the plugin runs as out-of-process, then it should implement RPC::IRemoteConnection::INotification interface inside your plugin.
+
+### Example
+
+```cpp
+class TestPlugin : public PluginHost::IPlugin, public PluginHost::JSONRPC {
+private:
+    class Notification : public RPC::IRemoteConnection::INotification {
+    public:
+        explicit Notification(TestPlugin* parent)
+            : _parent(*parent)
+        {
+            ASSERT(parent != nullptr);
+        }
+
+        ~Notification() override = default;
+
+        Notification(Notification&&) = delete;
+        Notification(const Notification&) = delete;
+        Notification& operator=(Notification&&) = delete;
+        Notification& operator=(const Notification&) = delete;
+
+    public:
+        void Activated(RPC::IRemoteConnection* /* connection */) override
+        {
+        }
+        void Deactivated(RPC::IRemoteConnection* connection) override
+        {
+            _parent.Deactivated(connection);
+        }
+
+        BEGIN_INTERFACE_MAP(Notification)
+        INTERFACE_ENTRY(RPC::IRemoteConnection::INotification)
+        END_INTERFACE_MAP
+
+    private:
+        TestPlugin& _parent;
+    };
+
+public:
+    TestPlugin()
+        : _connectionId(0)
+        , _service(nullptr)
+        , _testPlugin(nullptr)
+        , _notification(this)
+    {
+    }
+    ~TestPlugin() override = default;
+
+    TestPlugin(TestPlugin&&) = delete;
+    TestPlugin(const TestPlugin&) = delete;
+    TestPlugin& operator=(TestPlugin&&) = delete;
+    TestPlugin& operator=(const TestPlugin&) = delete;
+
+    BEGIN_INTERFACE_MAP(TestPlugin)
+    INTERFACE_ENTRY(PluginHost::IPlugin)
+    INTERFACE_ENTRY(PluginHost::IDispatcher)
+    INTERFACE_AGGREGATE(Exchange::ITestPlugin, _testPlugin)
+    END_INTERFACE_MAP
+
+public:
+    // IPlugin methods
+    const string Initialize(PluginHost::IShell* service) override;
+    void Deinitialize(PluginHost::IShell* service) override;
+    string Information() const override;
+
+private:
+    void Deactivated(RPC::IRemoteConnection* connection);
+
+private:
+    uint32_t _connectionId;
+    PluginHost::IShell* _service;
+    Exchange::ITestPlugin* _testPlugin;
+    Core::Sink<Notification> _notification;
+};
+```
+
+- It should be registered during Initialize() to get itself notified when the remote process connects or disconnects.
+
+### Example
+
+```cpp
+const string TestPlugin::Initialize(PluginHost::IShell* service)
+{
+    // Register for COM-RPC connection/disconnection notifications
+    _service->Register(&_notification);
+}
+```

.github/instructions/PluginOnboardingCompliance.instructions.md

@@ -0,0 +1,67 @@
+---
+applyTo: "CMakeLists.txt"
+---
+
+## Requirement
+
+### Coverity Scan Inclusion and Test Workflow Updates for New Plugins
+
+When adding a new plugin in `CMakeLists.txt`, you **must** also update the following to guarantee the plugin is included in all required test and Coverity analysis workflows:
+
+- **CI Workflow Files:**  
+  - `L1-tests.yml`
+  - `L2-tests.yml`
+  - `L2-tests-oop.yml`
+- **Coverity Build Script:**  
+  - `cov_build.sh`
+
+**Example:**
+
+1. **CMake Plugin Registration Example**
+
+   If you add your plugin in `CMakeLists.txt` as:
+   ```cmake
+   if (PLUGIN_RESOURCEMANAGER)
+       add_subdirectory(ResourceManager)
+   endif()
+   if (PLUGIN_MY_NEW_PLUGIN)
+       add_subdirectory(MyNewPlugin)
+   endif()
+   ```
+2. **Update Coverity Build Script**
+
+   Add your plugin’s flag in the build command in `cov_build.sh`:
+   ```bash
+   cmake \
+       -DPLUGIN_CORE=ON \
+       -DPLUGIN_LEGACY=ON \
+       # <-- NEW PLUGIN FLAG
+       -DPLUGIN_MY_NEW_PLUGIN=ON \
+       .
+   ```
+   This ensures Coverity runs on your new plugin.
+
+3. **Update Test Workflow YAMLs**
+
+   Ensure each test workflow references your new plugin using the **DPLUGIN_<PLUGINNAME>** CMake flag in their build/test step. For example, in `L1-tests.yml`:
+   ```yaml
+   jobs:
+     build-test:
+       runs-on: ubuntu-22.04
+       steps:
+         - name: Configure with new plugin
+           run: |
+             cmake \
+               -DPLUGIN_CORE=ON \
+               -DPLUGIN_MY_NEW_PLUGIN=ON \
+               .
+         - name: Run tests
+           run: |
+             ctest
+   ```
+   Repeat similar additions in `L2-tests.yml` and `L2-tests-oop.yml`.
+
+**Summary:**  
+Whenever a new plugin is registered via `CMakeLists.txt`, always update:
+- `cov_build.sh` (add plugin flag to Coverity scan build step)
+- All test CI workflows (`L1-tests.yml`, `L2-tests.yml`, `L2-tests-oop.yml`) to include your plugin flag so that your plugin’s code quality and tests are assured!

.github/instructions/Plugincmake.instructions.md

@@ -0,0 +1,44 @@
+---
+applyTo: "**/CMakeLists.txt"
+---
+
+### NAMESPACE Usage
+
+### Requirement
+
+All CMake targets, install paths, export sets,find_package and references must use the ${NAMESPACE} variable instead of hardcoded framework names (e.g., WPEFrameworkCore, WPEFrameworkPlugins).
+This ensures smooth upgrades (e.g., WPEFramework → Thunder) and prevents regressions.
+
+### Correct Example
+
+```cmake
+set(MODULE_NAME ${NAMESPACE}${PLUGIN_NAME})
+
+find_package(${NAMESPACE}Plugins REQUIRED)
+
+find_package(${NAMESPACE}Definitions REQUIRED)
+
+target_link_libraries(${MODULE_NAME} 
+    PRIVATE
+    CompileSettingsDebug::CompileSettingsDebug
+    ${NAMESPACE}Plugins::${NAMESPACE}Plugins
+    ${NAMESPACE}Definitions::${NAMESPACE}Definitions)
+```
+
+
+### Incorrect Example
+
+```cmake
+set(MODULE_NAME WPEFramework${PLUGIN_NAME})
+
+find_package(WPEFrameworkPlugins REQUIRED)
+
+find_package(WPEFrameworkDefinitions REQUIRED)
+
+target_link_libraries(${MODULE_NAME} 
+    PRIVATE
+    CompileSettingsDebug::CompileSettingsDebug
+    WPEFrameworkPlugins::WPEFrameworkPlugins
+    WPEFrameworkDefinitions::WPEFrameworkDefinitions)
+```
+

.github/instructions/Pluginconfig.instructions.md

@@ -0,0 +1,49 @@
+---
+applyTo: "**/*.config,**/*.conf.in"
+---
+
+### Plugin Configuration
+
+### Requirement
+
+- Each plugin must define <PluginName>.conf.in file that includes the following mandatory properties:
+
+  - **autostart**: Indicates whether the plugin should start automatically when the framework boots. This should be set to false by default.
+
+  - **callsign**: A unique identifier used to reference the plugin within the framework. Every callsign must be defined with a prefix of org.rdk and it must be followed by the ENT Service name written in PascalCase (e.g., org.rdk.PersistentStore).
+
+  - **Custom properties**: Any additional configuration parameters required by the plugin. These are passed during activation via PluginHost::IShell::ConfigLine(). The following structural configuration elements are commonly defined:
+      - startuporder - Specifies the order in which plugins are started, relative to others.
+      - precondition - If these aren't met, the plugin stays in the Preconditions state and activates automatically once they are satisfied. It is recommended to define the precondition if the plugin depends on other subsystems being active.
+      - mode - Defines the execution mode of the plugin.
+
+### Plugin Mode Determination
+
+If the plugin's mode is set to OFF, it is treated as in-process.
+
+If no mode is specified, the plugin defaults to in-process.
+
+If the mode is explicitly set to LOCAL, the plugin runs out-of-process.
+
+The plugin mode is configured in the plugin's CMakeLists.txt file.
+
+- **locator** - Update with the name of the library (.so) that contains the actual plugin Implementation code.
+
+### Example
+
+<PluginName>.conf.in
+
+```
+precondition = ["Platform"]
+callsign = "org.rdk.HdcpProfile"
+autostart = "@PLUGIN_HDCPPROFILE_AUTOSTART@"
+startuporder = "@PLUGIN_HDCPPROFILE_STARTUPORDER@"
+
+configuration = JSON()
+rootobject = JSON()
+
+rootobject.add("mode", "@PLUGIN_HDCPPROFILE_MODE@")
+rootobject.add("locator", "lib@[email protected]")
+
+configuration.add("root", rootobject)
+```