RDKEMW-11903: Add custom coding guidelines for entservices-repos

Reason for change: To enhance copilot reviews using repo specific guidelines

Test Procedure:NA

Risks: Low

version: Patch

Signed-off-by: Soundaryaa [email protected]

Author: ssitar583

.github/instructions/Plugin.instructions.md

@@ -4,10 +4,10 @@ applyTo: "**/*.cpp,**/*.h"
 ---
 
 # Instructions summary
-  1. [Interface Implementation](https://github.com/rdkcentral/entservices-softwareupdate/blob/develop/.github/instructions/Plugin.instructions.md#interface-implementation)
-  2. [Service Registration](https://github.com/rdkcentral/entservices-softwareupdate/blob/develop/.github/instructions/Plugin.instructions.md#service-registration)
-  3. [JSON-RPC Stub Registration](https://github.com/rdkcentral/entservices-softwareupdate/blob/develop/.github/instructions/Plugin.instructions.md#json-rpc-stub-registration)
-  4. [Handling Out-of-Process Plugin Failures](https://github.com/rdkcentral/entservices-softwareupdate/blob/develop/.github/instructions/Plugin.instructions.md#handling-out-of-process-plugin-failures)
+  1. [Interface Implementation](#interface-implementation)
+  2. [Service Registration](#service-registration)
+  3. [JSON-RPC Stub Registration](#json-rpc-stub-registration)
+  4. [Handling Out-of-Process Plugin Failures](#handling-out-of-process-plugin-failures)
 
 ### Interface Implementation
 
@@ -82,7 +82,7 @@ If the plugin includes <interfaces/IPluginName*.h>, <interfaces/JsonData_PluginN
 
 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.
+Plugins using autogenerated JSON-RPC stubs (Exchange::J* classes) must register and unregister them in Initialize() and Deinitialize() methods. Do not register or unregister them in the constructor or destructor.
 
 In Initialize():
 
@@ -113,7 +113,7 @@ RDKShell::RDKShell()
 
 ### Requirement
 
-- If the plugin runs as out-of-process, then it should implement RPC::IRemoteConnection::"INotification interface inside your plugin.
+- If the plugin runs as out-of-process, then it should implement RPC::IRemoteConnection::INotification interface inside your plugin.
 
 ### Example
 

.github/instructions/Pluginconfig.instructions.md

@@ -1,20 +1,20 @@
 ---
-applyTo: "**/*.config,**/*.conf.in"
+applyTo: "**/*.conf.in"
 ---
 
 ### Plugin Configuration
 
 ### Requirement
 
-- Each plugin must define <PluginName>.conf.in file that includes the following mandatory properties:
+- Each plugin must define a <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.
+      - precondition - If these preconditions 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

.github/instructions/Pluginimplementation.instructions.md

@@ -26,7 +26,7 @@ QueryInterface:
 _userSettingsPlugin = _service->QueryInterface<WPEFramework::Exchange::IUserSettings>();
 ```
 
-SHOULD not use JSON-RPC or LinkType for inter-plugin communication, as they introduce unnecessary overhead.
+should not use JSON-RPC or LinkType for inter-plugin communication, as they introduce unnecessary overhead.
 
 ### Incorrect Example
 
@@ -151,7 +151,7 @@ void RegisterWithTarget(const string& callsign, PluginHost::IShell* plugin) {
 }
 ```
 
-If the notifying plugin supports only JSON-RPC, then use a specialized smart link type when subscribing to its events. This method allows the framework to efficiently handle Plugin statechange events.
+If the notifying plugin supports only JSON-RPC, then use a specialized smart link type when subscribing to its events. This method allows the framework to efficiently handle Plugin state change events.
 
 ### Example
 

.github/instructions/Pluginlifecycle.instructions.md

@@ -33,7 +33,7 @@ const string HdcpProfile::Initialize(PluginHost::IShell* service) {
 }
 ```
 
-- Plugin should register your listener object twice:
+- The plugin should register its listener object twice:
 
   - Framework Service (_service): Use _service->Register(listener) to receive general plugin state change notifications (like ACTIVATED/DEACTIVATED).
 
@@ -252,7 +252,7 @@ void HdcpProfile::Deinitialize(PluginHost::IShell* service) {
 
 ### Deactivated
 
-Each plugin should implement the deactivated method. In Deactivated, it should be checked if remote connectionId matches your plugin's connectionId. If it matches your plugin's connectionId, the plugin should submit a deactivation job to handle the out-of-process failure gracefully.
+Each plugin should implement the Deactivated method. In Deactivated, it should be checked if remote connectionId matches your plugin's connectionId. If it matches your plugin's connectionId, the plugin should submit a deactivation job to handle the out-of-process failure gracefully.
 
 ### Example