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:
Jesper Schulz-Wedde 2026-09-09 16:55:35 +02:00 • committed by GitHub
parent 8584217c75
commit 17bb84a25e
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
25 changed files with 229 additions and 51 deletions

View file

@ -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).

View file

@ -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.

View file

@ -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

View file

@ -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]