Add new action skills for AL testing and documentation

- Introduced `al-test-writer` to generate AL test codeunits for production objects based on TDD principles.
- Added `al-userguide-test-writer` to create test codeunits from user guide steps, mapping actions and assertions.
- Implemented `bc-extension-test-guide` to generate a comprehensive TEST_GUIDE.md for Business Central extensions, covering various categories.
- Created `bc-webclient-runner` to automate UI testing of the Business Central web client, capturing screenshots and asserting UI states.
- Developed `page-scripting-e2e` to produce a recording plan for Page Scripting, ensuring a structured approach to browser-level testing.

custom/knowledge/operations/inspect-the-al-runtime-during-a-debug-session.md

@@ -0,0 +1,28 @@
+---
+bc-version: [28]
+domain: operations
+keywords: [troubleshooting-mcp-server, debug, call-stack, runtime, copilot, breakpoint]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+---
+
+# Inspect the AL runtime during a debug session
+
+## Description
+
+The Troubleshooting MCP Server lets GitHub Copilot Chat read the live AL runtime state during an active debug session: the call stack, the variables at any frame, the source for a frame, and a breakpoint set by object and line number while paused. It is available only while a debug session is paused at a breakpoint or a runtime error, and only on BC 2026 release wave 1 (BC 28) or later. It is the right surface when you want a natural-language explanation that follows a deep call stack or an answer to why a particular code path executed, rather than stepping through manually.
+
+What it reads is the runtime as it stands at the pause point, so it answers questions about the present state of an execution rather than its history. The value over manual stepping is that Copilot can fan out across many frames and variables at once and summarise them, which is exactly the work that is tedious to do by hand on a deep stack. It reads; it does not write, step, or apply fixes.
+
+## Best Practice
+
+Reach for the Troubleshooting MCP Server when a runtime error has fired or a paused stack is deep across many objects and you want it summarised, or when you want to know why a branch took a particular path without manual stepping. Pause at the breakpoint or error first, then ask Copilot explicitly to use the server, since it does not always reach for it on its own. Use the variable inspection to surface database statistics (SQL latency, executes, row reads) that traditional stepping hides, which is good for spotting hidden DB calls in subscribers. Pair it with the performance profiler: profile first for slowness, then set a breakpoint at the slow frame and ask the Troubleshooting MCP for the runtime detail.
+
+## Anti Pattern
+
+Using it for the wrong job or expecting capabilities it does not have. It is not a replacement for interactive step-through debugging, for a quick look at one variable, or for learning unfamiliar code by reading it. It offers no time travel, so it only shows what is in scope right now, and it returns no source for frames whose code lives only in compiled .app packages, where you fall back to inspecting variables. The signal of misuse: trying to invoke it with no active paused debug session, on a version before BC 28, or expecting it to replay history or auto-apply fixes.
+
+## See also
+
+- `run-headless-al-builds-with-the-al-mcp-server.md`

custom/knowledge/operations/know-the-limits-of-saas-point-in-time-restore.md

@@ -0,0 +1,28 @@
+---
+bc-version: [all]
+domain: operations
+keywords: [saas-restore, point-in-time, backup, retention, sandbox, production]
+technologies: [powershell]
+countries: [w1]
+application-area: [all]
+---
+
+# Know the limits of SaaS point-in-time restore
+
+## Description
+
+A Business Central SaaS point-in-time restore is bounded by hard platform limits that decide whether a restore is even possible, and by what the platform does and does not bring back. Before promising a customer a restore, you need to know these limits: the backup retention window is the last 28 days, restores are capped per calendar month, the restore must stay in the same Azure region, the localisation cannot change, and a sandbox cannot be restored to production (the allowed paths are production to production, production to sandbox, and sandbox to sandbox). Promising a restore that the limits forbid, or assuming integrations come back live, sets a false expectation during an incident, which is the worst moment to discover a constraint.
+
+The restore is not a snapshot that comes up identical to the source. It is a managed operation that rebuilds business data and then deliberately neutralises anything that could fire against stale data or reach the wrong system, so the difference between what is restored and what is reset is the part a hand-off most often gets wrong.
+
+## Best Practice
+
+Check feasibility against the limits before committing: confirm the desired restore point is within the last 28 days, the target is in the same Azure region, the localisation is unchanged, and the path is allowed. Know what comes back and what does not. Business data, posted documents, master and setup data are restored; AppSource apps return at their latest hotfix even if newer than the restore point; dev-only extensions installed from VS Code are not in the backup and must be reinstalled. The most surprising part is that integrations come up disabled or cleared on purpose, so they cannot fire on stale data, which means a post-restore checklist of re-enabling and re-credentialing each one and running smoke tests. Tell the customer up front about downtime, lost work after the restore point, and integrations needing manual reconnection.
+
+## Anti Pattern
+
+Promising or attempting a restore without checking the limits, or assuming the restored environment comes up exactly as it was. The consequences: a restore that is simply not allowed (cross-region, localisation change, sandbox to production, outside the 28-day window, or over the monthly cap), or a customer surprised that integrations are off and post-restore work is gone. The signal: a restore committed to before the restore point, region, localisation, path, and retention window have been confirmed, or a hand-off that does not warn about disabled integrations and lost post-restore-point work.
+
+## See also
+
+- `restrict-bc-environments-with-an-entra-security-group.md`