Add knowledge-backed AL development

Add read-only planning and repository-changing development skills so BCQuality
knowledge can guide features, bug fixes, refactors, upgrades, and maintenance
before the existing AL review gate runs. Track Microsoft Learn ingestion and
add development and BCApps-shaped guidance evaluation fixtures.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 638b66d2-9f06-4f60-8781-808709e1485c

microsoft/knowledge/ui/dropdown-fieldgroup-respects-lookup-page-visibility.bad.al

@@ -0,0 +1,9 @@
+tableextension 50622 "Ship-to Dropdown Bad" extends "Ship-to Address"
+{
+    fieldgroups
+    {
+        addlast(DropDown; "Address 2")
+        {
+        }
+    }
+}

microsoft/knowledge/ui/dropdown-fieldgroup-respects-lookup-page-visibility.good.al

@@ -0,0 +1,20 @@
+tableextension 50620 "Ship-to Dropdown Good" extends "Ship-to Address"
+{
+    fieldgroups
+    {
+        addlast(DropDown; "Address 2")
+        {
+        }
+    }
+}
+
+pageextension 50621 "Ship-to Lookup Good" extends "Ship-to Address List"
+{
+    layout
+    {
+        modify("Address 2")
+        {
+            Visible = true;
+        }
+    }
+}

microsoft/knowledge/ui/dropdown-fieldgroup-respects-lookup-page-visibility.md

@@ -0,0 +1,30 @@
+---
+bc-version: [all]
+domain: ui
+keywords: [fieldgroup, dropdown, addlast, lookup-page, visible, tableextension, pageextension]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+---
+
+# A `DropDown` field remains hidden when its lookup-page control is hidden
+
+## Description
+
+A tableextension can append a field to the `DropDown` field group with `addlast`, but the client still omits that field when its control on the underlying lookup page has `Visible = false`. Changing only the table field group therefore compiles while producing no visible UI change. The field-group name is case-sensitive and must be written as `DropDown`.
+
+## Best Practice
+
+When adding a hidden field to a `DropDown` field group, also extend the page used for the lookup and make that field control visible. Verify the actual lookup page rather than assuming the table definition alone controls the drop-down.
+
+See sample: `dropdown-fieldgroup-respects-lookup-page-visibility.good.al`.
+
+## Anti Pattern
+
+Adding the field with `addlast(DropDown; ...)` while leaving its lookup-page control hidden, then expecting the field to appear in the drop-down.
+
+See sample: `dropdown-fieldgroup-respects-lookup-page-visibility.bad.al`.
+
+## Reference
+
+[Add a new FieldGroup to an existing table](https://learn.microsoft.com/en-us/training/modules/extend-modify-existing-table/add-field-group)

microsoft/knowledge/ui/updatepropagation-both-refreshes-main-page.bad.al

@@ -0,0 +1,26 @@
+page 50631 "Sample Order Bad"
+{
+    PageType = Document;
+    SourceTable = "Sales Header";
+
+    layout
+    {
+        area(Content)
+        {
+            group(General)
+            {
+                field(Amount; Rec.Amount)
+                {
+                    ApplicationArea = All;
+                    ToolTip = 'Specifies the total amount of the order.';
+                }
+            }
+            part(Lines; "Sales Order Subform")
+            {
+                ApplicationArea = All;
+                SubPageLink = "Document Type" = field("Document Type"),
+                              "Document No." = field("No.");
+            }
+        }
+    }
+}

microsoft/knowledge/ui/updatepropagation-both-refreshes-main-page.good.al

@@ -0,0 +1,27 @@
+page 50630 "Sample Order Good"
+{
+    PageType = Document;
+    SourceTable = "Sales Header";
+
+    layout
+    {
+        area(Content)
+        {
+            group(General)
+            {
+                field(Amount; Rec.Amount)
+                {
+                    ApplicationArea = All;
+                    ToolTip = 'Specifies the total amount of the order.';
+                }
+            }
+            part(Lines; "Sales Order Subform")
+            {
+                ApplicationArea = All;
+                SubPageLink = "Document Type" = field("Document Type"),
+                              "Document No." = field("No.");
+                UpdatePropagation = Both;
+            }
+        }
+    }
+}

microsoft/knowledge/ui/updatepropagation-both-refreshes-main-page.md

@@ -0,0 +1,30 @@
+---
+bc-version: [all]
+domain: ui
+keywords: [updatepropagation, page-part, subpage, main-page, refresh, flowfield, document-lines]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+---
+
+# Use `UpdatePropagation = Both` when line edits must refresh the main page
+
+## Description
+
+A page part does not automatically refresh its parent page when the subpage changes. `UpdatePropagation = Subpage` updates only the part; `Both` also refreshes the main page. Without `Both`, header totals, FlowFields, and FactBoxes that depend on edited lines can remain stale until another user action refreshes the page.
+
+## Best Practice
+
+Set `UpdatePropagation = Both` on a part when edits in that subpage must immediately update values rendered by the main page. Leave propagation at `Subpage` when the parent has no dependent presentation to avoid unnecessary refreshes.
+
+See sample: `updatepropagation-both-refreshes-main-page.good.al`.
+
+## Anti Pattern
+
+Displaying a line-dependent total on the main page while the editable lines part updates only itself. The persisted values can be correct while the parent page continues to show an old total.
+
+See sample: `updatepropagation-both-refreshes-main-page.bad.al`.
+
+## Reference
+
+[Set different control properties](https://learn.microsoft.com/en-us/training/modules/work-with-pages/8-controls)