mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-08-06 17:36:53 +01:00
Strengthen al-code-review execution, propagate suggested-code to leaves, two new KB articles
Driven by a parity comparison between BCAppsBCQuality PR #27 and BCAppsCampAIRHack PR #162 on byte-identical content: | | BCQuality | AIRHack | |--|--|--| | Total findings | 6 | 10 | | Performance | 0 | 4 | | Security | 0 | 5 | Standalone runs of al-security-review and al-performance-review against the SAME diff produced the expected matches (rimd-on-read-only via inherent-permissions-minimal-grant; redundant-Get via avoid-redundant-get-when-record-already-loaded). The miss in the live run is therefore not a knowledge-coverage gap and not a worklist filtering issue. It is attention dilution inside the al-code-review super-skill, which the model collapses into one rolled-up generation pass on real-size PRs. Changes: microsoft/skills/review/al-code-review.md - New 'Execution discipline (mandatory)' subsection in the Action step that explicitly forbids collapsing leaves into one shared reasoning pass and requires each sub-skill to walk its Source -> Relevance -> Worklist -> Action steps as its own iteration before the next leaf starts. - Self-review pass is now described as the final, mandatory iteration with a concrete candidate-category checklist (architecture-level smells, error-handling gaps, magic constants, privacy/telemetry, resource lifecycle). Returning zero agent findings on a real-size diff is explicitly defined as a defect. microsoft/skills/review/al-{security,performance,privacy,style, upgrade,ui}-review.md - Each leaf skill now states that when an unambiguous .good.al companion exists, findings[].suggested-code should carry the literal replacement for the source lines. Closes the one-click-suggestion gap created when BCQ#19 only updated al-code-review. microsoft/knowledge/security/case-must-handle-unknown-enum-values.{md, bad.al, good.al} - New article: case over a security-sensitive enum (Authentication Type, Authorization Mode, Identity Provider, Permission Scope, Encryption Algorithm) MUST have an else arm. Without it, an unknown enum value silently falls through and the security context never initialises. The bad sample is lifted from the SharePoint Graph helper that triggered the parity finding. microsoft/knowledge/performance/instream-length-unreliable-for-bc- streams.{md,bad,good} - New article: InStream.Length returns 0 / partial for HTTP-response streams and some file-API streams, breaking size-threshold branching in upload code. Bad sample is the simple-vs-chunked Graph upload pattern; good sample materialises into a Temp Blob first. Companion change: microsoft/BCAppsBCQuality#28 extends the orchestrator's bootstrap prompt with the same per-iteration execution discipline and adds a CI warning when a >5-file PR returns zero agent findings (regression signal). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
parent
d8e8355259
commit
31b9949235
13 changed files with 236 additions and 3 deletions
|
|
@ -0,0 +1,29 @@
|
|||
codeunit 50272 "Sample InStream Length Bad"
|
||||
{
|
||||
var
|
||||
MaxSimpleUploadSize: Integer;
|
||||
|
||||
procedure Upload(var Stream: InStream; FileName: Text)
|
||||
var
|
||||
SimpleResp: HttpResponseMessage;
|
||||
ChunkedResp: HttpResponseMessage;
|
||||
begin
|
||||
MaxSimpleUploadSize := 4 * 1024 * 1024;
|
||||
// Wrong: Stream.Length is 0 or unreliable for streams from HTTP
|
||||
// responses, some file APIs, and caller-supplied streams.
|
||||
if Stream.Length <= MaxSimpleUploadSize then
|
||||
UploadSimple(Stream, FileName, SimpleResp)
|
||||
else
|
||||
UploadChunked(Stream, FileName, ChunkedResp);
|
||||
end;
|
||||
|
||||
local procedure UploadSimple(var Stream: InStream; FileName: Text; var Response: HttpResponseMessage)
|
||||
begin
|
||||
// ... PUT to /items/{id}/content endpoint
|
||||
end;
|
||||
|
||||
local procedure UploadChunked(var Stream: InStream; FileName: Text; var Response: HttpResponseMessage)
|
||||
begin
|
||||
// ... POST to /items/{id}/createUploadSession endpoint, then PUT in chunks
|
||||
end;
|
||||
}
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
codeunit 50273 "Sample InStream Length Good"
|
||||
{
|
||||
var
|
||||
MaxSimpleUploadSize: Integer;
|
||||
|
||||
procedure Upload(var Stream: InStream; FileName: Text)
|
||||
var
|
||||
TempBlob: Codeunit "Temp Blob";
|
||||
SizedStream: InStream;
|
||||
BufferLength: Integer;
|
||||
SimpleResp: HttpResponseMessage;
|
||||
ChunkedResp: HttpResponseMessage;
|
||||
begin
|
||||
MaxSimpleUploadSize := 4 * 1024 * 1024;
|
||||
// Materialise once into a Temp Blob; its length is reliable.
|
||||
CopyStream(TempBlob.CreateOutStream(), Stream);
|
||||
BufferLength := TempBlob.Length();
|
||||
TempBlob.CreateInStream(SizedStream);
|
||||
|
||||
if (BufferLength > 0) and (BufferLength <= MaxSimpleUploadSize) then
|
||||
UploadSimple(SizedStream, FileName, SimpleResp)
|
||||
else
|
||||
UploadChunked(SizedStream, FileName, ChunkedResp);
|
||||
end;
|
||||
|
||||
local procedure UploadSimple(var Stream: InStream; FileName: Text; var Response: HttpResponseMessage)
|
||||
begin
|
||||
// ... PUT to /items/{id}/content endpoint
|
||||
end;
|
||||
|
||||
local procedure UploadChunked(var Stream: InStream; FileName: Text; var Response: HttpResponseMessage)
|
||||
begin
|
||||
// ... POST to /items/{id}/createUploadSession endpoint, then PUT in chunks
|
||||
end;
|
||||
}
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
---
|
||||
bc-version: [all]
|
||||
domain: performance
|
||||
keywords: [instream, outstream, length, stream, upload, blob, http, chunk]
|
||||
technologies: [al]
|
||||
countries: [w1]
|
||||
application-area: [all]
|
||||
---
|
||||
|
||||
# `InStream.Length` is unreliable for branching on payload size
|
||||
|
||||
## Description
|
||||
|
||||
`InStream` exposes a `Length` property that returns the total byte count of the underlying buffer when the runtime can determine it. The catch is that "when the runtime can determine it" depends on **how the stream was obtained**:
|
||||
|
||||
- Streams produced from a `Blob` or a `Temp Blob` field by `CreateInStream` — `Length` is reliable; the blob is fully materialised.
|
||||
- Streams produced from a Media or MediaSet field — same: backed by a known-size payload.
|
||||
- Streams produced from `HttpResponseMessage.Content.ReadAs` and from many `File.*` APIs — `Length` may return `0` or a partial value, because the underlying transport is consumed incrementally and the total length is not known until the stream is exhausted.
|
||||
- Streams from `Stream` parameters supplied by callers — depends entirely on what the caller passed in.
|
||||
|
||||
Branching upload behaviour on `Stream.Length` is the common failure mode. The pattern is:
|
||||
|
||||
```al
|
||||
if Stream.Length <= MaxSimpleUploadSize then
|
||||
UploadSimple(Stream)
|
||||
else
|
||||
UploadChunked(Stream);
|
||||
```
|
||||
|
||||
For a Microsoft Graph drive upload, `MaxSimpleUploadSize` is 4 MB. If `Stream.Length` returns `0` (because the stream came from an HTTP response or a freshly written outstream that the runtime cannot size cheaply), the code takes the simple-upload path with a 10 MB file behind it, the API returns `413 Payload Too Large`, and the upload fails. The error surfaces to the user as a generic HTTP failure with no obvious connection to the buggy size check.
|
||||
|
||||
The same trap applies to any code that "skips the work if the stream is empty": `if Stream.Length = 0 then exit;` silently drops payloads when the stream came from a source that does not pre-compute length.
|
||||
|
||||
## Best Practice
|
||||
|
||||
Decide which behaviour you actually need.
|
||||
|
||||
- **Always-chunked** is the safe default when the stream's origin is not under your control. Chunked uploads work for any payload size; the per-chunk overhead is small for small payloads.
|
||||
- When a size threshold is genuinely required (for example, choosing between two endpoints with different cost profiles), copy the stream into a known-size buffer first — typically a `Temp Blob` — and read length from the blob, which IS reliable. The cost of one round-trip through a blob is acceptable for the upload-routing decision.
|
||||
- When the threshold is informational (logging, telemetry), guard against `0`: `if (Stream.Length > 0) and (Stream.Length <= Threshold)` so an unknown size routes to the safe path, not the optimistic one.
|
||||
|
||||
See sample: `instream-length-unreliable-for-bc-streams.good.al`.
|
||||
|
||||
## Anti Pattern
|
||||
|
||||
Branching upload size, validation, or buffer allocation directly on `Stream.Length` when the stream's origin is anything other than a freshly-materialised blob. Detection signal: `Stream.Length` (or `.Length` on a variable typed `InStream` or `OutStream`) appearing as the left or right side of `<=`, `<`, `>=`, `>`, or `=` against a size-like constant or `Label`, with no prior copy through a `Blob`. The narrower signal — branching simple-vs-chunked upload on `Length` for Graph or REST endpoints with a documented size cap — is the high-confidence case.
|
||||
|
||||
See sample: `instream-length-unreliable-for-bc-streams.bad.al`.
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
codeunit 50270 "Sample Case No Else Bad"
|
||||
{
|
||||
procedure InitializeGraphClient(var SharePointAccount: Record "Ext. SharePoint Account"; var GraphAuthInterface: Interface "Graph Auth Interface")
|
||||
var
|
||||
GraphAuthClientCredentials: Codeunit "Graph Auth Client Credentials";
|
||||
GraphAuthCertificate: Codeunit "Graph Auth Certificate";
|
||||
begin
|
||||
case SharePointAccount."Authentication Type" of
|
||||
SharePointAccount."Authentication Type"::"Client Secret":
|
||||
GraphAuthInterface := GraphAuthClientCredentials;
|
||||
SharePointAccount."Authentication Type"::Certificate:
|
||||
GraphAuthInterface := GraphAuthCertificate;
|
||||
end;
|
||||
end;
|
||||
}
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
codeunit 50271 "Sample Case With Else Good"
|
||||
{
|
||||
var
|
||||
UnsupportedAuthTypeErr: Label 'Authentication type %1 is not supported.', Comment = '%1 = Authentication Type value';
|
||||
|
||||
procedure InitializeGraphClient(var SharePointAccount: Record "Ext. SharePoint Account"; var GraphAuthInterface: Interface "Graph Auth Interface")
|
||||
var
|
||||
GraphAuthClientCredentials: Codeunit "Graph Auth Client Credentials";
|
||||
GraphAuthCertificate: Codeunit "Graph Auth Certificate";
|
||||
begin
|
||||
case SharePointAccount."Authentication Type" of
|
||||
SharePointAccount."Authentication Type"::"Client Secret":
|
||||
GraphAuthInterface := GraphAuthClientCredentials;
|
||||
SharePointAccount."Authentication Type"::Certificate:
|
||||
GraphAuthInterface := GraphAuthCertificate;
|
||||
else
|
||||
Error(UnsupportedAuthTypeErr, SharePointAccount."Authentication Type");
|
||||
end;
|
||||
end;
|
||||
}
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
---
|
||||
bc-version: [all]
|
||||
domain: security
|
||||
keywords: [case, else, enum, fallthrough, authentication, authorization, default, switch]
|
||||
technologies: [al]
|
||||
countries: [w1]
|
||||
application-area: [all]
|
||||
---
|
||||
|
||||
# `case` over an enum must handle unknown values via `else`
|
||||
|
||||
## Description
|
||||
|
||||
A `case` statement that branches on an enum value and lists only the values the author knows about silently falls through when the runtime value is one the code does not name. For business-logic enums, falling through usually means "do nothing"; for security-relevant enums — authentication type, authorization mode, identity provider, encryption strategy, permission scope — falling through means **the code path that was supposed to set up the security context never runs, and the operation proceeds with whatever state the variables had before the `case`**.
|
||||
|
||||
A canonical example, lifted from real review traffic:
|
||||
|
||||
```al
|
||||
case SharePointAccount."Authentication Type" of
|
||||
SharePointAccount."Authentication Type"::"Client Secret":
|
||||
GraphAuthInterface := GraphAuthClientCredentials;
|
||||
SharePointAccount."Authentication Type"::Certificate:
|
||||
GraphAuthInterface := GraphAuthCertificate;
|
||||
end;
|
||||
GraphClient.Initialize(GraphAuthInterface);
|
||||
```
|
||||
|
||||
If a new authentication type is added to the enum, or if a database row carries a value the deployed code does not yet handle, `GraphAuthInterface` is whatever the previous caller left in it (or default-initialised), and the client initialises against an unauthenticated or wrongly-authenticated context. The compiler does not warn — enums are not closed sets to the AL type system the way unions are in other languages.
|
||||
|
||||
The same shape shows up outside security: postings codeunits that handle two of three document types and silently skip the third; tax computation that branches on calculation method; report layouts that branch on output format. Wherever a `case` over an enum determines what code path executes, an `else` branch with a controlled error (or a deliberate documented no-op) is required.
|
||||
|
||||
## Best Practice
|
||||
|
||||
Add an `else` branch to every `case` statement that branches on an enum value when the code paths matter. For security-sensitive branches, raise a `Error` with a message that names the unsupported value:
|
||||
|
||||
```al
|
||||
case SharePointAccount."Authentication Type" of
|
||||
SharePointAccount."Authentication Type"::"Client Secret":
|
||||
GraphAuthInterface := GraphAuthClientCredentials;
|
||||
SharePointAccount."Authentication Type"::Certificate:
|
||||
GraphAuthInterface := GraphAuthCertificate;
|
||||
else
|
||||
Error(UnsupportedAuthTypeErr, SharePointAccount."Authentication Type");
|
||||
end;
|
||||
```
|
||||
|
||||
For deliberate no-op fall-through, document it: `else // intentional: format X is a passthrough.` so reviewers see the choice was made rather than forgotten. Pair the `else` arm of a security branch with telemetry — an unsupported value reaching this point in production is a deployment signal worth surfacing.
|
||||
|
||||
See sample: `case-must-handle-unknown-enum-values.good.al`.
|
||||
|
||||
## Anti Pattern
|
||||
|
||||
`case` over an enum with no `else`, used to choose which authentication, authorization, or security-state-initialising code path runs. Detection signal: a `case` whose arms write to a single shared output (an interface variable, a credentials record, a permission token) with no `else` arm. The narrower signal — a `case` whose value type is a security-related enum (`Authentication Type`, `Authorization Mode`, `Identity Provider`, `Permission Scope`, `Encryption Algorithm`) — is the high-confidence anti-pattern.
|
||||
|
||||
See sample: `case-must-handle-unknown-enum-values.bad.al`.
|
||||
|
|
@ -60,9 +60,18 @@ The worklist is the list of sub-skills judged relevant by the previous step. Eve
|
|||
|
||||
## Action
|
||||
|
||||
### Execution discipline (mandatory)
|
||||
|
||||
The Action step is a sequence of **discrete iterations**, not one combined generation. The contract requires the super-skill to invoke each sub-skill in turn and then perform a self-review pass. Concretely this means:
|
||||
|
||||
- Treat each sub-skill in the worklist as its own pass: read the sub-skill's instructions, apply its Source → Relevance → Worklist → Action steps to the orchestrator-supplied inputs, and produce that sub-skill's complete findings-report before moving on.
|
||||
- Do not collapse multiple sub-skills into one shared reasoning step. Each sub-skill has a distinct knowledge subset and a distinct evaluation procedure; sharing one rolled-up scan dilutes per-skill attention and causes leaves to silently underreport (this has been observed in production: leaf skills returned empty `findings[]` while their standalone runs against the same diff produced multiple matches).
|
||||
- The agent self-review pass is its own final iteration. Begin it only after every sub-skill in the worklist has completed and its sub-result is recorded.
|
||||
- Sub-skills are independent: re-walking the diff once per sub-skill is correct and expected. The output schema accommodates this — `sub-results` carries one entry per sub-skill, each a complete findings-report.
|
||||
|
||||
### Roll up sub-skill findings
|
||||
|
||||
For each sub-skill in the worklist:
|
||||
For each sub-skill in the worklist, executed one at a time per the discipline above:
|
||||
|
||||
1. Invoke the sub-skill with the orchestrator's inputs, passing only the subset each sub-skill declares in its `inputs`.
|
||||
2. Capture the sub-skill's complete findings-report verbatim and append it to `sub-results`.
|
||||
|
|
@ -71,7 +80,17 @@ For each sub-skill in the worklist:
|
|||
|
||||
### Agent self-review pass
|
||||
|
||||
After the sub-skill rollup, perform a self-review pass against the same task input using the agent's built-in BC and AL knowledge. BCQuality is an **additive** knowledge layer: it augments the agent's review judgement, it does not replace it. The goal of this pass is to surface defects the agent recognises on its own — bugs, anti-patterns, error-handling gaps, AL idioms — that the leaf sub-skills did not catch because no BCQuality knowledge file covers them yet.
|
||||
After every sub-skill has produced its sub-result, perform a self-review pass against the same task input using the agent's built-in BC and AL knowledge. BCQuality is an **additive** knowledge layer: it augments the agent's review judgement, it does not replace it. The goal of this pass is to surface defects the agent recognises on its own — bugs, anti-patterns, error-handling gaps, AL idioms — that the leaf sub-skills did not catch because no BCQuality knowledge file covers them yet.
|
||||
|
||||
This pass is mandatory. An empty agent-findings list is acceptable only when the diff is small enough that the leaves have provably exhausted the surface (in practice: PRs of ≤2 files with ≤30 changed lines and at least one sub-skill emitting findings). For larger diffs, returning an empty agent-findings list is a defect — the agent has built-in BC/AL knowledge that the leaves cannot supply, and refusing to apply it is the most common cause of parity loss against agents that do not have a BCQuality layer at all.
|
||||
|
||||
Before emitting the final report, walk these candidate categories explicitly against the diff and decide for each whether to emit a finding. This is a checklist, not an exhaustive list — it names patterns where the agent's general AL knowledge consistently outruns BCQuality coverage:
|
||||
|
||||
- **Architecture-level smells**: repeated `Record.Get` of the same key inside one call chain; large payloads streamed through memory when a streaming primitive exists; widely-scoped `Permissions = … = rimd` on codeunits that only read; `case` over an enum without an `else` branch (silent fall-through on unknown values); HTTP calls without `IsSuccessStatusCode` inspection; `tryFunction`-shaped procedures that swallow errors without surfacing them to telemetry.
|
||||
- **Error-handling gaps**: `Error()` built by `+` string concatenation; `if not Customer.Get(...) then Error(... + CustomerNo)`; failure paths that emit no telemetry; upgrade procedures that do not register `OnGetPerCompanyUpgradeTags` / `OnGetPerDatabaseUpgradeTags` event subscribers when they call `Set/HasUpgradeTag`.
|
||||
- **Magic constants** that encode a protocol or platform threshold (Graph 4 MB simple-upload cutoff, file-size limits, retry counts) without naming them through a `const`-suffixed Label.
|
||||
- **Privacy/telemetry surface**: PII bound into `Session.LogMessage` message text; placeholder telemetry event IDs (`'0000'`, `'TODO'`); `Locked = true` missing on Labels that carry URLs, JSON, or wire tokens.
|
||||
- **Resource lifecycle**: temporary records or HTTP message objects re-used across iterations without `Reset`/clearing; `Commit` inside a loop body.
|
||||
|
||||
For every candidate the agent identifies in this pass:
|
||||
|
||||
|
|
@ -85,7 +104,7 @@ For every candidate the agent identifies in this pass:
|
|||
- `id` is a skill-defined slug prefixed with `agent:` (for example, `agent:missing-error-handling-on-http-call`).
|
||||
- `confidence` capped at `medium`.
|
||||
- `message` is non-empty and self-contained, describing both the issue and a concrete recommendation. A consumer rendering the finding has no knowledge-file footer to fall back on.
|
||||
- `suggested-code` SHOULD be set when the fix is small and mechanical (e.g. removing a few unreachable lines, replacing a `Count() > 0` test with `not IsEmpty()`, declaring a missing `Label`). Omit it when the appropriate fix depends on context the agent cannot determine.
|
||||
- `suggested-code` SHOULD be set when the fix is small and mechanical (e.g. removing a few unreachable lines, replacing a `Count() > 0` test with `not IsEmpty()`, declaring a missing `Label`, adding an `else` branch to a `case` over an enum). Omit it when the appropriate fix depends on context the agent cannot determine.
|
||||
|
||||
Leaf sub-skills MUST NOT emit agent findings: their scope is bounded by the knowledge subset they evaluate. The self-review pass is a super-skill responsibility.
|
||||
|
||||
|
|
|
|||
|
|
@ -61,6 +61,8 @@ Set `confidence` to:
|
|||
- `medium` when detection relies on heuristics or when any frontmatter dimension was `unknown`.
|
||||
- `low` when the finding is an advisory derived only from applicability.
|
||||
|
||||
When the knowledge file ships an unambiguous `.good.al` companion that names exactly the correction the finding requires (and the diff context makes the substitution mechanical), set `findings[].suggested-code` to the literal replacement for the source lines indicated by `location`. The payload must be a verbatim replacement — no diff markers, no fences, no commentary — that the consumer can render as a one-click suggestion. Skip the field when the appropriate fix depends on context the skill cannot determine, or when more than one defensible replacement exists. See `skills/do.md` for the full contract.
|
||||
|
||||
Outcome selection:
|
||||
|
||||
- `completed` — the skill evaluated every worklist item; default when the skill finishes normally, including when the resulting `findings` array is empty.
|
||||
|
|
|
|||
|
|
@ -61,6 +61,8 @@ Set `confidence` to:
|
|||
- `medium` when detection relies on heuristics or when any frontmatter dimension was `unknown`.
|
||||
- `low` when the finding is an advisory derived only from applicability.
|
||||
|
||||
When the knowledge file ships an unambiguous `.good.al` companion that names exactly the correction the finding requires (and the diff context makes the substitution mechanical), set `findings[].suggested-code` to the literal replacement for the source lines indicated by `location`. The payload must be a verbatim replacement — no diff markers, no fences, no commentary — that the consumer can render as a one-click suggestion. Skip the field when the appropriate fix depends on context the skill cannot determine, or when more than one defensible replacement exists. See `skills/do.md` for the full contract.
|
||||
|
||||
Outcome selection:
|
||||
|
||||
- `completed` — the skill evaluated every worklist item; default when the skill finishes normally, including when the resulting `findings` array is empty.
|
||||
|
|
|
|||
|
|
@ -61,6 +61,8 @@ Set `confidence` to:
|
|||
- `medium` when detection relies on heuristics or when any frontmatter dimension was `unknown`.
|
||||
- `low` when the finding is an advisory derived only from applicability.
|
||||
|
||||
When the knowledge file ships an unambiguous `.good.al` companion that names exactly the correction the finding requires (and the diff context makes the substitution mechanical), set `findings[].suggested-code` to the literal replacement for the source lines indicated by `location`. The payload must be a verbatim replacement — no diff markers, no fences, no commentary — that the consumer can render as a one-click suggestion. Skip the field when the appropriate fix depends on context the skill cannot determine, or when more than one defensible replacement exists. See `skills/do.md` for the full contract.
|
||||
|
||||
Outcome selection:
|
||||
|
||||
- `completed` — the skill evaluated every worklist item; default when the skill finishes normally, including when the resulting `findings` array is empty.
|
||||
|
|
|
|||
|
|
@ -59,6 +59,8 @@ Set `confidence` to:
|
|||
- `medium` when detection relies on heuristics or when any frontmatter dimension was `unknown`.
|
||||
- `low` when the finding is an advisory derived only from applicability.
|
||||
|
||||
When the knowledge file ships an unambiguous `.good.al` companion that names exactly the correction the finding requires (and the diff context makes the substitution mechanical), set `findings[].suggested-code` to the literal replacement for the source lines indicated by `location`. The payload must be a verbatim replacement — no diff markers, no fences, no commentary — that the consumer can render as a one-click suggestion. Skip the field when the appropriate fix depends on context the skill cannot determine, or when more than one defensible replacement exists. See `skills/do.md` for the full contract.
|
||||
|
||||
Outcome selection:
|
||||
|
||||
- `completed` — the skill evaluated every worklist item.
|
||||
|
|
|
|||
|
|
@ -59,6 +59,8 @@ Set `confidence` to:
|
|||
- `medium` when detection relies on heuristics (judging whether a caption is a noun phrase or a sentence phrase) or when any frontmatter dimension was `unknown`.
|
||||
- `low` when the finding is an advisory derived only from applicability.
|
||||
|
||||
When the knowledge file ships an unambiguous `.good.al` companion that names exactly the correction the finding requires (and the diff context makes the substitution mechanical), set `findings[].suggested-code` to the literal replacement for the source lines indicated by `location`. The payload must be a verbatim replacement — no diff markers, no fences, no commentary — that the consumer can render as a one-click suggestion. Skip the field when the appropriate fix depends on context the skill cannot determine, or when more than one defensible replacement exists. See `skills/do.md` for the full contract.
|
||||
|
||||
Outcome selection:
|
||||
|
||||
- `completed` — the skill evaluated every worklist item.
|
||||
|
|
|
|||
|
|
@ -61,6 +61,8 @@ Set `confidence` to:
|
|||
- `medium` when detection relies on heuristics or when any frontmatter dimension was `unknown`.
|
||||
- `low` when the finding is an advisory derived only from applicability.
|
||||
|
||||
When the knowledge file ships an unambiguous `.good.al` companion that names exactly the correction the finding requires (and the diff context makes the substitution mechanical), set `findings[].suggested-code` to the literal replacement for the source lines indicated by `location`. The payload must be a verbatim replacement — no diff markers, no fences, no commentary — that the consumer can render as a one-click suggestion. Skip the field when the appropriate fix depends on context the skill cannot determine, or when more than one defensible replacement exists. See `skills/do.md` for the full contract.
|
||||
|
||||
Outcome selection:
|
||||
|
||||
- `completed` — the skill evaluated every worklist item.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue