mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-05 06:36:55 +01:00
Support standalone runners and complete app-folder reviews (#172)
* Document standalone review runner contract Keep model selection and scheduling outside BCQuality while allowing orchestrators to run isolated review leaves concurrently with deterministic rollup semantics. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Support complete app folder reviews Define folder-path as a current-state review scope and accept it across the standalone adapter, broad coordinator, and every AL review leaf. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Add walk-up app review quick start Put the complete app-folder installation and prompt flow directly in the README so partners can discover the standalone experience without reading integration details first. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Organize conceptual guides under docs Move architecture and standalone runner documentation out of the repository root, add a documentation index, and update all inbound links. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Jesper Schulz-Wedde <jesper.schulzwedde@microsoft.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
parent
8584217c75
commit
17bb84a25e
25 changed files with 229 additions and 51 deletions
|
|
@ -57,4 +57,4 @@ each review domain to run in an isolated context.
|
|||
|
||||
These contracts are stable. Changes require a PR approved by both maintainers.
|
||||
|
||||
For the end-to-end flow — from orchestrator trigger through to findings integration — see [`../agent-consumption.md`](../agent-consumption.md). For the high-level project framing, see [`../README.md`](../README.md).
|
||||
For the end-to-end flow — from orchestrator trigger through to findings integration — see [How agents consume BCQuality](../docs/agent-consumption.md). For the high-level project framing, see [`../README.md`](../README.md).
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
name: al-code-review
|
||||
description: Review Business Central AL code changes using BCQuality's curated rules. Use for an AL pull request, working-tree diff, branch, or individual AL file when BCQuality is installed as a standalone plugin.
|
||||
description: Review Business Central AL code using BCQuality's curated rules. Use for an AL app folder, pull request, working-tree diff, branch, or individual AL file when BCQuality is installed as a standalone plugin.
|
||||
---
|
||||
|
||||
# AL code review
|
||||
|
|
@ -21,8 +21,11 @@ context and execute the resulting dispatch.
|
|||
- Copy the caller's actual request verbatim into `goal`; do not replace a
|
||||
focused request such as "review performance" with a generic full-review
|
||||
goal.
|
||||
- Set `inputs-available` to the inputs actually available to the review,
|
||||
normally `pr-diff` for changes or `file-path` for one file.
|
||||
- Set `inputs-available` to the inputs actually available to the review:
|
||||
`folder-path` for an app or source folder, `pr-diff` for changes, or
|
||||
`file-path` for one file. Pass the caller's actual path with the selected
|
||||
input type; for a whole-app request in the current working directory, use
|
||||
that directory as the `folder-path`.
|
||||
- Set `technologies: [al]` when the input is known to be AL.
|
||||
- Pass `bc-version`, `countries`, and `application-area` only when supplied
|
||||
or reliably determined.
|
||||
|
|
@ -66,4 +69,3 @@ where a consumer prunes its checkout to policy before the agent runs and the
|
|||
index is rebuilt over the pruned tree. Treat `BCQUALITY_ENABLED_LAYERS` as a
|
||||
selection filter, never as a security boundary. A host that needs a genuine
|
||||
deny mechanism must prune the installed tree itself.
|
||||
|
||||
|
|
|
|||
43
skills/do.md
43
skills/do.md
|
|
@ -56,7 +56,24 @@ application-area: [all]
|
|||
|
||||
`bc-version`, `technologies`, `countries`, `application-area` are optional filters that let an orchestrator pre-select applicable skills for a task. They follow the same semantics as in READ.
|
||||
|
||||
`inputs` is a list of abstract input types the skill **accepts**. Standard values: `pr-diff`, `object-list`, `file-path`, `repository`, `telemetry-query`. Semantics are any-of: the orchestrator supplies whichever listed input types it has, and the skill is invoked with a non-empty subset of its declared `inputs`. A skill that cannot proceed with the supplied subset MUST return `outcome: "not-applicable"`. `outputs` is always a single-element list naming the output kind; today only `findings-report` is defined.
|
||||
`inputs` is a list of abstract input types the skill **accepts**. Standard values:
|
||||
`pr-diff`, `object-list`, `file-path`, `folder-path`, `repository`, and
|
||||
`telemetry-query`. Semantics are any-of: the orchestrator supplies whichever
|
||||
listed input types it has, and the skill is invoked with a non-empty subset of
|
||||
its declared `inputs`. A skill that cannot proceed with the supplied subset
|
||||
MUST return `outcome: "not-applicable"`. `outputs` is always a single-element
|
||||
list naming the output kind; today only `findings-report` is defined.
|
||||
|
||||
`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
|
||||
actual path, not merely the name of the input type. The agent MUST enumerate
|
||||
the folder rather than reducing it to one representative file.
|
||||
|
||||
Review skills use terms such as "diff", "changed files", and "changed code" as
|
||||
shorthand for the supplied review scope. For `folder-path`, every relevant file
|
||||
under the folder is in scope. A folder supplies no historical baseline:
|
||||
comparison-only rules MUST NOT infer a prior state that was not provided.
|
||||
|
||||
`sub-skills` is an optional field. When present and non-empty, the skill is a **super-skill** that composes other action skills; see *Composition* below. Values are repo-relative paths to action-skill files.
|
||||
|
||||
|
|
@ -231,7 +248,7 @@ Omit `suggested-code` only when the appropriate fix depends on context the skill
|
|||
- `reference` — the suppressed file (same object shape as `findings[].references`).
|
||||
- `reason` — `layer-precedence` when another layer won under READ's precedence rules; `configuration` when the consumer disabled the file's layer.
|
||||
|
||||
**`sub-results`** — super-skills only. Array of complete findings-reports, one per sub-skill that was invoked (i.e., every sub-skill not listed in `skipped-sub-skills`). Each entry MUST itself conform to this output contract. Leaf skills MUST NOT emit `sub-results`.
|
||||
**`sub-results`** — super-skills only. Array of complete findings-reports, one per sub-skill that was invoked (i.e., every sub-skill not listed in `skipped-sub-skills`). Each entry MUST itself conform to this output contract. Entries MUST appear in the worklist's declared order, regardless of invocation or completion order. Leaf skills MUST NOT emit `sub-results`.
|
||||
|
||||
**`skipped-sub-skills`** — super-skills only. Array of sub-skills that were declared in frontmatter but not invoked. `reason` is `configuration` when the orchestrator disabled the sub-skill, or `not-applicable` when the super-skill's Relevance step ruled it out.
|
||||
|
||||
|
|
@ -248,6 +265,20 @@ A **super-skill** is an action skill whose frontmatter declares a non-empty `sub
|
|||
|
||||
Composition is flat: a super-skill MAY list only leaf skills (skills without their own `sub-skills`). Nested super-skills are not permitted in v1.
|
||||
|
||||
### Scheduling boundary
|
||||
|
||||
The super-skill defines which leaves must run, the input and output contracts,
|
||||
and how their results are composed. It does not prescribe a model, concurrency
|
||||
limit, retry policy, or telemetry system. Those choices belong to the
|
||||
orchestrator.
|
||||
|
||||
Each leaf invocation MUST remain a discrete evaluation with its own complete
|
||||
findings-report. An orchestrator MAY execute independent leaves serially or
|
||||
concurrently, but MUST invoke every worklisted leaf, preserve `sub-results` in
|
||||
the declared worklist order, and wait for every invocation to finish before
|
||||
performing any super-skill self-review or final rollup. Scheduling MUST NOT
|
||||
change relevance, coverage, failure, reference-integrity, or output semantics.
|
||||
|
||||
### Section interpretation for super-skills
|
||||
|
||||
The five required sections still apply. Their meaning shifts from knowledge files to sub-skills:
|
||||
|
|
@ -274,7 +305,13 @@ When the worklist is empty (every sub-skill was skipped), `outcome` is `not-appl
|
|||
|
||||
### Rolled-up summary
|
||||
|
||||
`summary.counts` is the sum of sub-skill counts. `summary.coverage.worklist-size` and `items-evaluated` are the sums across invoked sub-skills.
|
||||
`summary.counts` counts the findings in the super-skill's final top-level
|
||||
`findings[]`, after failed sub-results have been excluded and duplicates have
|
||||
been merged. It MUST NOT be calculated by summing sub-skill counts, because the
|
||||
same concern may appear in more than one sub-result.
|
||||
|
||||
`summary.coverage.worklist-size` and `items-evaluated` are the sums across
|
||||
invoked sub-skills whose outcomes are not `failed`.
|
||||
|
||||
### Suppression scope
|
||||
|
||||
|
|
|
|||
|
|
@ -23,6 +23,7 @@ task-context:
|
|||
inputs-available: # values the orchestrator has ready to pass to a chosen skill
|
||||
- pr-diff
|
||||
- file-path
|
||||
- folder-path
|
||||
technologies: [al]
|
||||
bc-version: 28
|
||||
countries: [w1]
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue