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

microsoft/knowledge/performance/hidden-flowfields-still-calculate-before-bc26-opt-in.bad.al

@@ -0,0 +1,18 @@
+pageextension 50445 "Customer Balance Hidden" extends "Customer Card"
+{
+    layout
+    {
+        addlast(General)
+        {
+            field(Balance; Rec.Balance)
+            {
+                ApplicationArea = All;
+                ToolTip = 'Specifies the customer balance.';
+                Visible = ShowBalance;
+            }
+        }
+    }
+
+    var
+        ShowBalance: Boolean;
+}

microsoft/knowledge/performance/hidden-flowfields-still-calculate-before-bc26-opt-in.good.al

@@ -0,0 +1,29 @@
+pageextension 50444 "Customer Balance Lazy" extends "Customer Card"
+{
+    layout
+    {
+        addlast(General)
+        {
+            field("Balance Preview"; BalancePreview)
+            {
+                ApplicationArea = All;
+                Caption = 'Balance Preview';
+                ToolTip = 'Specifies the balance when balance details are enabled.';
+                Visible = ShowBalance;
+            }
+        }
+    }
+
+    trigger OnAfterGetCurrRecord()
+    begin
+        Clear(BalancePreview);
+        if not ShowBalance then
+            exit;
+        Rec.CalcFields(Balance);
+        BalancePreview := Rec.Balance;
+    end;
+
+    var
+        BalancePreview: Decimal;
+        ShowBalance: Boolean;
+}

microsoft/knowledge/performance/hidden-flowfields-still-calculate-before-bc26-opt-in.md

@@ -0,0 +1,26 @@
+---
+bc-version: [all]
+domain: performance
+keywords: [flowfield, visible, page-control, calculate-only-visible-flowfields, feature-management, hidden-field]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+---
+
+# Hidden page FlowFields still calculate unless visible-only calculation is enabled
+
+## Description
+
+By default, a FlowField used directly as a page control's source is calculated when the page loads even when `Visible = false` or its visibility expression evaluates to false. The hidden control can therefore issue an aggregate query that no user sees. Business Central 26 introduced the **Calculate only visible FlowFields** feature-management option; only environments with that option enabled skip calculation for controls that are not visible.
+
+## Best Practice
+
+On BC 26 and later, enable and verify the visible-only FlowField feature before relying on `Visible` to suppress calculation. When the target environment does not guarantee that option, avoid binding an expensive FlowField directly to a usually-hidden control: calculate it only in the branch that displays it and bind the page control to a variable. Do not flag a hidden FlowField when the v26 feature is known to be enabled or the FlowField is cheap and intentionally preloaded.
+
+See sample: `hidden-flowfields-still-calculate-before-bc26-opt-in.good.al`.
+
+## Anti Pattern
+
+Adding a costly Sum or Lookup FlowField to a page with `Visible = SomeRareMode` and assuming the hidden state prevents its query on all supported versions. The review signal is the direct FlowField source plus conditional or false visibility, not visibility alone.
+
+See sample: `hidden-flowfields-still-calculate-before-bc26-opt-in.bad.al`.

microsoft/knowledge/performance/use-tryfunction-for-error-catching-not-rollback.md

@@ -11,11 +11,11 @@ application-area: [all]
 
 ## Description
 
-`[TryFunction]` annotates a method so that errors raised inside it can be caught by the caller instead of propagating. Per the platform reference, "changes to the database that are made with a try method aren't rolled back" — the attribute catches the error; it does not unwind database state. This is the critical distinction from `Codeunit.Run`, which does roll back on error (see `codeunit-run-as-atomic-sub-operation.md`). A try function also only catches when its return value is used: "If the return variable for a call to a function, which is attributed with [TryFunction] isn't used, then the call isn't considered a try function call." `DoTry();` propagates errors normally; only `ok := DoTry();` or `if DoTry() then ...` catches. The return type is forced to Boolean; user-defined return types are not allowed, and the value isn't accessible inside the try method itself. On Business Central on-premises, writes inside a try method are blocked by default and raise a runtime error unless `DisableWriteInsideTryFunctions` is set to `false` on the server — SaaS has no such restriction.
+`[TryFunction]` lets a caller catch an error, but database changes made before that error are not rolled back. The attribute catches; it does not unwind transaction state. This is the critical distinction from `Codeunit.Run`, which can provide an atomic rollback boundary (see `codeunit-run-as-atomic-sub-operation.md`). On Business Central on-premises, writes inside a try method are blocked by default unless `DisableWriteInsideTryFunctions` is set to `false`; SaaS does not provide that server setting.
 
 ## Best Practice
 
-Reach for `[TryFunction]` when you want to catch a failure without unwinding the transaction — HTTP calls whose non-2xx responses should surface a user-friendly message, .NET interop whose exceptions you want to translate, validation or parsing routines whose errors you intend to log and continue past. Always capture the return: `if MyTry() then ... else HandleFailure(GetLastErrorText());`. When the work is transactional — writes that must either fully apply or fully revert — use `Codeunit.Run` instead. The two primitives solve different problems: one catches errors, the other bounds a rollback scope.
+Reach for `[TryFunction]` when you want to catch a failure without unwinding the transaction — for example, third-party interop or parsing whose error you intend to translate. When writes must either fully apply or fully revert, use `Codeunit.Run` instead. The two primitives solve different problems: one catches errors, the other bounds a rollback scope.
 
 Use `[TryFunction]` sparingly. Each caught error writes to the session-wide `GetLastErrorText` and `GetLastErrorCallStack` buffers, and every subsequent catch overwrites the earlier state — a helper that reads `GetLastErrorText` later may see a different error than the one it intended to inspect. Prefer explicit checks (non-throwing predicates, guard conditions, upfront validation) for operations with predictable failure modes; reserve `[TryFunction]` for genuinely unpredictable failures such as network calls, third-party interop, or evaluation of user-supplied expressions. When you do catch, read `GetLastErrorText` immediately after the failed call, and call `ClearLastError` before the call if an earlier catch in the same scope could have left state behind — per the platform reference, "If you call the GetLastErrorText method immediately after you call the ClearLastError method, then an empty string is returned."
 
@@ -23,6 +23,10 @@ See sample: `use-tryfunction-for-error-catching-not-rollback.good.al`.
 
 ## Anti Pattern
 
-Wrapping database writes in `[TryFunction]` expecting the writes to roll back when the method errors. They do not: the writes that succeeded before the error remain, the caller receives `false`, and the corrupted-state bug surfaces in production. A related anti-pattern is calling a try function without capturing the return (`DoTry();`), which silently strips the error-catching behavior and lets the error propagate — the code looks defensive but behaves identically to an unwrapped call. A third is defensive sprinkling: wrapping every operation that *could* theoretically error in `[TryFunction]` on the theory that catching is always safer than propagating. Each extra catch pollutes the shared error buffer and makes the diagnostic signal harder to find when something real does fail.
+Wrapping database writes in `[TryFunction]` and expecting successful writes before the error to roll back. They remain, the caller receives `false`, and partially applied state can escape. Defensive sprinkling is also unsafe: every catch overwrites the session error buffer and can hide the failure a later helper intended to inspect.
 
 See sample: `use-tryfunction-for-error-catching-not-rollback.bad.al`.
+
+## See also
+
+`microsoft/knowledge/error-handling/ignored-tryfunction-return-disables-try-semantics.md` owns the separate call-site rule that a try method's Boolean result must be consumed.