When an AI reviewer recommends changing some AL code, I want to know where that recommendation came from. Most of us have seen advice described as “best practice” that becomes difficult to verify the moment someone asks for the underlying rule. BCQuality gives Business Central teams a knowledge base and review skills whose articles can be read and cited. ALDC uses that material to bring relevant guidance into design decisions and to support code review findings with references.
The useful outcome is a shared conversation. A team rule can shape the architecture before implementation starts; later, a reviewer can identify a problem and point to the article behind its finding. The developer can inspect the source, challenge its relevance and make a decision with context.
Guidance with three levels of ownership
BCQuality organizes knowledge under microsoft, community and custom. Your organization can populate custom in its own fork, and that layer takes precedence when guidance overlaps. For example, a team may have an AL convention driven by its maintenance or deployment constraints. Keeping it in the same knowledge system as community and Microsoft guidance lets reviewers apply it without pretending that every rule has the same authority or origin.
ALDC selects a provider in the project’s aldc.yaml; the declaration does not install BCQuality. With external-multiroot, the corpus lives outside the AL source folders and is opened as another workspace root. With plugin, the host provides a configured review skill, such as al-code-review when that is the installed identity. The current plugin skill is a review entry point. For knowledge-only reading during design, agents need access to the corpus, for example through the multiroot workspace.
That distinction matters because it defines what each mode can actually do today. A team can also point the configuration to its BCQuality fork and optionally pin a commit when it needs to reproduce the rules used for a particular review.
Apply knowledge before writing AL
During architecture and specification, agents with access to the corpus can read articles relevant to the requirement. Organization guidance comes first, followed by platform articles selected for the domain. The output is not a defects report, because there may be no code yet. The Architect can capture constraints and source selections; the Spec Agent can write review criteria that cite exact article paths.
That gives a Business Central team a chance to discuss an exception early. If a house rule does not fit a particular requirement, the deviation and its reason can be recorded and brought to the existing human approval gate. The agent does not silently ignore the rule, and reading an article is not represented as a code review.
Apply it again when reviewing code
Once there is AL to inspect, a review agent supplies the real task context to BCQuality’s entry point and executes the selected skills. ALDC can consume results in Conductor’s review phase, Developer review, Dredd’s on-demand audits and Triage diagnostics. A knowledge-backed finding retains its article path as its identifier, so a developer can open the rule and CI can resolve the citation against the corpus.
BCQuality adds to the agent’s judgment and native checks. It does not replace compilation, analyzers or tests. Native review coverage for a domain is reduced only after BCQuality actually completes a review of that domain; discovering a related article is not the same as reviewing the change.
If the provider is absent or incompatible, ALDC records that state and runs its full native A–G checklist. Missing BCQuality is not an AL code defect and cannot itself block a phase. Findings produced by native review retain their ordinary severity. This fallback matters in teams where developers use different hosts or have different plugins installed.
Keep the source of a finding visible
ALDC distinguishes a provider being configured, discovered, loaded and executed. Those stages make a review report easier to interpret: a skill listed in a catalog has not necessarily run. During design, reading the relevant article can be reported; during review, the actual result and its outcome can be retained. Doctor and the optional knowledge index follow the same discipline when describing what they observed.
That evidence detail supports the larger benefit: a team can turn scattered AL advice into shared criteria that are useful both when designing and when reviewing. AI helps apply those criteria. Citations and human approval make it possible to discuss them without accepting a confident recommendation on trust alone.
Deja un comentario