Custom-laget bestaar nu begge CI-checks: 72 validator-fejl -> 0

Normalisering af alle 39 custom knowledge-filer til READ-kontraktens
skema (validate_frontmatter.py + Test-KnowledgeIndex.ps1 begge groenne):

- R01/R02: 28 filer manglede frontmatter eller brugte aeldre skemaer
  (title/category/severity/rule-id m.fl.) - alle har nu praecis de 6
  kraevede noegler; keywords haandskrevet pr. fil da de driver
  worklist-selektionen i INDEX/knowledge-index
- R09: manglende Description-sektion - regel-agtige foersteoverskrifter
  (Core Rule/Rule/Regel/Core Principle) omdoebt, eller sektion indsat
  efter titlen hvor intro-tekst fandtes
- R10: fenced code blocks konverteret til 4-space indrykkede blokke
  i alle filer (indhold uaendret)
- R11: 4 filer over 100 linjer fortaettet redaktionelt uden semantisk
  tab (ai-eval-scores 143->100, git-lifecycle 121->97,
  permission-sets 113->99, test-feature-scenario-tags 105->91)
- R05: AL0197->al0197, add_repo->add-repo; keyword-lister trimmet
  til maks 10

Ingen regler er fjernet eller aendret i betydning - kun form.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

custom/knowledge/mcp/api-page-least-privilege-write-access.md

@@ -1,6 +1,14 @@
+---
+bc-version: [all]
+domain: mcp
+keywords: [api-page, least-privilege, write-access, odata, security]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+---
 # CURABIS MCP: API Pages Must Use Least-Privilege Write Access
 
-## Core Principle
+## Description
 
 A general-purpose API page that exposes many fields should not be widened to allow writes on a single additional field. Instead, create a dedicated minimal API page that exposes only the fields the consumer needs to read and write. This limits the blast radius of any agent or integration mistake.
 
@@ -10,26 +18,22 @@ An MCP agent operates with the permissions of its service identity, not an indiv
 
 ## Pattern to Avoid
 
-```al
-// WRONG: General page widened with write access to one field
-// Now the agent can accidentally (or intentionally) write to all other fields too
-field(status; Rec.Status) { }                          // should be read-only
-field(gitHubRepository; Rec."GitHub Repository") { }   // the one field we want writable
-field(estimatedHours; Rec."Estimated Hours") { }        // should be read-only
-```
+    // WRONG: General page widened with write access to one field
+    // Now the agent can accidentally (or intentionally) write to all other fields too
+    field(status; Rec.Status) { }                          // should be read-only
+    field(gitHubRepository; Rec."GitHub Repository") { }   // the one field we want writable
+    field(estimatedHours; Rec."Estimated Hours") { }        // should be read-only
 
 ## Correct Pattern
 
 Create a separate, minimal API page:
 
-```al
-page 6102904 "CUR MCP Project Repository"
-{
-    // Only two fields: the key and the one writable field
-    field(no; Rec."No.") { Editable = false; }
-    field(gitHubRepository; Rec."GitHub Repository") { }
-}
-```
+    page 6102904 "CUR MCP Project Repository"
+    {
+        // Only two fields: the key and the one writable field
+        field(no; Rec."No.") { Editable = false; }
+        field(gitHubRepository; Rec."GitHub Repository") { }
+    }
 
 ## Requirements