Complete AL review knowledge readiness (#108)

* Complete AL review knowledge readiness

Fill telemetry and Query coverage, strengthen thin review domains, correct audited content defects, and add deterministic cheap-model evaluation and reference-integrity safeguards.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 9825b012-e653-496a-9310-c1f4b6f8ac27

* Generalize review fixture discovery

Derive smoke cases from the leaf, domain, and paired-sample conventions so new leaves require no scoring-contract changes. Keep only exceptional selection/context overrides and fail when retrieval metadata cannot rank the selected article.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 9825b012-e653-496a-9310-c1f4b6f8ac27

* Preserve published field IDs in sample

Keep the existing Email and Contact Email field IDs unchanged, clarify that the sample represents an independent baseline, and use a local breaking-change rule for the generic smoke evaluation.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 9825b012-e653-496a-9310-c1f4b6f8ac27

* Clarify published field identity rules

State explicitly that a published field keeps its ID, name, and type while a replacement is added as a separate field under an unused ID.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 9825b012-e653-496a-9310-c1f4b6f8ac27

* Align field obsoletion sample baselines

Use Email field ID 3 as the shared baseline so the bad example demonstrates a same-ID rename while the good example retains the original field and adds a separate replacement.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 9825b012-e653-496a-9310-c1f4b6f8ac27

---------

Co-authored-by: Jesper Schulz-Wedde <jesper.schulzwedde@microsoft.com>

microsoft/knowledge/breaking-changes/namespace-is-part-of-published-object-identity.bad.al

@@ -0,0 +1,9 @@
+// This published object previously used namespace Contoso.Rentals.
+namespace Contoso.RentalManagement;
+
+codeunit 50467 "Rental Agreement Mgt."
+{
+    procedure CreateAgreement()
+    begin
+    end;
+}

microsoft/knowledge/breaking-changes/namespace-is-part-of-published-object-identity.good.al

@@ -0,0 +1,8 @@
+namespace Contoso.Rentals;
+
+codeunit 50466 "Rental Agreement Mgt."
+{
+    procedure CreateAgreement()
+    begin
+    end;
+}

microsoft/knowledge/breaking-changes/namespace-is-part-of-published-object-identity.md

@@ -0,0 +1,26 @@
+---
+bc-version: [23..]
+domain: breaking-changes
+keywords: [namespace, published-object, dependency, breaking-change, as0007, compile-time-identity]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+---
+
+# Treat a published namespace as part of object identity
+
+## Description
+
+AL resolves an object by namespace and name. Once an app ships and dependent extensions compile against that identity, changing the namespace breaks their references even when the object name and ID stay unchanged. AppSourceCop AS0007 rejects changing the namespace of published objects; namespaces are therefore not a cosmetic folder-like label that can be reorganized after release.
+
+## Best Practice
+
+Choose a globally meaningful namespace before first publication and keep it stable. Add new functional areas beneath that structure without moving existing published objects. If an identity must move, use the platform's supported move/obsoletion lifecycle rather than a source-only namespace rename.
+
+See sample: `namespace-is-part-of-published-object-identity.good.al`.
+
+## Anti Pattern
+
+Changing `namespace Contoso.Rentals;` to `namespace Contoso.RentalManagement;` as a cleanup while leaving the object name and ID untouched. Every dependent `using` directive and qualified reference targets the old identity and stops compiling.
+
+See sample: `namespace-is-part-of-published-object-identity.bad.al`.

microsoft/knowledge/breaking-changes/obsolete-table-fields-instead-of-deleting-them.bad.al

@@ -3,9 +3,10 @@ table 50311 "Customer Profile Bad"
     fields
     {
         field(1; "No."; Code[20]) { }
-        // Breaking: the published field was renamed while retaining ID 2.
+        // Breaking: the published Email field at ID 3 was renamed while retaining
+        // the ID. The good example keeps Email at ID 3 and adds a separate field.
         // AppSourceCop AS0005 rejects the compatibility change; retaining the ID
         // does not by itself mean the stored column was dropped and re-created.
-        field(2; "Contact Email"; Text[80]) { }
+        field(3; "Contact Email"; Text[80]) { }
     }
 }

microsoft/knowledge/breaking-changes/obsolete-table-fields-instead-of-deleting-them.good.al

@@ -3,10 +3,10 @@ table 50310 "Customer Profile Good"
     fields
     {
         field(1; "No."; Code[20]) { }
-        // Replacement field shipped alongside the old one.
+        // Replacement is a separate field under an otherwise unused ID.
         field(2; "Contact Email"; Text[80]) { }
-        // Old field kept and marked Pending so dependent code keeps compiling and
-        // an upgrade codeunit can copy its data before it is finally removed.
+        // Old field keeps its original ID, name, and type and is marked Pending so
+        // dependent code keeps compiling while an upgrade codeunit migrates its data.
         field(3; "Email"; Text[80])
         {
             ObsoleteState = Pending;

microsoft/knowledge/breaking-changes/obsolete-table-fields-instead-of-deleting-them.md

@@ -7,7 +7,7 @@ countries: [w1]
 application-area: [all]
 ---
 
-# Obsolete published table fields instead of deleting or renumbering them
+# Obsolete published table fields instead of deleting, renaming, or renumbering them
 
 ## Description
 
@@ -15,12 +15,12 @@ A shipped table field carries both a source-level contract and persisted data. R
 
 ## Best Practice
 
-Add the replacement field under a new ID, then mark the old field `ObsoleteState = Pending` with an `ObsoleteReason` that names the replacement and an `ObsoleteTag` recording the obsoletion version. Keep the old field readable so an upgrade codeunit can copy its data during the deprecation window. Move it to `ObsoleteState = Removed` only in a later release, after the window has passed and data has migrated.
+Keep the old field's ID, name, and type unchanged. Add the replacement as a separate field under an unused ID, then mark the old field `ObsoleteState = Pending` with an `ObsoleteReason` that names the replacement and an `ObsoleteTag` recording the obsoletion version. Keep the old field readable so an upgrade codeunit can copy its data during the deprecation window. Move it to `ObsoleteState = Removed` only in a later release, after the window has passed and data has migrated.
 
 See sample: `obsolete-table-fields-instead-of-deleting-them.good.al`.
 
 ## Anti Pattern
 
-Renaming published `Email` to `Contact Email` with the same ID violates the compatibility contract and AS0005, even though the retained ID does not itself imply a fresh empty column. Deleting `Email` or moving the replacement to another ID without migration additionally risks losing its stored values. Detection: a previously shipped field removed, renumbered, or renamed with no retained `Pending` field and migration path.
+Renaming published `Email` to `Contact Email` with the same ID violates the compatibility contract and AS0005, even though the retained ID does not itself imply a fresh empty column. Deleting `Email` or changing its ID additionally risks losing its stored values. Detection: any previously shipped field whose name changes at the same ID, or whose original ID disappears without the unchanged field being retained as `Pending` and its data migrated to a separate replacement field.
 
 See sample: `obsolete-table-fields-instead-of-deleting-them.bad.al`.