Add StrongPoint custom knowledge layer

Eight organization rules in custom/knowledge, each overriding or
supplementing the Microsoft layer for StrongPoint repositories:

- style/spu-prefix-on-objects-and-extension-members
- style/cyclomatic-complexity-is-not-a-gate-in-sp-repos (LC0010 = Info)
- ui/keep-tooltips-on-sp-page-fields (AA0218 = Error, LC0064 off;
  overrides microsoft ui/bound-page-field-inherits-source-field-tooltip)
- data-modeling/sp-field-names-fit-30-chars-with-prefix (AL0468 = Error)
- events/change-ls-central-behaviour-through-its-events
- web-services/device-io-goes-through-sp-device-manager
- appsource/sp-id-ranges-are-not-checked-by-as0084 (AS0084 = None)
- upgrade/sp-released-ids-never-change

Sources: sp.ruleset.json across SP repositories, SPUFBUpgrade pattern in
SP-LSC-Fiscal-Printing, observed LS Central and Device Manager usage.
Verified: all eight are indexed by Build-KnowledgeIndex.ps1, and a review
of a probe app applied the ToolTip rule as major and suppressed the
Microsoft article by layer precedence.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

custom/knowledge/style/cyclomatic-complexity-is-not-a-gate-in-sp-repos.md

@@ -0,0 +1,26 @@
+---
+bc-version: [all]
+domain: style
+keywords: [cyclomatic-complexity, lc0010, lintercop, maintainability, false-positive]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+---
+
+# Cyclomatic complexity (LC0010) is advisory in StrongPoint repositories
+
+## Description
+
+StrongPoint's `sp.ruleset.json` downgrades LinterCop LC0010 (cyclomatic complexity) to `Info`, and a few repositories disable it. Long procedures in POS, fiscal-printing and device flows mirror LS Central's own event and state handling; splitting them only to satisfy the metric is not required. Complexity is therefore never a merge gate in SP code.
+
+## Best Practice
+
+Mention high complexity at most as `info` or `minor`, and only together with a concrete readability or correctness problem you can point to (a duplicated branch, an unreachable path, a missing `else`). Judge new code on correctness first.
+
+## Anti Pattern
+
+Reporting a procedure as `major` or `blocker` because LC0010 fires or because it "has too many branches", or asking for a refactor of existing complex procedures that the change did not touch.
+
+## References
+
+StrongPoint policy: `sp.ruleset.json` — LC0010 `Info` ("Cyclomatic complexity warning changed to info").

custom/knowledge/style/spu-prefix-on-objects-and-extension-members.md

@@ -0,0 +1,26 @@
+---
+bc-version: [all]
+domain: style
+keywords: [prefix, affix, spu, naming, object-name, tableextension, pageextension, as0011]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+---
+
+# StrongPoint objects and extension members carry the `SPU` prefix
+
+## Description
+
+In StrongPoint repositories every new AL object name, and every new field, control or action that a table extension or page extension adds to someone else's object, starts with the mandatory affix `SPU` — for example `codeunit 70760591 "SPU EMV Manager"` or the table-extension field `"SPU FB Receipt Printed"`. The AL-Go pipeline validates the prefix and fails the build without it; there is usually no `AppSourceCop.json` with `mandatoryAffixes` in the repository to warn earlier, so a missing prefix is only found at CI time.
+
+## Best Practice
+
+Name every new object `"SPU <App code> <Name>"` and every member added to a base-app or LS Central object `"SPU <App code> <Name>"`, following the app's existing code (for example `FB` for Fiscal Printing). Members of the extension's own `SPU` objects (fields of an `SPU` table, procedures of an `SPU` codeunit) do not need the prefix again. Report a missing prefix on a new object or extension member as `major`: the build will fail.
+
+## Anti Pattern
+
+A new object or an extension field without the prefix, a suffix instead of a prefix (`"Receipt Printed SPU"`), or another company's affix copied from sample code. Also wrong: demanding the prefix on members of an object that is already `SPU`-prefixed, or on existing objects that predate the rule.
+
+## References
+
+StrongPoint policy: AL-Go pipeline prefix validation in every SP repository (workspace `CLAUDE.md`, "AL Object Rules").