chore: refine GH copilot instructions

Signed-off-by: Jérôme Benoit <jerome.benoit@sap.com>

diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
index 662ed99ec27e0a32606b609df0d00de6be0dcbc4..9b0ad1d8c6b1021e4383e4c2bd802914fa8aa174 100644 (file)
--- a/.github/copilot-instructions.md
+++ b/.github/copilot-instructions.md
@@ -92,11 +92,12 @@ Documentation serves as an operational specification, not narrative prose.
 ## OCPP-specific conventions
 
 - **Command naming**: Follow OCPP standard naming exactly (e.g., RemoteStartTransaction, BootNotification, StatusNotification).
+- **Enumeration naming**: Use standard OCPP specifications enumeration names and values exactly (e.g., ConnectorStatusEnumType with values Available, Occupied). Avoid string literals when an enumeration exists.
 - **Version handling**: Clearly distinguish between OCPP 1.6 and 2.0.x implementations in separate namespaces/files.
 - **Payload validation**: Validate against OCPP JSON schemas when ocppStrictCompliance is enabled.
 - **Message format**: Use standard SRPC format: [messageTypeId, messageId, action, payload] or [messageTypeId, messageId, payload].
 - **UUID tracking**: Use UUIDs to correlate requests with responses; store pending operations in Maps with UUID keys.
-- **Response handling**: Wait for all expected responses before resolving broadcast requests.
+- **Response handling**: Ensure to wait for all expected responses before resolving broadcast requests.
 
 ## Quality gates