mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-05 14:46:55 +01:00
fa7eb750c6
Keep plan enrichment internal and read-only pending consumer agreement and runtime pilot evidence. Move knowledge to its independent PR and remove the consumer-owned forensic evaluator. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 638b66d2-9f06-4f60-8781-808709e1485c
74 lines
7.1 KiB
Markdown
74 lines
7.1 KiB
Markdown
---
|
|
kind: action-skill
|
|
id: al-development-plan
|
|
version: 1
|
|
title: AL development plan guidance
|
|
description: Produces a read-only BCQuality knowledge bundle for an existing Business Central AL development plan.
|
|
inputs: [development-plan, repository]
|
|
outputs: [development-guidance-report]
|
|
bc-version: [all]
|
|
technologies: [al]
|
|
countries: [w1]
|
|
application-area: [all]
|
|
---
|
|
|
|
# AL development plan guidance
|
|
|
|
Selects the BCQuality knowledge that should constrain an existing AL development plan. It does not implement, edit, stage, commit, or publish anything in the target repository. Repository-specific orchestrators can consume this skill before their own test and implementation phases while retaining ownership of workflow, tooling, and delivery.
|
|
|
|
A non-empty `development-plan` is required. A readable `repository` is optional but recommended: use it to confirm affected symbols and applicability context when supplied. When it is absent, preserve repository-dependent facts as unknown and return `partial` only when that missing context materially prevents reliable selection. Return `not-applicable` without changing files when the plan is absent or does not identify the intended change.
|
|
|
|
The caller supplies its existing plan, not a request to generate one. Consumer-specific formats must be normalized by the consumer before invocation. This skill does not interpret issue records, continuation markers, batons, retries, or workflow state. A serialized document containing plan metadata and a markdown body is acceptable when it states the intended change, affected surfaces, proposed approach, test strategy, and acceptance criteria. Missing details remain unknown; do not invent them.
|
|
|
|
## Source
|
|
|
|
Read the BCQuality knowledge index once, using the external path supplied by Entry when present. If no index is available, use READ's path-based discovery across enabled layers; inability to read the corpus is `failed`, not `no-knowledge`. Use entries from every enabled layer and domain. The index supplies candidate paths, applicability dimensions, keywords, titles, and descriptions; it never substitutes for opening selected articles in full.
|
|
|
|
When supplied, inspect the target repository read-only for `app.json`, affected files and symbols named by the plan, relevant tests, permission sets, dependencies, target/runtime versions, countries, application areas, and repository conventions. Do not create scratch or generated files inside the target repository.
|
|
|
|
## Relevance
|
|
|
|
Apply READ's matching semantics using:
|
|
|
|
- `bc-version` from the plan, target application, or supplied context; for upgrades, distinguish source and target versions.
|
|
- `technologies` from the affected files, beginning with `[al]`.
|
|
- `countries` from the plan, `app.json`, or workspace configuration.
|
|
- `application-area` from the plan and affected objects.
|
|
|
|
When a dimension cannot be resolved, retain conditionally applicable candidates only when they can materially constrain the plan. Record the dimension in `context.unknown` and explain it in `unresolved`; do not silently treat it as a match.
|
|
|
|
## Worklist
|
|
|
|
1. Read the supplied plan for its request summary, development kind, assumptions, root cause or design intent, affected files and symbols, proposed changes, test strategy, and acceptance criteria. Preserve its intent; do not generate a replacement plan. If kind is not explicit, classify the stated intent: new or expanded behavior is `feature`, a defect correction is `bug`, behavior-preserving restructuring is `refactor`, migration is `upgrade`, and other bounded work is `maintenance`. Do not redesign the consumer's workflow.
|
|
2. Build retrieval vocabulary from the plan and confirmed repository symbols. Give exact object types, properties, methods, analyzers, errors, and affected domains more weight than broad business nouns.
|
|
3. Search the index in separate passes:
|
|
- data ownership, keys, setup, numbering, validation, transactions, and upgrade;
|
|
- behavior, events, interfaces, errors, permissions, privacy, and telemetry;
|
|
- pages, reports, APIs, integrations, localization, and accessibility;
|
|
- tests, analyzers, packaging, and deployment constraints.
|
|
4. Add an article when its keywords or indexed topic match a concrete planned change, affected symbol, acceptance criterion, or validation obligation. Applicability alone is not enough.
|
|
5. Open every selected article in full. Read any referenced `.good.*` and `.bad.*` sibling needed to make the constraint concrete. Never cite an index row that was not opened.
|
|
6. Resolve contradictory normative guidance with READ's layer precedence and record losing candidates in `suppressed`.
|
|
7. Check the resulting worklist across the whole plan. A bug fix may require testing, data, performance, and upgrade guidance at once; a feature plan may require security and lifecycle constraints that are not named in its title.
|
|
|
|
Keep the worklist focused. Do not include generic engineering advice, an entire domain, or an article that would not change implementation or validation.
|
|
|
|
This skill deliberately does not dispatch the review leaves. Review leaves inspect existing source and emit defects through domain-specific code signals; plan enrichment runs before that source exists and must collect constraints that cross several domains. Both paths consume the same indexed article metadata and full normative article bodies, so new knowledge is automatically eligible for plan retrieval. Review-leaf token maps remain code-detection precision rules, not a second registry that plan retrieval must duplicate.
|
|
|
|
## Action
|
|
|
|
For each worklist article:
|
|
|
|
1. Copy its exact path and optional commit SHA.
|
|
2. State `used-for` as the concrete plan decision or affected surface.
|
|
3. Translate its normative Best Practice and Anti Pattern into short implementation constraints without adding facts or weakening conditions.
|
|
4. Include only opened, existing sibling samples in `sample-paths`.
|
|
5. Derive validation considerations only where the plan or selected knowledge requires observable evidence. Describe the evidence to obtain; do not claim it already exists or passed.
|
|
|
|
Do not change the target repository. Before emitting, verify every knowledge and sample path exists in the live BCQuality checkout and was opened during this run. If reference integrity cannot be established, return `failed` rather than fabricating guidance.
|
|
|
|
## Output
|
|
|
|
Return one `development-guidance-report` conforming to DO. `completed` requires that every selected article was opened and faithfully converted into constraints, with no material unresolved applicability. `no-knowledge` means there are no additional applicable BCQuality constraints for this plan; emit empty `knowledge`. It does not mean the work is unsafe or unimplementable, and the consumer can proceed under its ordinary gates. Never add generic or filler guidance to avoid this outcome.
|
|
|
|
Return `partial` for incomplete evaluation or materially unresolved conditional guidance, naming every gap. Failed retrieval or reference-integrity checks are `failed`, never `no-knowledge`. Consumers own handling of partial, failed, and unresolved results, including clarification and re-enrichment; this read-only interface does not define a universal implementation gate.
|