mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-06 15:16:56 +01:00
Narrow development guidance to provisional contract
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
This commit is contained in:
parent
8f025ac679
commit
fa7eb750c6
40 changed files with 294 additions and 2053 deletions
|
|
@ -1,7 +1,7 @@
|
|||
# BCQuality global skills
|
||||
|
||||
This folder contains BCQuality's layer-independent protocol files and the
|
||||
host-native adapters used by standalone plugin installations.
|
||||
host-native adapter used by standalone plugin installations.
|
||||
|
||||
The protocol files have two kinds:
|
||||
|
||||
|
|
@ -31,9 +31,8 @@ READ and DO are read on demand — typically by the first action skill the agent
|
|||
| Path | Role |
|
||||
|---|---|
|
||||
| [`al-code-review/SKILL.md`](al-code-review/SKILL.md) | Exposes BCQuality through the standard `SKILL.md` format when this repository is installed as a plugin. |
|
||||
| [`al-development-plan/SKILL.md`](al-development-plan/SKILL.md) | Enriches an existing AL plan read-only through the standard `SKILL.md` format; does not generate a plan or implement code. |
|
||||
|
||||
Each adapter is deliberately thin. It translates the caller's request into an
|
||||
The adapter is deliberately thin. It translates the caller's request into an
|
||||
Entry task context, then follows Entry's dispatch without owning routing,
|
||||
review, index, or output policy. It is not an action skill, is not considered
|
||||
by Entry, and should not accumulate behavior already defined by `entry.md`,
|
||||
|
|
@ -41,23 +40,18 @@ by Entry, and should not accumulate behavior already defined by `entry.md`,
|
|||
|
||||
This gives the two skill formats distinct roles:
|
||||
|
||||
- `skills/al-code-review/SKILL.md` and
|
||||
`skills/al-development-plan/SKILL.md` are the public host integration
|
||||
surfaces for a standalone plugin installation.
|
||||
- `skills/al-code-review/SKILL.md` is the public host integration surface for a
|
||||
standalone plugin installation.
|
||||
- `microsoft/skills/review/al-code-review.md` is BCQuality's internal
|
||||
Microsoft-layer super-skill for coordinating a broad AL review.
|
||||
- `microsoft/skills/development/al-development-plan.md` is the read-only
|
||||
knowledge-enrichment interface for existing plans. Consumers own format
|
||||
normalization, planning, implementation, and delivery.
|
||||
|
||||
Each host adapter deliberately shares its name with the internal action skill
|
||||
for the same operation. Their locations distinguish the host integration from
|
||||
the layered policy. `al-code-review` remains distinct from BC-ALAgents'
|
||||
separately installed `al-review` skill, avoiding a collision in hosts that use
|
||||
one shared skill inventory. References from adapters to Entry, and from a
|
||||
dispatched super-skill to its leaves, are intentional progressive disclosure.
|
||||
This avoids registering every internal protocol file as an ambient host skill
|
||||
while allowing each review domain to run in an isolated context.
|
||||
The host adapter and internal coordinator deliberately share the
|
||||
`al-code-review` name because they represent the same user-facing operation in
|
||||
their respective formats. Their locations distinguish their roles. The
|
||||
reference from the adapter to Entry, and from a dispatched super-skill to its
|
||||
leaf skills, is intentional progressive disclosure. It avoids registering
|
||||
every internal BCQuality protocol file as an ambient host skill while allowing
|
||||
each review domain to run in an isolated context.
|
||||
|
||||
These contracts are stable. Changes require a PR approved by both maintainers.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,22 +0,0 @@
|
|||
---
|
||||
name: al-development-plan
|
||||
description: Enrich an existing Business Central AL development plan with read-only BCQuality knowledge constraints. Does not generate a plan or implement code.
|
||||
---
|
||||
|
||||
# AL development plan guidance
|
||||
|
||||
This host-native adapter translates an existing plan and repository into Entry's task context. It does not plan new work, edit the target repository, run an implementation or review/fix loop, stage, commit, or publish changes.
|
||||
|
||||
## Execute
|
||||
|
||||
1. Resolve `PLUGIN_ROOT` to the directory containing this plugin's root `plugin.json`, two levels above this file.
|
||||
2. Preserve the caller's existing `development-plan` verbatim. Consumer-specific workflow payloads must be normalized by the consumer; do not interpret workflow state or manufacture a plan from a coding request.
|
||||
3. Build the task context for `PLUGIN_ROOT/skills/entry.md`:
|
||||
- Set `goal` to read-only BCQuality knowledge enrichment of the supplied plan, preserving the caller's intended change.
|
||||
- List only actually supplied inputs from `[development-plan, repository]` in `inputs-available`.
|
||||
- Set `technologies: [al]` only when established, and pass other applicability dimensions only when supplied or reliably determined.
|
||||
- Apply `BCQUALITY_ENABLED_LAYERS` and `BCQUALITY_DISABLED_SKILLS` as described in the `al-code-review` adapter.
|
||||
4. Read and execute Entry, including Preparation. Resolve its paths against `PLUGIN_ROOT`, not the target repository. Keep all generated index and scratch artifacts outside the target repository. Use READ's path-based fallback if index generation is unavailable; an unreadable corpus is a failure, not empty knowledge.
|
||||
5. Follow Entry's dispatch, checking its output metadata against the referenced skill before invocation. This operation accepts only `development-guidance-report`; return `failed` rather than execute another output kind. Pass the supplied existing plan and readable repository, and return the report unchanged. Return Entry's `no-match` or `failed` record unchanged when nothing is dispatched.
|
||||
|
||||
Missing inputs remain missing; the dispatched action skill returns `not-applicable` when it cannot proceed. A `no-knowledge` report is additive: it means no additional BCQuality constraints, not a refusal to let the consumer implement under its own gates. The consumer retains all implementation and delivery ownership.
|
||||
24
skills/do.md
24
skills/do.md
|
|
@ -73,6 +73,11 @@ proceed with the supplied subset MUST return `outcome: "not-applicable"`.
|
|||
- `findings-report` — evaluates an input and reports defects or observations.
|
||||
- `development-guidance-report` — selects and summarizes applicable BCQuality knowledge for an existing development plan without changing the target repository.
|
||||
|
||||
`development-plan` and `development-guidance-report` are provisional contract
|
||||
extensions. They are intentionally not exposed by the standalone plugin in this
|
||||
release. Consumer-owner agreement and pilot evidence are required before they
|
||||
are treated as frozen public integration surfaces.
|
||||
|
||||
`file-path` is one file. `folder-path` is a directory whose recursively
|
||||
contained files form the complete current-state input, such as a Business
|
||||
Central app folder containing `app.json` and AL source. The input value is the
|
||||
|
|
@ -106,6 +111,14 @@ Every action skill MUST contain these five sections, in order:
|
|||
|
||||
**Action.** Execute the skill's work against the worklist. Evaluate each item in the worklist against the task input and emit findings. The action step is where skill behavior differs; the preceding three steps are uniform.
|
||||
|
||||
Review and plan enrichment use different Worklist signals by design. Review
|
||||
leaves inspect existing source and use domain-specific code tokens to decide
|
||||
which rules can produce findings. Plan enrichment precedes implementation and
|
||||
selects cross-domain constraints from plan vocabulary and confirmed repository
|
||||
symbols. Both use the same knowledge index, applicability semantics, layer
|
||||
precedence, and full normative article bodies; review-leaf cue lists are not a
|
||||
second knowledge registry.
|
||||
|
||||
<a id="output-contract"></a>
|
||||
|
||||
## Findings-report contract
|
||||
|
|
@ -345,6 +358,11 @@ Severity taxonomy:
|
|||
|
||||
An action skill with `outputs: [development-guidance-report]` emits one JSON document:
|
||||
|
||||
The provisional machine-readable structural schema is
|
||||
[`schemas/development-guidance-report.schema.json`](../schemas/development-guidance-report.schema.json).
|
||||
The semantic rules below remain authoritative for count arithmetic, exact
|
||||
reference existence, applicability, and normative constraint fidelity.
|
||||
|
||||
```json
|
||||
{
|
||||
"skill": { "id": "string", "version": 1 },
|
||||
|
|
@ -389,12 +407,12 @@ An action skill with `outputs: [development-guidance-report]` emits one JSON doc
|
|||
}
|
||||
```
|
||||
|
||||
The skill is read-only with respect to the target repository: no edits, generated files, staging, commits, or publication. Keep index, report, and scratch artifacts outside that repository. The report is strict JSON with no surrounding commentary. The caller supplies an existing plan and repository; consumer-specific input normalization and workflow state are outside this contract.
|
||||
The skill is read-only with respect to the target repository: no edits, generated files, staging, commits, or publication. Keep index, report, and scratch artifacts outside that repository. The report is strict JSON with no surrounding commentary. The caller supplies an existing plan and may supply a readable repository; consumer-specific input normalization and workflow state are outside this contract.
|
||||
|
||||
### Guidance outcome semantics
|
||||
|
||||
- `completed` — evaluation finished, at least one article was selected, every selected article was opened and faithfully converted into constraints, and no materially unresolved conditional guidance remains.
|
||||
- `not-applicable` — the required existing plan or readable repository is absent, or the task is outside the skill's applicability. No constraints are claimed.
|
||||
- `not-applicable` — the required existing plan is absent, does not identify the intended change, or is outside the skill's applicability. No constraints are claimed.
|
||||
- `no-knowledge` — evaluation finished and there are **no additional applicable BCQuality constraints** for this plan. `knowledge` is empty. This is not a statement that the work is unsafe or unimplementable; the consuming workflow can proceed under its ordinary gates. Do not add generic or filler articles to avoid this outcome.
|
||||
- `partial` — evaluation is incomplete or conditional guidance remains materially unresolved. Name each gap in `outcome-reason` and `unresolved`; do not silently treat an unknown dimension as a match.
|
||||
- `failed` — retrieval, reference integrity, or another error prevents a reliable report. Set `outcome-reason`; consumers must not treat the result as reliable constraints or as `no-knowledge`.
|
||||
|
|
@ -409,7 +427,7 @@ The skill is read-only with respect to the target repository: no edits, generate
|
|||
|
||||
`validation-considerations` states evidence the implementation workflow should obtain; it does not claim that a command or test has run. `suppressed` has the same shape and semantics as in a findings-report. `unresolved` records missing repository context or plan decisions that prevent a reliable constraint. Unknown applicability dimensions must appear in both `context.unknown` and a relevant unresolved entry, explaining whether they materially affect a candidate. An unknown dimension is not itself a failure or proof that relevant knowledge exists.
|
||||
|
||||
Reference SHAs, when present, identify the files read; they do not prove runtime pinning on their own. The consumer records and verifies the actual immutable BCQuality checkout used for both enrichment and final review, plus its filtering policy and run provenance outside the target repository. See [agent-consumption.md](../agent-consumption.md).
|
||||
Reference SHAs, when present, identify the files read; they do not prove runtime pinning on their own. The consumer records and verifies the actual immutable BCQuality checkout used for both enrichment and final review, plus its filtering policy and run provenance outside the target repository. See [agent-consumption.md](../docs/agent-consumption.md).
|
||||
|
||||
## Composition (super-skills)
|
||||
|
||||
|
|
|
|||
|
|
@ -36,6 +36,11 @@ task-context:
|
|||
|
||||
`goal` and `inputs-available` are required. Filter dimensions (`technologies`, `bc-version`, `countries`, `application-area`) are optional; omitting a dimension is equivalent to "unconstrained" — see Relevance for the exact matching rule. `enabled-layers` defaults to all three. `disabled-skills` defaults to empty.
|
||||
|
||||
`development-plan` and the corresponding `development-guidance-report` output
|
||||
kind are provisional. They are available to explicit integrations for review
|
||||
and pilot use, but are not registered as standalone plugin capabilities in
|
||||
this release.
|
||||
|
||||
## Preparation — knowledge index
|
||||
|
||||
Before routing, ensure the knowledge index is current for the **live** clone. The dispatched skills read `knowledge-index.json` (by default at the clone root) at their Source step instead of opening every knowledge file — see READ's [Retrieval workflow](read.md). When a consumer prunes its clone to policy *before* the agent runs, the index MUST be built over the clone as it exists now, so it lists exactly the articles that survived pruning and never an article the consumer denied:
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue