Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-08-06 17:36:53 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Improve PR-review parity: suggestion blocks, missing KB articles, privacy cross-ref

Browse source 
Adds the contract field, skill instructions, and two knowledge articles
that BCAppsBCQuality's PR-review agent needs to match (and exceed) the
coverage of the embedded review agent in BCAppsCampAIRHack:

skills/do.md
- New optional findings[].suggested-code field. Documents what it MUST
  contain (a literal line-replacement payload) and when to emit it.

microsoft/skills/review/al-code-review.md
- Instructs both the agent self-review pass and rolled-up sub-skill
  findings to populate suggested-code when the fix is mechanical.
- Lists examples (dead code removal, Count > 0 -> IsEmpty, object-scope
  Label) that map to issues observed in the parity comparison.

microsoft/knowledge/style/telemetry-event-id-stable-unique.{md,bad.al,good.al}
- New knowledge article: telemetry event IDs must be stable, unique,
  and non-placeholder. Closes a gap surfaced by the parity comparison.

microsoft/knowledge/style/labels-declared-at-object-scope.{md,bad.al,good.al}
- New knowledge article: Labels must live in the object-level var
  block, not in procedure-local var blocks. Closes the second gap.

microsoft/knowledge/privacy/no-pii-in-telemetry-message-string.md
- Adds an explicit note that changing DataClassification alone does not
  make embedding PII into the message string acceptable, plus links to
  the two adjacent privacy articles. Resolves the privacy advice the
  parity comparison flagged as ambiguous.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
Jesper Schulz-Wedde 2026-05-27 15:45:49 +02:00
parent 4d59fb73bc
commit b11f3ec506
9 changed files with 130 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

7
microsoft/knowledge/privacy/no-pii-in-telemetry-message-string.md
View file

@ -17,8 +17,15 @@ application-area: [all]
Keep the telemetry message a static, non-personal string ("Customer record processed", "Error processing uploaded file"). When structured context is genuinely needed, attach it through custom dimensions, where individual values can be reviewed and classified at the dimension level rather than baked into a free-text message.
If a pseudonymous identifier (record `No.`, primary key value) genuinely belongs in the diagnostic, prefer attaching it through a custom dimension and set the call's `DataClassification` to match the data actually shipped — `EndUserPseudonymousIdentifiers` for pseudonymous IDs, `CustomerContent` for content-bearing telemetry. Changing the `DataClassification` alone does **not** make embedding a customer name into the message string acceptable; the data still ships in the message, and downstream consumers still see the literal string.
See sample: `no-pii-in-telemetry-message-string.good.al`.
## Related
- `session-logmessage-requires-dataclassification.md` — every `Session.LogMessage` call must specify `DataClassification`; choose the value to match the actual data shipped, not the value that makes the entry retained the longest.
- `featuretelemetry-customdimensions-no-pii.md` — custom dimensions are the right surface for structured context, but they have their own PII rules.
## Anti Pattern
`Session.LogMessage('0000', StrSubstNo('Processed %1', Customer.Name), ...)` — the customer name is in telemetry the moment the line runs. Detection signal: a `StrSubstNo` whose result is the second argument of `Session.LogMessage`. The same shape with `FileName`, `EmployeeCode`, or any record field is the same problem.