Add CMFRT coding standards documentation and examples

- Introduced guidelines for "one codeunit one global function" architecture to enforce single responsibility in AL code.
- Added best practices and anti-patterns for adding parameters via overloads to maintain backward compatibility.
- Documented the importance of never deleting members in AL and always marking them as obsolete.
- Established the requirement for OnBefore and OnAfter integration events for global procedures to enhance extensibility.
- Defined naming conventions for CMFRT objects, including prefixes and object ID ranges to avoid conflicts.
- Implemented patterns for case statements to ensure all cases are handled, including the necessity of an else clause.
- Introduced the interface injection pattern to allow pluggable operations in table-level code.
- Recommended using Confirm Management for user confirmations to improve testability.
- Established a three-permission set pattern for security to ensure proper access control.
- Created a review skill for CMFRT AL standards to automate compliance checks against established guidelines.

custom/knowledge/security/cmfrt-three-permissionset-pattern.bad.al

@@ -0,0 +1,16 @@
+// Only one flat permission set — no composition, no read-only role.
+// Adding a new table means updating this one set and hoping nothing was missed.
+permissionset 2045222 "CMFRT GD Geodynamics"
+{
+    Assignable = true;
+    Caption = 'CMFRT GD Geodynamics';
+    Permissions =
+        table "CMFRT GD POI" = X,
+        tabledata "CMFRT GD POI" = RIMD,
+        table "CMFRT GD Setup" = X,
+        tabledata "CMFRT GD Setup" = RIMD,
+        page "CMFRT GD POI" = X,
+        page "CMFRT GD Setup" = X,
+        codeunit "CMFRT GD IGeodynamics" = X,
+        codeunit "CMFRT GD IGeodynamics Impl" = X;
+}

custom/knowledge/security/cmfrt-three-permissionset-pattern.good.al

@@ -0,0 +1,35 @@
+// Step 1: Objects set — owns all AL objects with execute access.
+permissionset 2045222 "CMFRT GD Objects"
+{
+    Assignable = true;
+    Caption = 'CMFRT GD Geodynamics - Objects';
+    Permissions =
+        table "CMFRT GD POI" = X,
+        table "CMFRT GD Setup" = X,
+        page "CMFRT GD POI" = X,
+        page "CMFRT GD Setup" = X,
+        codeunit "CMFRT GD IGeodynamics" = X,
+        codeunit "CMFRT GD IGeodynamics Impl" = X;
+}
+
+// Step 2: Read set — inherits object access, adds tabledata read.
+permissionset 2045221 "CMFRT GD Read"
+{
+    Assignable = true;
+    Caption = 'CMFRT GD Geodynamics - Read';
+    IncludedPermissionSets = "CMFRT GD Objects";
+    Permissions =
+        tabledata "CMFRT GD POI" = R,
+        tabledata "CMFRT GD Setup" = R;
+}
+
+// Step 3: Edit set — inherits Read, adds insert/modify/delete.
+permissionset 2045226 "CMFRT GD Edit"
+{
+    Assignable = true;
+    Caption = 'CMFRT GD Geodynamics - Edit';
+    IncludedPermissionSets = "CMFRT GD Read";
+    Permissions =
+        tabledata "CMFRT GD POI" = IMD,
+        tabledata "CMFRT GD Setup" = IMD;
+}

custom/knowledge/security/cmfrt-three-permissionset-pattern.md

@@ -0,0 +1,26 @@
+---
+bc-version: [all]
+domain: security
+keywords: [permissionset, permission-set, objects, read, edit, assignable, included-permission-sets, authorization]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+---
+
+# CMFRT three-permission-set pattern
+
+## Description
+
+Every CMFRT functional module must ship exactly three permission set objects: an Objects set, a Read set, and an Edit set. The Objects set lists every AL object the module owns — tables, pages, codeunits, reports, interfaces — with `X` (execute) access. The Read set includes the Objects set via `IncludedPermissionSets` and grants `tabledata = R` on each table. The Edit set includes the Read set and grants `tabledata = IMD` on each writable table. All three sets have `Assignable = true`. Names follow the pattern `"CMFRT <ABBR> Objects"`, `"CMFRT <ABBR> Read"`, and `"CMFRT <ABBR> Edit"`.
+
+## Best Practice
+
+Define the sets in the strict composition chain Objects ← Read ← Edit so that object access is declared once and inherited. When a new table is added to the module, update the Objects set and the tabledata entries in Read and Edit — there is no risk of the object access drifting between roles because the chain is the single source of truth for it.
+
+See sample: `cmfrt-three-permissionset-pattern.good.al`.
+
+## Anti Pattern
+
+Shipping fewer than three permission sets, omitting `IncludedPermissionSets` and enumerating the same object list in each set by hand, or granting `RIMD` access in a flat set that cannot be composed. Flat role sets that enumerate objects independently drift apart when tables are added or removed, and the resulting authorization gap is invisible until a user reports an access error in production.
+
+See sample: `cmfrt-three-permissionset-pattern.bad.al`.