From 2feb01072ceaaeb61d502c241876ee5509f5c53d Mon Sep 17 00:00:00 2001 From: David Burg <12040431+daviburg@users.noreply.github.com> Date: Fri, 25 Sep 2026 12:14:45 -0700 Subject: [PATCH 1/2] Guide public release note and generator evidence Prevent internal BPM links in new public release entries, keep mirrored release notes consistent, verify request wire fixtures and merged generator provenance, and preserve PR body formatting. Co-authored-by: Dobby --- .github/copilot-instructions.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index fec1320..5bcb633 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -34,9 +34,31 @@ references and every distinct reachable wire property. - Add focused wire serialization tests for collisions and semantic compilation tests when generated helper or factory signatures can collide. Syntax parsing alone does not catch duplicate C# parameters. +- For request serialization tests, resolve the operation's request schema in the + pinned Swagger rather than inferring the wire shape from a similarly named + response model. Use valid required nested fields and parameter formats, and + assert the serialized request; a mocked success response alone proves little. +- Check that the exact generator commit used for regeneration landed in BPM + `master`. A PR can be merged before later commits reach its source branch; + those later commits need a separate upstream PR even if downstream clients + were already generated from them. - For shared naming or reachability changes, run a same-revision catalog sweep and document the full blast radius before choosing a narrow demonstration client. +### Public Release Notes and PR Descriptions + +- In new or edited entries in public `CHANGELOG.md` and `release_notes.md`, + describe the customer-visible change and link public issues or documentation + when useful. Do not link internal AzureUX-BPM repositories or PRs there; + record generator commits, pinned Swagger hashes, and internal PR links in + the GitHub PR description for reviewers instead. Leave unrelated historical + entries alone. +- If an entry appears in both release files, keep its content consistent and + check both files before submitting the PR. +- Submit PR descriptions as multiline Markdown using `gh pr create --body-file` + and read the body back from GitHub. PowerShell can flatten line breaks when + CLI output is captured without preserving it as one string. + ## Quick Reference: Coding Style Rules ### File Structure From 6d548f7eb670a5563f7871385e747d121c8a2e00 Mon Sep 17 00:00:00 2001 From: David Burg <12040431+daviburg@users.noreply.github.com> Date: Fri, 25 Sep 2026 13:43:16 -0700 Subject: [PATCH 2/2] Document PR description edits as multiline Markdown Cover updates as well as creation with --body-file and read back the submitted PR body to catch flattened formatting. Co-authored-by: Dobby --- .github/copilot-instructions.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 5bcb633..a672636 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -56,8 +56,9 @@ references and every distinct reachable wire property. - If an entry appears in both release files, keep its content consistent and check both files before submitting the PR. - Submit PR descriptions as multiline Markdown using `gh pr create --body-file` - and read the body back from GitHub. PowerShell can flatten line breaks when - CLI output is captured without preserving it as one string. + for new PRs or `gh pr edit --body-file` for updates. Read the body back from + GitHub; PowerShell can flatten line breaks when CLI output is captured without + preserving it as one string. ## Quick Reference: Coding Style Rules