Add CMFRT naming conventions, object ID ranges, and patterns documentation

- Introduced guidelines for using the "CMFRT" prefix in object names, fields, and procedures to avoid naming collisions and ensure clarity.
- Established rules for object ID ranges to prevent conflicts with other extensions and maintain historical integrity.
- Documented best practices and anti-patterns for various coding patterns, including case statements, interface injection, label usage, and validation methods.
- Implemented a standards review skill to evaluate AL source changes against CMFRT company standards, ensuring compliance with naming, permissions, and architectural patterns.

custom/knowledge/breaking-changes/cmfrt-never-delete-always-obsolete.good.al

@@ -0,0 +1,23 @@
+// Obsoleted field kept at the end of the table — never deleted.
+table 2045085 "CMFRT GD Setup"
+{
+    fields
+    {
+        field(1; "Primary Key"; Code[10]) { DataClassification = SystemMetadata; }
+        field(2; "CMFRT GD ErrorPath"; Text[500])
+        {
+            Caption = 'Error Path';
+            DataClassification = CustomerContent;
+        }
+
+        // Obsolete section at the end — original field retained with state = Removed.
+        field(2045325; "CMFRT GD Error Path"; Text[200])
+        {
+            Caption = 'Error Path (Obsolete)';
+            DataClassification = CustomerContent;
+            ObsoleteState = Removed;
+            ObsoleteReason = 'Replaced by field "CMFRT GD ErrorPath" with extended length.';
+            ObsoleteTag = 'Task-29100';
+        }
+    }
+}