From 408986615670d31467e7f19f47757a0be732f6fc Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Tue, 26 May 2026 13:16:22 +0200
Subject: [PATCH 01/17] Introduce support for agentic autofix

---
 docs/copilot-instructions.md | 157 +++++++++++++++++++++++++++++++++++
 docs/user_manual.md          |   1 +
 2 files changed, 158 insertions(+)
 create mode 100644 docs/copilot-instructions.md

diff --git a/docs/copilot-instructions.md b/docs/copilot-instructions.md
new file mode 100644
index 000000000..e94bcbe6a
--- /dev/null
+++ b/docs/copilot-instructions.md
@@ -0,0 +1,157 @@
+[//]: # "Include this file in the repository to provide instructions to GitHub Copilot AUtofix. For more information, see https://docs.github.com/copilot/copilot-for-business/copilot-instructions."
+# GitHub Copilot instructions
+
+This file contains repository-wide guidance for GitHub Copilot. Each top-level
+section below configures Copilot for a specific use case in this repository.
+Add further top-level sections as needed (general coding conventions, review
+guidance, etc.).
+
+## Agentic autofix for CodeQL Coding Standards
+
+This section configures GitHub Copilot (in particular, Copilot **agentic
+autofix**) when it generates pull requests to remediate alerts produced by the
+[CodeQL Coding Standards](https://github.com/github/codeql-coding-standards/)
+project. It applies to alerts for any of the supported standards (MISRA C,
+MISRA C++, AUTOSAR C++, CERT C, CERT C++).
+
+### 1. Reference material — where to learn each rule
+
+Before proposing a fix, consult the rule’s authoritative implementation as well as the corresponding compliant and non-compliant code patterns available as test cases in the CodeQL Coding Standards [`github/codeql-coding-standards`](https://github.com/github/codeql-coding-standards/)
+repository. That repository is the single source of truth for what the query
+detects and what compliant code looks like.
+
+Project layout (per language / standard):
+
+```
+<language>/<standard>/src/rules/<rule-id>/    # query source (.ql) and rule help (.md, .qhelp)
+<language>/<standard>/test/rules/<rule-id>/   # test cases, with COMPLIANT / NON_COMPLIANT markers
+```
+
+When generating a fix:
+
+1. Locate the rule directory matching the alert’s rule id / query id.
+2. Read the `.md` / `.qhelp` help file in `src/rules/<rule-id>/` to understand
+   the intent and the recommended remediation.
+3. Read the files in `test/rules/<rule-id>/`. Lines (or blocks) annotated with
+   `// COMPLIANT` show patterns that pass the query; lines annotated with
+   `// NON_COMPLIANT` show patterns that trigger the query. Use these as the
+   ground truth for what the fixed code must look like.
+
+The full list of supported rules per standard is published as
+`supported_rules_list_<version>.csv` / `.md` in each
+[release](https://github.com/github/codeql-coding-standards/releases).
+
+### 2. Fix discipline — keep changes minimal and standards-compliant
+
+- **Minimum diff.** Modify the smallest possible amount of code that
+  eliminates the alert. Do not refactor surrounding code, rename symbols,
+  reformat unrelated lines, or change public APIs unless strictly required to
+  satisfy the rule.
+- **No drive-by changes.** Do not add features, fix unrelated warnings, change
+  build flags, update dependencies, or “improve” code that the alert does not
+  point at.
+- **New code must comply with the same standard.** Any code introduced by the
+  fix must itself satisfy the coding standard being verified (e.g. MISRA C++
+  2023). Cross-check the inserted code against the COMPLIANT examples in the
+  corresponding `test/rules/<rule-id>/` directory and against neighbouring
+  rules that are obviously relevant (e.g. don’t fix an integer-conversion rule
+  by introducing a cast that violates a different MISRA rule).
+- **Match the project’s existing style.** Follow the conventions visible in
+  the surrounding source files (naming, headers, namespaces, C++ standard
+  level, use of `enum class`, etc.).
+- **Preserve behaviour.** A coding-standards fix is a refactor at the source
+  level, not a functional change. The fix must not alter observable runtime
+  behaviour unless the rule explicitly targets undefined or implementation-
+  defined behaviour that has to change.
+
+### 3. Do not touch build outputs, generated files, or `.gitignore`
+
+Autofix pull requests must only change source files that are part of the
+checked-in project. They must **not** include:
+
+- Build directories or files generated during compilation.
+- Editor / IDE state (`.vscode/`, `.idea/`, `.DS_Store`, etc.).
+- **`.gitignore` itself.** Do not add, remove, or reorder entries in
+  `.gitignore` as part of an autofix.
+- The CodeQL workflow files under `.github/workflows/` (e.g. `codeql.yml`).
+  Suppression or scope changes must use the deviation mechanism (see §4),
+  not workflow edits.
+
+### 4. Deviations — respect project policy and reference it in fixes
+
+A project under analysis may declare that a rule, file, region, or specific
+construct is intentionally exempt from a coding standard. Such deviations are
+not always expressed through the same mechanism: a project may use the
+**standard CodeQL Coding Standards deviation mechanism**, a **custom
+annotation or attribute** convention, **in-source line / block comments**,
+or a **separate documentation file** (for example a `DEVIATIONS.md`,
+`MISRA-deviations.md`, compliance matrix, or similar).
+
+The fix proposal must take what is found into account and treat it as an existing deviation if it clearly covers the alert location and rule.
+
+If the alert location is covered by an existing deviation:
+
+- **Still propose a code fix** that would make the location compliant by
+  default. Authors may have left the deviation in place pragmatically and
+  may prefer a real fix.
+- **In the pull request description, explicitly state** that a matching
+  deviation already exists in the project, citing the file path and the
+  relevant `rule-id` / `query-id` / `permit-id` / `code-identifier` / scope
+  (paths or markers) so reviewers can decide whether to accept the fix or
+  keep the deviation.
+- Do not silently delete or weaken an existing deviation, permit, or
+  re-categorization entry as part of the fix.
+
+### 5. False positives — propose a deviation, do not stay silent
+
+Copilot autofix normally refrains from opening a pull request when it
+considers an alert to be a false positive. For CodeQL Coding Standards alerts
+this behaviour is **overridden**: a false-positive determination must still
+result in a pull request, and that pull request must record the decision
+using the project’s deviation mechanism.
+
+The CodeQL Coding Standards project supports an explicit deviation mechanism,
+fully documented in
+[`docs/user_manual.md`](https://github.com/github/codeql-coding-standards/blob/main/docs/user_manual.md)
+(sections “Applying deviations”, “Deviation records”, “Deviation permits”,
+“Guideline re-categorization plan”).
+When an alert is judged to be a false positive, the autofix PR must:
+
+1. **Not modify the flagged code** to “work around” the alert.
+2. **Add or update a deviation record** that scopes precisely to the alert.
+   Prefer the narrowest scope that is appropriate:
+   - a `code-identifier` deviation referenced from the exact line, statement,
+     function, or block, via an attribute
+     (`[[codeql::<standard>_deviation("...")]]`) or a comment marker
+     (`// codeql::<standard>_deviation(...)`,
+     `// codeql::<standard>_deviation_next_line(...)`, or a
+     `..._deviation_begin` / `..._deviation_end` pair); or
+   - a `paths:`-scoped deviation in `coding-standards.yml` when a whole file
+     or directory is affected;
+   - a project-wide deviation only when the rule is genuinely inapplicable to
+     the project.
+   Use `<standard>` ∈ {`misra`, `autosar`, `cert`} as appropriate for the
+   alert.
+3. **Populate the deviation record** with at least:
+   - `rule-id` matching the alert’s rule identifier;
+   - `query-id` matching the alert’s `@id` (when the deviation is meant to
+     cover a single sub-query of the rule);
+   - a clear `justification` explaining why the alert is a false positive
+     (what the query missed, why the code is in fact compliant or safe);
+   - `scope`, `background`, and `requirements` when they help a reviewer
+     audit the decision;
+   - a `raised-by` entry (and leave `approved-by` for a human reviewer).
+4. **Place the deviation entry** in an existing `coding-standards.yml` if one
+   exists in an appropriate directory; otherwise create one at the most
+   specific directory whose subtree is affected. When using a `permit-id`,
+   reference an existing permit if one matches; do not invent new permit IDs
+   unless necessary.
+5. **In the PR description**, explicitly state that the alert is being
+   handled as a false positive via a deviation (not by code change), link to
+   the
+   [deviation mechanism documentation](https://github.com/github/codeql-coding-standards/blob/main/docs/user_manual.md#applying-deviations),
+   and summarise the justification so a reviewer can approve or reject it.
+
+A false-positive PR should therefore contain **only** the deviation entry
+and/or the in-source deviation marker — no changes to logic, no edits to
+build outputs, and no edits to `.gitignore`.
diff --git a/docs/user_manual.md b/docs/user_manual.md
index c58b8c25f..cee8ee965 100644
--- a/docs/user_manual.md
+++ b/docs/user_manual.md
@@ -646,6 +646,7 @@ The only use cases that will be certified under ISO 26262 are those listed above
 
 - Creating databases and running the CodeQL Coding Standards queries with the [CodeQL Action](https://github.com/github/codeql-action) (for GitHub Actions CI/CD system).
 - Uploading the SARIF results files for a CodeQL Coding Standards analysis to the GitHub [Code Scanning](https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning) feature.
+- Using [Agentic Autofix in Code Scanning](https://docs.github.com/en/code-security/concepts/code-scanning/copilot-autofix-for-code-scanning) (use the reference [copilot-instructions.md](copilot-instructions.md) file provided). 
 
 ### Hazard and risk analysis
 

From 13c43e20336df327a1f13432ad44f0649ae36937 Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Tue, 2 Jun 2026 19:48:08 +0200
Subject: [PATCH 02/17] Update copilot-instructions.md

---
 docs/copilot-instructions.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/copilot-instructions.md b/docs/copilot-instructions.md
index e94bcbe6a..0c62bdf7e 100644
--- a/docs/copilot-instructions.md
+++ b/docs/copilot-instructions.md
@@ -1,4 +1,4 @@
-[//]: # "Include this file in the repository to provide instructions to GitHub Copilot AUtofix. For more information, see https://docs.github.com/copilot/copilot-for-business/copilot-instructions."
+[//]: # "Include this file in the repository to provide instructions to GitHub Copilot Autofix. For more information, see https://docs.github.com/copilot/copilot-for-business/copilot-instructions."
 # GitHub Copilot instructions
 
 This file contains repository-wide guidance for GitHub Copilot. Each top-level
@@ -67,7 +67,7 @@ The full list of supported rules per standard is published as
 ### 3. Do not touch build outputs, generated files, or `.gitignore`
 
 Autofix pull requests must only change source files that are part of the
-checked-in project. They must **not** include:
+checked-in project or add deviation records. They must **not** include:
 
 - Build directories or files generated during compilation.
 - Editor / IDE state (`.vscode/`, `.idea/`, `.DS_Store`, etc.).

From 0d46c8c23defcee45b37b12973a0b1e67fabd025 Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Tue, 2 Jun 2026 19:59:34 +0200
Subject: [PATCH 03/17] Update docs/copilot-instructions.md

Co-authored-by: Michael R Fairhurst <MichaelRFairhurst@github.com>
---
 docs/copilot-instructions.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/copilot-instructions.md b/docs/copilot-instructions.md
index 0c62bdf7e..cf3fc122f 100644
--- a/docs/copilot-instructions.md
+++ b/docs/copilot-instructions.md
@@ -85,7 +85,7 @@ not always expressed through the same mechanism: a project may use the
 **standard CodeQL Coding Standards deviation mechanism**, a **custom
 annotation or attribute** convention, **in-source line / block comments**,
 or a **separate documentation file** (for example a `DEVIATIONS.md`,
-`MISRA-deviations.md`, compliance matrix, or similar).
+`MISRA-deviations.md`, `coding-standards.yml`, compliance matrix, or similar).
 
 The fix proposal must take what is found into account and treat it as an existing deviation if it clearly covers the alert location and rule.
 

From 04c5cab0e18c46996790f54ff2b2ad0263a15b04 Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Wed, 17 Jun 2026 17:54:48 +0200
Subject: [PATCH 04/17] Improved instructions

---
 docs/copilot-instructions.md | 116 +++++++++++++++++++++--------------
 1 file changed, 71 insertions(+), 45 deletions(-)

diff --git a/docs/copilot-instructions.md b/docs/copilot-instructions.md
index cf3fc122f..e4a788a79 100644
--- a/docs/copilot-instructions.md
+++ b/docs/copilot-instructions.md
@@ -1,4 +1,5 @@
 [//]: # "Include this file in the repository to provide instructions to GitHub Copilot Autofix. For more information, see https://docs.github.com/copilot/copilot-for-business/copilot-instructions."
+
 # GitHub Copilot instructions
 
 This file contains repository-wide guidance for GitHub Copilot. Each top-level
@@ -8,16 +9,17 @@ guidance, etc.).
 
 ## Agentic autofix for CodeQL Coding Standards
 
-This section configures GitHub Copilot (in particular, Copilot **agentic
-autofix**) when it generates pull requests to remediate alerts produced by the
-[CodeQL Coding Standards](https://github.com/github/codeql-coding-standards/)
-project. It applies to alerts for any of the supported standards (MISRA C,
-MISRA C++, AUTOSAR C++, CERT C, CERT C++).
+This section configures **Agentic Autofix** when generating pull requests to
+remediate alerts produced by [CodeQL Coding Standards](https://github.com/github/codeql-coding-standards/).
+It applies to alerts for any of the supported standards (MISRA C, MISRA C++,
+AUTOSAR C++, CERT C, CERT C++).
 
 ### 1. Reference material — where to learn each rule
 
-Before proposing a fix, consult the rule’s authoritative implementation as well as the corresponding compliant and non-compliant code patterns available as test cases in the CodeQL Coding Standards [`github/codeql-coding-standards`](https://github.com/github/codeql-coding-standards/)
-repository. That repository is the single source of truth for what the query
+Before proposing a fix, consult the rule’s authoritative implementation as well
+as the corresponding compliant and non-compliant code patterns available as
+test cases in the [`github/codeql-coding-standards` repository](https://github.com/github/codeql-coding-standards/).
+That repository is the single source of truth for what the query
 detects and what compliant code looks like.
 
 Project layout (per language / standard):
@@ -50,59 +52,83 @@ The full list of supported rules per standard is published as
 - **No drive-by changes.** Do not add features, fix unrelated warnings, change
   build flags, update dependencies, or “improve” code that the alert does not
   point at.
+- **Do not attempt at fixing design issues.** A fix should not attempt to
+  “improve” the design of the code or address architectural issues.
+  Always verify that the code section around the alert is intended to follow
+  the standard and add a comment.
+  The presence of certain design issues (e.g. dynamic memory allocation) might
+  indicate that the code is not intended to be compliant with the standard, and
+  that a deviation should be added instead of a code fix.
 - **New code must comply with the same standard.** Any code introduced by the
   fix must itself satisfy the coding standard being verified (e.g. MISRA C++
   2023). Cross-check the inserted code against the COMPLIANT examples in the
   corresponding `test/rules/<rule-id>/` directory and against neighbouring
   rules that are obviously relevant (e.g. don’t fix an integer-conversion rule
   by introducing a cast that violates a different MISRA rule).
-- **Match the project’s existing style.** Follow the conventions visible in
-  the surrounding source files (naming, headers, namespaces, C++ standard
-  level, use of `enum class`, etc.).
-- **Preserve behaviour.** A coding-standards fix is a refactor at the source
-  level, not a functional change. The fix must not alter observable runtime
-  behaviour unless the rule explicitly targets undefined or implementation-
-  defined behaviour that has to change.
-
-### 3. Do not touch build outputs, generated files, or `.gitignore`
-
-Autofix pull requests must only change source files that are part of the
-checked-in project or add deviation records. They must **not** include:
-
-- Build directories or files generated during compilation.
-- Editor / IDE state (`.vscode/`, `.idea/`, `.DS_Store`, etc.).
-- **`.gitignore` itself.** Do not add, remove, or reorder entries in
-  `.gitignore` as part of an autofix.
-- The CodeQL workflow files under `.github/workflows/` (e.g. `codeql.yml`).
-  Suppression or scope changes must use the deviation mechanism (see §4),
-  not workflow edits.
-
-### 4. Deviations — respect project policy and reference it in fixes
-
-A project under analysis may declare that a rule, file, region, or specific
-construct is intentionally exempt from a coding standard. Such deviations are
+- **Preserve safe and desired functional behavior.** ensure the resulting code
+  handles all reasonable real-world scenarios as the code originally intended.
+  This may involve precisely maintaining the existing code behavior, or it may
+  involve fixing subtle or rare bugs, for instance dangerous overflows,
+  that the existing code does not handle and the rule is designed to detect.
+- **Fix dangerous bugs** If the alert is flagging unsafe or undefined behavior,
+  critically examine how that safety issue in the code should be properly fixed.
+  Add detections and error handling if necessary to make the code safe under
+  all conditions without introducing unnecessary complexity. Follow existing
+  project guidelines on how to handle rare, dangerous, or unexpected scenarios
+  that occur at runtime.
+- **Thoroughly explain analysis and functional changes.** If the alert does not
+  introduce any unwanted behavior and the change is functionally equivalent,
+  explain your thinking, and clearly show that the code before was safe, and
+  that the new code is exactly equivalent in behavior.
+  If there was a dangerous edge case or condition, explain exactly how that
+  scenario would create problems in the code and how the fix will prevent such
+  issues and improve the safety and quality of the codebase.
+
+### 3. Deviations — respect project policy and reference it in fixes
+
+A project may declare that a rule, file, region, or specific construct is
+intentionally exempt from a coding standard. Such deviations are
 not always expressed through the same mechanism: a project may use the
-**standard CodeQL Coding Standards deviation mechanism**, a **custom
-annotation or attribute** convention, **in-source line / block comments**,
+**standard CodeQL Coding Standards deviation mechanism**, a
+**custom annotation or attribute** convention,
+**in-source line / block comments**,
 or a **separate documentation file** (for example a `DEVIATIONS.md`,
 `MISRA-deviations.md`, `coding-standards.yml`, compliance matrix, or similar).
 
-The fix proposal must take what is found into account and treat it as an existing deviation if it clearly covers the alert location and rule.
+Locate the deviations file and explicitly search for matching deviations
+before proposing code changes.
+The fix proposal must take what is found into account and treat it as an
+existing deviation if it clearly covers the alert location and rule.
 
 If the alert location is covered by an existing deviation:
-
-- **Still propose a code fix** that would make the location compliant by
-  default. Authors may have left the deviation in place pragmatically and
-  may prefer a real fix.
-- **In the pull request description, explicitly state** that a matching
+- Look for existing deviations of that rule, and see if any should apply
+- In the pull request description, explicitly state that a matching
   deviation already exists in the project, citing the file path and the
   relevant `rule-id` / `query-id` / `permit-id` / `code-identifier` / scope
   (paths or markers) so reviewers can decide whether to accept the fix or
   keep the deviation.
 - Do not silently delete or weaken an existing deviation, permit, or
   re-categorization entry as part of the fix.
-
-### 5. False positives — propose a deviation, do not stay silent
+- Propose a code fix that would make the location compliant by
+  default. Authors may have left the deviation in place pragmatically and
+  may prefer a real fix.
+- Consider whether an existing code identifier should be used
+- Consider whether a file-wide exception should be used
+- Consider whether a new code identifier should be used
+- If using a code-identifier, look for examples to determine whether 
+  to use [[attribute]] form
+- If using an [[attribute]], look for project formatting configurations or code
+  examples to determine how to format the attribute relative to its declaration
+- When using deviation comments, consider project formatting, the specific
+  violation in question, and other example deviation comments in the project to
+  determine whether to use same-line, next-line, or begin/end comment deviations
+  Project formatting configuration may be .clang-format, etc.
+
+### 4. False positives — propose a deviation, do not stay silent
+
+Precedence: if an alert is judged to be a false positive, the false-positive
+workflow in this section overrides any guidance above about proposing a code
+fix when a deviation exists.
 
 Copilot autofix normally refrains from opening a pull request when it
 considers an alert to be a false positive. For CodeQL Coding Standards alerts
@@ -130,8 +156,8 @@ When an alert is judged to be a false positive, the autofix PR must:
      or directory is affected;
    - a project-wide deviation only when the rule is genuinely inapplicable to
      the project.
-   Use `<standard>` ∈ {`misra`, `autosar`, `cert`} as appropriate for the
-   alert.
+     Use `<standard>` ∈ {`misra`, `autosar`, `cert`} as appropriate for the
+     alert.
 3. **Populate the deviation record** with at least:
    - `rule-id` matching the alert’s rule identifier;
    - `query-id` matching the alert’s `@id` (when the deviation is meant to
@@ -149,7 +175,7 @@ When an alert is judged to be a false positive, the autofix PR must:
 5. **In the PR description**, explicitly state that the alert is being
    handled as a false positive via a deviation (not by code change), link to
    the
-   [deviation mechanism documentation](https://github.com/github/codeql-coding-standards/blob/main/docs/user_manual.md#applying-deviations),
+  [deviation mechanism documentation](https://github.com/github/codeql-coding-standards/blob/main/docs/user_manual.md#applying-deviations),
    and summarise the justification so a reviewer can approve or reject it.
 
 A false-positive PR should therefore contain **only** the deviation entry

From f494dde37b1fcc55f2d19788bd4fa54a400bbe65 Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Wed, 17 Jun 2026 19:13:14 +0200
Subject: [PATCH 05/17] Fix typos and enhance clarity in instructions

Corrected typos and improved clarity in Copilot instructions.
---
 docs/copilot-instructions.md | 148 +++++++++++++++--------------------
 1 file changed, 61 insertions(+), 87 deletions(-)

diff --git a/docs/copilot-instructions.md b/docs/copilot-instructions.md
index e4a788a79..a315aaaad 100644
--- a/docs/copilot-instructions.md
+++ b/docs/copilot-instructions.md
@@ -1,5 +1,4 @@
-[//]: # "Include this file in the repository to provide instructions to GitHub Copilot Autofix. For more information, see https://docs.github.com/copilot/copilot-for-business/copilot-instructions."
-
+[//]: # "Include this file in the repository to provide instructions to GitHub Copilot AUtofix. For more information, see https://docs.github.com/copilot/copilot-for-business/copilot-instructions."
 # GitHub Copilot instructions
 
 This file contains repository-wide guidance for GitHub Copilot. Each top-level
@@ -7,20 +6,17 @@ section below configures Copilot for a specific use case in this repository.
 Add further top-level sections as needed (general coding conventions, review
 guidance, etc.).
 
-## Agentic autofix for CodeQL Coding Standards
+## Autofix for CodeQL Coding Standards
 
-This section configures **Agentic Autofix** when generating pull requests to
-remediate alerts produced by [CodeQL Coding Standards](https://github.com/github/codeql-coding-standards/).
-It applies to alerts for any of the supported standards (MISRA C, MISRA C++,
-AUTOSAR C++, CERT C, CERT C++).
+This section configures GitHub Copilot **Autofix** when it generates pull requests to remediate alerts produced by the
+[CodeQL Coding Standards](https://github.com/github/codeql-coding-standards/)
+project. It applies to alerts for any of the supported standards (MISRA C,
+MISRA C++, AUTOSAR C++, CERT C, CERT C++).
 
 ### 1. Reference material — where to learn each rule
 
-Before proposing a fix, consult the rule’s authoritative implementation as well
-as the corresponding compliant and non-compliant code patterns available as
-test cases in the [`github/codeql-coding-standards` repository](https://github.com/github/codeql-coding-standards/).
-That repository is the single source of truth for what the query
-detects and what compliant code looks like.
+Before proposing a fix, consult the rule’s authoritative implementation as well as the corresponding compliant and non-compliant code patterns available as test cases in the CodeQL Coding Standards [`github/codeql-coding-standards`](https://github.com/github/codeql-coding-standards/)
+repository. That repository is the single source of truth for what the query detects and what compliant code looks like.
 
 Project layout (per language / standard):
 
@@ -29,6 +25,8 @@ Project layout (per language / standard):
 <language>/<standard>/test/rules/<rule-id>/   # test cases, with COMPLIANT / NON_COMPLIANT markers
 ```
 
+When referring to the alerts you are addressing, include a clickable link.
+
 When generating a fix:
 
 1. Locate the rule directory matching the alert’s rule id / query id.
@@ -46,89 +44,65 @@ The full list of supported rules per standard is published as
 ### 2. Fix discipline — keep changes minimal and standards-compliant
 
 - **Minimum diff.** Modify the smallest possible amount of code that
-  eliminates the alert. Do not refactor surrounding code, rename symbols,
+  eliminates the assigned alerts. Do not refactor surrounding code, rename symbols,
   reformat unrelated lines, or change public APIs unless strictly required to
   satisfy the rule.
 - **No drive-by changes.** Do not add features, fix unrelated warnings, change
   build flags, update dependencies, or “improve” code that the alert does not
   point at.
-- **Do not attempt at fixing design issues.** A fix should not attempt to
-  “improve” the design of the code or address architectural issues.
-  Always verify that the code section around the alert is intended to follow
-  the standard and add a comment.
-  The presence of certain design issues (e.g. dynamic memory allocation) might
-  indicate that the code is not intended to be compliant with the standard, and
-  that a deviation should be added instead of a code fix.
-- **New code must comply with the same standard.** Any code introduced by the
-  fix must itself satisfy the coding standard being verified (e.g. MISRA C++
-  2023). Cross-check the inserted code against the COMPLIANT examples in the
-  corresponding `test/rules/<rule-id>/` directory and against neighbouring
-  rules that are obviously relevant (e.g. don’t fix an integer-conversion rule
-  by introducing a cast that violates a different MISRA rule).
-- **Preserve safe and desired functional behavior.** ensure the resulting code
-  handles all reasonable real-world scenarios as the code originally intended.
-  This may involve precisely maintaining the existing code behavior, or it may
-  involve fixing subtle or rare bugs, for instance dangerous overflows,
-  that the existing code does not handle and the rule is designed to detect.
-- **Fix dangerous bugs** If the alert is flagging unsafe or undefined behavior,
-  critically examine how that safety issue in the code should be properly fixed.
-  Add detections and error handling if necessary to make the code safe under
-  all conditions without introducing unnecessary complexity. Follow existing
-  project guidelines on how to handle rare, dangerous, or unexpected scenarios
-  that occur at runtime.
-- **Thoroughly explain analysis and functional changes.** If the alert does not
-  introduce any unwanted behavior and the change is functionally equivalent,
-  explain your thinking, and clearly show that the code before was safe, and
-  that the new code is exactly equivalent in behavior.
-  If there was a dangerous edge case or condition, explain exactly how that
-  scenario would create problems in the code and how the fix will prevent such
-  issues and improve the safety and quality of the codebase.
-
-### 3. Deviations — respect project policy and reference it in fixes
-
-A project may declare that a rule, file, region, or specific construct is
-intentionally exempt from a coding standard. Such deviations are
+- **New code must comply with the analyzed coding standard.** Any code introduced by the
+  fix must itself satisfy every rule of the coding standard being verified
+  (e.g. all MISRA C rules). Do not limit the review to the rule targeted by
+  the alert: iterate over the full supported rules list for the applicable
+  standard and, for each rule, read its help file
+  (`<language>/<standard>/src/rules/<rule-id>/<rule-id>.md` or `.qhelp`) to
+  understand its intent, then verify that the introduced code does not violate
+  it. Cross-check against the COMPLIANT examples in each rule's
+  `test/rules/<rule-id>/` directory.
+- **Match the project’s existing style.** Follow the conventions visible in
+  the surrounding source files (naming, headers, namespaces, C++ standard
+  level, use of `enum class`, etc.).
+- **Preserve behaviour.** A coding-standards fix is a refactor at the source
+  level, not a functional change. The fix must not alter observable runtime
+  behaviour unless the rule explicitly targets undefined or implementation-
+  defined behaviour that has to change.
+
+### 3. Do not touch build outputs, generated files, or `.gitignore`
+
+Autofix pull requests must only change source files that are part of the
+checked-in project. They must **not** include:
+
+- Build directories or files generated during compilation.
+- Editor / IDE state (`.vscode/`, `.idea/`, `.DS_Store`, etc.).
+- **`.gitignore` itself.** Do not add, remove, or reorder entries in
+  `.gitignore` as part of an autofix.
+- The CodeQL workflow files under `.github/workflows/` (e.g. `codeql.yml`).
+  Suppression or scope changes must use the deviation mechanism (see §4),
+  not workflow edits.
+
+### 4. Deviations — respect project policy and reference it in fixes
+
+A project under analysis may declare that a rule, file, region, or specific
+construct is intentionally exempt from a coding standard. Such deviations are
 not always expressed through the same mechanism: a project may use the
-**standard CodeQL Coding Standards deviation mechanism**, a
-**custom annotation or attribute** convention,
-**in-source line / block comments**,
+**standard CodeQL Coding Standards deviation mechanism**, a **custom
+annotation or attribute** convention, **in-source line / block comments**,
 or a **separate documentation file** (for example a `DEVIATIONS.md`,
-`MISRA-deviations.md`, `coding-standards.yml`, compliance matrix, or similar).
-
-Locate the deviations file and explicitly search for matching deviations
-before proposing code changes.
-The fix proposal must take what is found into account and treat it as an
-existing deviation if it clearly covers the alert location and rule.
+`MISRA-deviations.md`, compliance matrix, or similar).
 
 If the alert location is covered by an existing deviation:
-- Look for existing deviations of that rule, and see if any should apply
-- In the pull request description, explicitly state that a matching
-  deviation already exists in the project, citing the file path and the
-  relevant `rule-id` / `query-id` / `permit-id` / `code-identifier` / scope
-  (paths or markers) so reviewers can decide whether to accept the fix or
-  keep the deviation.
-- Do not silently delete or weaken an existing deviation, permit, or
-  re-categorization entry as part of the fix.
-- Propose a code fix that would make the location compliant by
+
+- **Still propose a code fix** that would make the location compliant by
   default. Authors may have left the deviation in place pragmatically and
   may prefer a real fix.
-- Consider whether an existing code identifier should be used
-- Consider whether a file-wide exception should be used
-- Consider whether a new code identifier should be used
-- If using a code-identifier, look for examples to determine whether 
-  to use [[attribute]] form
-- If using an [[attribute]], look for project formatting configurations or code
-  examples to determine how to format the attribute relative to its declaration
-- When using deviation comments, consider project formatting, the specific
-  violation in question, and other example deviation comments in the project to
-  determine whether to use same-line, next-line, or begin/end comment deviations
-  Project formatting configuration may be .clang-format, etc.
-
-### 4. False positives — propose a deviation, do not stay silent
-
-Precedence: if an alert is judged to be a false positive, the false-positive
-workflow in this section overrides any guidance above about proposing a code
-fix when a deviation exists.
+- **In the pull request description, explicitly state** that a matching
+  deviation already exists in the project, referring to the possible deviation marker
+  so reviewers can decide whether to accept the fix or keep the deviation.
+- If the deviation style does not match the coding standards user manual, propose a fix.  
+- Do not silently delete or weaken an existing deviation, permit, or
+  re-categorization entry as part of the fix.
+
+### 5. False positives — propose a deviation, do not stay silent
 
 Copilot autofix normally refrains from opening a pull request when it
 considers an alert to be a false positive. For CodeQL Coding Standards alerts
@@ -156,8 +130,8 @@ When an alert is judged to be a false positive, the autofix PR must:
      or directory is affected;
    - a project-wide deviation only when the rule is genuinely inapplicable to
      the project.
-     Use `<standard>` ∈ {`misra`, `autosar`, `cert`} as appropriate for the
-     alert.
+   Use `<standard>` ∈ {`misra`, `autosar`, `cert`} as appropriate for the
+   alert.
 3. **Populate the deviation record** with at least:
    - `rule-id` matching the alert’s rule identifier;
    - `query-id` matching the alert’s `@id` (when the deviation is meant to
@@ -175,7 +149,7 @@ When an alert is judged to be a false positive, the autofix PR must:
 5. **In the PR description**, explicitly state that the alert is being
    handled as a false positive via a deviation (not by code change), link to
    the
-  [deviation mechanism documentation](https://github.com/github/codeql-coding-standards/blob/main/docs/user_manual.md#applying-deviations),
+   [deviation mechanism documentation](https://github.com/github/codeql-coding-standards/blob/main/docs/user_manual.md#applying-deviations),
    and summarise the justification so a reviewer can approve or reject it.
 
 A false-positive PR should therefore contain **only** the deviation entry

From 69fbf216cbfae7ec586b51d26776f7795fed4bb0 Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Wed, 17 Jun 2026 19:31:38 +0200
Subject: [PATCH 06/17] Clarify autofix pull request restrictions

---
 docs/copilot-instructions.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/copilot-instructions.md b/docs/copilot-instructions.md
index a315aaaad..f45f7d3e9 100644
--- a/docs/copilot-instructions.md
+++ b/docs/copilot-instructions.md
@@ -72,7 +72,7 @@ The full list of supported rules per standard is published as
 Autofix pull requests must only change source files that are part of the
 checked-in project. They must **not** include:
 
-- Build directories or files generated during compilation.
+- Build directories or files generated during compilation (`.build/`, etc.).
 - Editor / IDE state (`.vscode/`, `.idea/`, `.DS_Store`, etc.).
 - **`.gitignore` itself.** Do not add, remove, or reorder entries in
   `.gitignore` as part of an autofix.

From feb2f18ae1b08412074db32b86ef7de1a8f771ae Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Wed, 17 Jun 2026 19:40:38 +0200
Subject: [PATCH 07/17] Refactor Copilot instructions for clarity and
 consistency

---
 docs/copilot-instructions.md | 141 ++++++++++++++++++++++-------------
 1 file changed, 88 insertions(+), 53 deletions(-)

diff --git a/docs/copilot-instructions.md b/docs/copilot-instructions.md
index f45f7d3e9..fe9340b10 100644
--- a/docs/copilot-instructions.md
+++ b/docs/copilot-instructions.md
@@ -1,22 +1,20 @@
-[//]: # "Include this file in the repository to provide instructions to GitHub Copilot AUtofix. For more information, see https://docs.github.com/copilot/copilot-for-business/copilot-instructions."
-# GitHub Copilot instructions
+[//]: # "Include this file in the repository to provide instructions to GitHub Copilot Autofix. For more information, see https://docs.github.com/copilot/copilot-for-business/copilot-instructions."
 
-This file contains repository-wide guidance for GitHub Copilot. Each top-level
-section below configures Copilot for a specific use case in this repository.
-Add further top-level sections as needed (general coding conventions, review
-guidance, etc.).
 
-## Autofix for CodeQL Coding Standards
+# Agentic autofix instructions for CodeQL Coding Standards
 
-This section configures GitHub Copilot **Autofix** when it generates pull requests to remediate alerts produced by the
-[CodeQL Coding Standards](https://github.com/github/codeql-coding-standards/)
-project. It applies to alerts for any of the supported standards (MISRA C,
-MISRA C++, AUTOSAR C++, CERT C, CERT C++).
+This document configures **Agentic Autofix** when generating pull requests to
+remediate alerts produced by [CodeQL Coding Standards](https://github.com/github/codeql-coding-standards/).
+It applies to alerts for any of the supported standards (MISRA C, MISRA C++,
+AUTOSAR C++, CERT C, CERT C++).
 
-### 1. Reference material — where to learn each rule
+## 1. Reference material — where to learn each rule
 
-Before proposing a fix, consult the rule’s authoritative implementation as well as the corresponding compliant and non-compliant code patterns available as test cases in the CodeQL Coding Standards [`github/codeql-coding-standards`](https://github.com/github/codeql-coding-standards/)
-repository. That repository is the single source of truth for what the query detects and what compliant code looks like.
+Before proposing a fix, consult the rule’s authoritative implementation as well
+as the corresponding compliant and non-compliant code patterns available as
+test cases in the [`github/codeql-coding-standards` repository](https://github.com/github/codeql-coding-standards/).
+That repository is the single source of truth for what the query
+detects and what compliant code looks like.
 
 Project layout (per language / standard):
 
@@ -41,33 +39,48 @@ The full list of supported rules per standard is published as
 `supported_rules_list_<version>.csv` / `.md` in each
 [release](https://github.com/github/codeql-coding-standards/releases).
 
-### 2. Fix discipline — keep changes minimal and standards-compliant
+## 2. Fix discipline — keep changes minimal and standards-compliant
 
 - **Minimum diff.** Modify the smallest possible amount of code that
-  eliminates the assigned alerts. Do not refactor surrounding code, rename symbols,
+  eliminates the alert. Do not refactor surrounding code, rename symbols,
   reformat unrelated lines, or change public APIs unless strictly required to
   satisfy the rule.
 - **No drive-by changes.** Do not add features, fix unrelated warnings, change
   build flags, update dependencies, or “improve” code that the alert does not
   point at.
-- **New code must comply with the analyzed coding standard.** Any code introduced by the
-  fix must itself satisfy every rule of the coding standard being verified
-  (e.g. all MISRA C rules). Do not limit the review to the rule targeted by
-  the alert: iterate over the full supported rules list for the applicable
-  standard and, for each rule, read its help file
-  (`<language>/<standard>/src/rules/<rule-id>/<rule-id>.md` or `.qhelp`) to
-  understand its intent, then verify that the introduced code does not violate
-  it. Cross-check against the COMPLIANT examples in each rule's
-  `test/rules/<rule-id>/` directory.
-- **Match the project’s existing style.** Follow the conventions visible in
-  the surrounding source files (naming, headers, namespaces, C++ standard
-  level, use of `enum class`, etc.).
-- **Preserve behaviour.** A coding-standards fix is a refactor at the source
-  level, not a functional change. The fix must not alter observable runtime
-  behaviour unless the rule explicitly targets undefined or implementation-
-  defined behaviour that has to change.
-
-### 3. Do not touch build outputs, generated files, or `.gitignore`
+- **Do not attempt at fixing design issues.** A fix should not attempt to
+  “improve” the design of the code or address architectural issues.
+  Always verify that the code section around the alert is intended to follow
+  the standard and add a comment.
+  The presence of certain design issues (e.g. dynamic memory allocation) might
+  indicate that the code is not intended to be compliant with the standard, and
+  that a deviation should be added instead of a code fix.
+- **New code must comply with the same standard.** Any code introduced by the
+  fix must itself satisfy the coding standard being verified (e.g. MISRA C++
+  2023). Cross-check the inserted code against the COMPLIANT examples in the
+  corresponding `test/rules/<rule-id>/` directory and against neighbouring
+  rules that are obviously relevant (e.g. don’t fix an integer-conversion rule
+  by introducing a cast that violates a different MISRA rule).
+- **Preserve safe and desired functional behavior.** ensure the resulting code
+  handles all reasonable real-world scenarios as the code originally intended.
+  This may involve precisely maintaining the existing code behavior, or it may
+  involve fixing subtle or rare bugs, for instance dangerous overflows,
+  that the existing code does not handle and the rule is designed to detect.
+- **Fix dangerous bugs** If the alert is flagging unsafe or undefined behavior,
+  critically examine how that safety issue in the code should be properly fixed.
+  Add detections and error handling if necessary to make the code safe under
+  all conditions without introducing unnecessary complexity. Follow existing
+  project guidelines on how to handle rare, dangerous, or unexpected scenarios
+  that occur at runtime.
+- **Thoroughly explain analysis and functional changes.** If the alert does not
+  introduce any unwanted behavior and the change is functionally equivalent,
+  explain your thinking, and clearly show that the code before was safe, and
+  that the new code is exactly equivalent in behavior.
+  If there was a dangerous edge case or condition, explain exactly how that
+  scenario would create problems in the code and how the fix will prevent such
+  issues and improve the safety and quality of the codebase.
+
+## 3. Do not touch build output, generated files, or `.gitignore`
 
 Autofix pull requests must only change source files that are part of the
 checked-in project. They must **not** include:
@@ -80,29 +93,51 @@ checked-in project. They must **not** include:
   Suppression or scope changes must use the deviation mechanism (see §4),
   not workflow edits.
 
-### 4. Deviations — respect project policy and reference it in fixes
+## 4. Deviations — respect project policy and reference it in fixes
 
-A project under analysis may declare that a rule, file, region, or specific
-construct is intentionally exempt from a coding standard. Such deviations are
+A project may declare that a rule, file, region, or specific construct is
+intentionally exempt from a coding standard. Such deviations are
 not always expressed through the same mechanism: a project may use the
-**standard CodeQL Coding Standards deviation mechanism**, a **custom
-annotation or attribute** convention, **in-source line / block comments**,
+**standard CodeQL Coding Standards deviation mechanism**, a
+**custom annotation or attribute** convention,
+**in-source line / block comments**,
 or a **separate documentation file** (for example a `DEVIATIONS.md`,
-`MISRA-deviations.md`, compliance matrix, or similar).
+`MISRA-deviations.md`, `coding-standards.yml`, compliance matrix, or similar).
 
-If the alert location is covered by an existing deviation:
+Locate the deviations file and explicitly search for matching deviations
+before proposing code changes.
+The fix proposal must take what is found into account and treat it as an
+existing deviation if it clearly covers the alert location and rule.
 
-- **Still propose a code fix** that would make the location compliant by
-  default. Authors may have left the deviation in place pragmatically and
-  may prefer a real fix.
-- **In the pull request description, explicitly state** that a matching
-  deviation already exists in the project, referring to the possible deviation marker
-  so reviewers can decide whether to accept the fix or keep the deviation.
-- If the deviation style does not match the coding standards user manual, propose a fix.  
+If the alert location is covered by an existing deviation:
+- Look for existing deviations of that rule, and see if any should apply
+- In the pull request description, explicitly state that a matching
+  deviation already exists in the project, citing the file path and the
+  relevant `rule-id` / `query-id` / `permit-id` / `code-identifier` / scope
+  (paths or markers) so reviewers can decide whether to accept the fix or
+  keep the deviation.
 - Do not silently delete or weaken an existing deviation, permit, or
   re-categorization entry as part of the fix.
-
-### 5. False positives — propose a deviation, do not stay silent
+- Propose a code fix that would make the location compliant by
+  default. Authors may have left the deviation in place pragmatically and
+  may prefer a real fix.
+- Consider whether an existing code identifier should be used
+- Consider whether a file-wide exception should be used
+- Consider whether a new code identifier should be used
+- If using a code-identifier, look for examples to determine whether 
+  to use [[attribute]] form
+- If using an [[attribute]], look for project formatting configurations or code
+  examples to determine how to format the attribute relative to its declaration
+- When using deviation comments, consider project formatting, the specific
+  violation in question, and other example deviation comments in the project to
+  determine whether to use same-line, next-line, or begin/end comment deviations
+  Project formatting configuration may be .clang-format, etc.
+
+## 5. False positives — propose a deviation, do not stay silent
+
+Precedence: if an alert is judged to be a false positive, the false-positive
+workflow in this section overrides any guidance above about proposing a code
+fix when a deviation exists.
 
 Copilot autofix normally refrains from opening a pull request when it
 considers an alert to be a false positive. For CodeQL Coding Standards alerts
@@ -130,8 +165,8 @@ When an alert is judged to be a false positive, the autofix PR must:
      or directory is affected;
    - a project-wide deviation only when the rule is genuinely inapplicable to
      the project.
-   Use `<standard>` ∈ {`misra`, `autosar`, `cert`} as appropriate for the
-   alert.
+     Use `<standard>` ∈ {`misra`, `autosar`, `cert`} as appropriate for the
+     alert.
 3. **Populate the deviation record** with at least:
    - `rule-id` matching the alert’s rule identifier;
    - `query-id` matching the alert’s `@id` (when the deviation is meant to
@@ -149,7 +184,7 @@ When an alert is judged to be a false positive, the autofix PR must:
 5. **In the PR description**, explicitly state that the alert is being
    handled as a false positive via a deviation (not by code change), link to
    the
-   [deviation mechanism documentation](https://github.com/github/codeql-coding-standards/blob/main/docs/user_manual.md#applying-deviations),
+  [deviation mechanism documentation](https://github.com/github/codeql-coding-standards/blob/main/docs/user_manual.md#applying-deviations),
    and summarise the justification so a reviewer can approve or reject it.
 
 A false-positive PR should therefore contain **only** the deviation entry

From 32b4edef48781c1a5e0af2a427cabf29da513063 Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Wed, 17 Jun 2026 19:43:23 +0200
Subject: [PATCH 08/17] Rename copilot-instructions.md to
 autofix-instructions.md

---
 docs/{copilot-instructions.md => autofix-instructions.md} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename docs/{copilot-instructions.md => autofix-instructions.md} (100%)

diff --git a/docs/copilot-instructions.md b/docs/autofix-instructions.md
similarity index 100%
rename from docs/copilot-instructions.md
rename to docs/autofix-instructions.md

From 2cd06d8478cac51c4e60bb9e1e9a9e2836fb7566 Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Wed, 17 Jun 2026 19:56:43 +0200
Subject: [PATCH 09/17] Update autofix instructions for clickable links

Clarified instructions for including clickable links to Code Scanning results.
---
 docs/autofix-instructions.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/docs/autofix-instructions.md b/docs/autofix-instructions.md
index fe9340b10..da724f261 100644
--- a/docs/autofix-instructions.md
+++ b/docs/autofix-instructions.md
@@ -23,7 +23,8 @@ Project layout (per language / standard):
 <language>/<standard>/test/rules/<rule-id>/   # test cases, with COMPLIANT / NON_COMPLIANT markers
 ```
 
-When referring to the alerts you are addressing, include a clickable link.
+When referring to the alerts you are addressing, include a clickable link
+to the Code Scanning result (e.g. `./security/code-scanning/<id>`).
 
 When generating a fix:
 

From 5d49de1365723de43c45974ca913ddad240cc877 Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Wed, 17 Jun 2026 20:08:29 +0200
Subject: [PATCH 10/17] Update autofix instructions by removing link guidance

Removed instructions for including clickable links to Code Scanning results.
---
 docs/autofix-instructions.md | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/docs/autofix-instructions.md b/docs/autofix-instructions.md
index da724f261..2057fa64b 100644
--- a/docs/autofix-instructions.md
+++ b/docs/autofix-instructions.md
@@ -23,9 +23,6 @@ Project layout (per language / standard):
 <language>/<standard>/test/rules/<rule-id>/   # test cases, with COMPLIANT / NON_COMPLIANT markers
 ```
 
-When referring to the alerts you are addressing, include a clickable link
-to the Code Scanning result (e.g. `./security/code-scanning/<id>`).
-
 When generating a fix:
 
 1. Locate the rule directory matching the alert’s rule id / query id.

From 321e3f1d8f71d343b3fcb722b97259ba229c7c16 Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Wed, 17 Jun 2026 20:16:16 +0200
Subject: [PATCH 11/17] Update autofix-instructions.md

---
 docs/autofix-instructions.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/autofix-instructions.md b/docs/autofix-instructions.md
index 2057fa64b..14be12bf5 100644
--- a/docs/autofix-instructions.md
+++ b/docs/autofix-instructions.md
@@ -159,8 +159,8 @@ When an alert is judged to be a false positive, the autofix PR must:
      (`// codeql::<standard>_deviation(...)`,
      `// codeql::<standard>_deviation_next_line(...)`, or a
      `..._deviation_begin` / `..._deviation_end` pair); or
-   - a `paths:`-scoped deviation in `coding-standards.yml` when a whole file
-     or directory is affected;
+   - a `paths:`-scoped deviation in `coding-standards.yml` when the rule should
+     not be applied to a whole file or directory or
    - a project-wide deviation only when the rule is genuinely inapplicable to
      the project.
      Use `<standard>` ∈ {`misra`, `autosar`, `cert`} as appropriate for the

From acc38502b3e781ce1f4b5718c9fc9feb71d1102f Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Wed, 17 Jun 2026 20:35:18 +0200
Subject: [PATCH 12/17] Update autofix-instructions.md

---
 docs/autofix-instructions.md | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/docs/autofix-instructions.md b/docs/autofix-instructions.md
index 14be12bf5..1508bf1d9 100644
--- a/docs/autofix-instructions.md
+++ b/docs/autofix-instructions.md
@@ -53,12 +53,12 @@ The full list of supported rules per standard is published as
   The presence of certain design issues (e.g. dynamic memory allocation) might
   indicate that the code is not intended to be compliant with the standard, and
   that a deviation should be added instead of a code fix.
-- **New code must comply with the same standard.** Any code introduced by the
-  fix must itself satisfy the coding standard being verified (e.g. MISRA C++
-  2023). Cross-check the inserted code against the COMPLIANT examples in the
-  corresponding `test/rules/<rule-id>/` directory and against neighbouring
-  rules that are obviously relevant (e.g. don’t fix an integer-conversion rule
-  by introducing a cast that violates a different MISRA rule).
+- **New code must comply with the same standard.** Any code modified by the
+  fix must itself satisfy every rule of the coding standard being verified. 
+  Cross-check the changed code against the COMPLIANT examples in the
+  corresponding `test/rules/<rule-id>/` directory and against every other
+  relevant rules (e.g. don’t fix an integer-conversion rule by introducing a
+  cast that violates a different MISRA rule).
 - **Preserve safe and desired functional behavior.** ensure the resulting code
   handles all reasonable real-world scenarios as the code originally intended.
   This may involve precisely maintaining the existing code behavior, or it may
@@ -152,20 +152,20 @@ When an alert is judged to be a false positive, the autofix PR must:
 
 1. **Not modify the flagged code** to “work around” the alert.
 2. **Add or update a deviation record** that scopes precisely to the alert.
-   Prefer the narrowest scope that is appropriate:
-   - a `code-identifier` deviation referenced from the exact line, statement,
+   Prefer the narrowest scope that is appropriate in this order:
+   1. a `code-identifier` deviation referenced from the exact line, statement,
      function, or block, via an attribute
      (`[[codeql::<standard>_deviation("...")]]`) or a comment marker
      (`// codeql::<standard>_deviation(...)`,
      `// codeql::<standard>_deviation_next_line(...)`, or a
      `..._deviation_begin` / `..._deviation_end` pair); or
-   - a `paths:`-scoped deviation in `coding-standards.yml` when the rule should
+   2. a `paths:`-scoped deviation in `coding-standards.yml` when the rule should
      not be applied to a whole file or directory or
-   - a project-wide deviation only when the rule is genuinely inapplicable to
+   3. a project-wide deviation only when the rule is genuinely inapplicable to
      the project.
      Use `<standard>` ∈ {`misra`, `autosar`, `cert`} as appropriate for the
      alert.
-3. **Populate the deviation record** with at least:
+3. **Populate the deviation record** for deviation records with at least:
    - `rule-id` matching the alert’s rule identifier;
    - `query-id` matching the alert’s `@id` (when the deviation is meant to
      cover a single sub-query of the rule);
@@ -174,12 +174,12 @@ When an alert is judged to be a false positive, the autofix PR must:
    - `scope`, `background`, and `requirements` when they help a reviewer
      audit the decision;
    - a `raised-by` entry (and leave `approved-by` for a human reviewer).
-4. **Place the deviation entry** in an existing `coding-standards.yml` if one
-   exists in an appropriate directory; otherwise create one at the most
-   specific directory whose subtree is affected. When using a `permit-id`,
-   reference an existing permit if one matches; do not invent new permit IDs
-   unless necessary.
-5. **In the PR description**, explicitly state that the alert is being
+4. **Place the deviation entry** of types 2. and 3. in an existing
+   `coding-standards.yml` if one exists in an appropriate directory; 
+   otherwise create one at the most specific directory whose subtree is
+   affected. When using a `permit-id`, reference an existing permit
+   if one matches; do not invent new permit IDs unless necessary.
+6. **In the PR description**, explicitly state that the alert is being
    handled as a false positive via a deviation (not by code change), link to
    the
   [deviation mechanism documentation](https://github.com/github/codeql-coding-standards/blob/main/docs/user_manual.md#applying-deviations),

From d8cedd9bf662cbbdce75a63b5b94724360bc4318 Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Wed, 17 Jun 2026 20:37:26 +0200
Subject: [PATCH 13/17] Update autofix-instructions.md

---
 docs/autofix-instructions.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/autofix-instructions.md b/docs/autofix-instructions.md
index 1508bf1d9..23ef290af 100644
--- a/docs/autofix-instructions.md
+++ b/docs/autofix-instructions.md
@@ -152,7 +152,7 @@ When an alert is judged to be a false positive, the autofix PR must:
 
 1. **Not modify the flagged code** to “work around” the alert.
 2. **Add or update a deviation record** that scopes precisely to the alert.
-   Prefer the narrowest scope that is appropriate in this order:
+   Prefer the one narrowest scope that is appropriate in the following order:
    1. a `code-identifier` deviation referenced from the exact line, statement,
      function, or block, via an attribute
      (`[[codeql::<standard>_deviation("...")]]`) or a comment marker

From 84c34f933572f28866197d829152a4864878f614 Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Wed, 17 Jun 2026 20:48:53 +0200
Subject: [PATCH 14/17] Update autofix-instructions.md

---
 docs/autofix-instructions.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/docs/autofix-instructions.md b/docs/autofix-instructions.md
index 23ef290af..d8546f67c 100644
--- a/docs/autofix-instructions.md
+++ b/docs/autofix-instructions.md
@@ -78,11 +78,10 @@ The full list of supported rules per standard is published as
   scenario would create problems in the code and how the fix will prevent such
   issues and improve the safety and quality of the codebase.
 
-## 3. Do not touch build output, generated files, or `.gitignore`
+## 3. Do not add build output folders, generated files, or `.gitignore`
 
 Autofix pull requests must only change source files that are part of the
 checked-in project. They must **not** include:
-
 - Build directories or files generated during compilation (`.build/`, etc.).
 - Editor / IDE state (`.vscode/`, `.idea/`, `.DS_Store`, etc.).
 - **`.gitignore` itself.** Do not add, remove, or reorder entries in

From 8089adf3f1502a24bbd1f1b35e1af034be366dc6 Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Thu, 18 Jun 2026 15:03:49 +0200
Subject: [PATCH 15/17] Add compliance tests for division and modulus
 operations in unsigned operations

---
 .../unsignedoperationwithconstantoperandswraps/test.c      | 7 +++++++
 change_notes/2026-06-18-fix-fp-misra-c++-8-20-1.md         | 4 ++++
 .../UnsignedOperationWithConstantOperandsWraps.qll         | 3 +--
 .../unsignedoperationwithconstantoperandswraps/test.cpp    | 7 +++++++
 4 files changed, 19 insertions(+), 2 deletions(-)
 create mode 100644 change_notes/2026-06-18-fix-fp-misra-c++-8-20-1.md

diff --git a/c/common/test/rules/unsignedoperationwithconstantoperandswraps/test.c b/c/common/test/rules/unsignedoperationwithconstantoperandswraps/test.c
index 214b18a44..e5dbdc126 100644
--- a/c/common/test/rules/unsignedoperationwithconstantoperandswraps/test.c
+++ b/c/common/test/rules/unsignedoperationwithconstantoperandswraps/test.c
@@ -80,4 +80,11 @@ void test_sub_postcheck(unsigned int i1, unsigned int i2) {
   if (i1 > i2) {
     // handle error
   }
+
+  void test_mod_rem(unsigned int i1, unsigned int i2) {
+    i1 / i2;  // COMPLIANT - exception 2
+    i1 /= i2; // COMPLIANT - exception 2
+    i1 % i2;  // COMPLIANT - exception 2
+    i1 %= i2; // COMPLIANT - exception 2
+  }
 }
\ No newline at end of file
diff --git a/change_notes/2026-06-18-fix-fp-misra-c++-8-20-1.md b/change_notes/2026-06-18-fix-fp-misra-c++-8-20-1.md
new file mode 100644
index 000000000..3ee9bcde4
--- /dev/null
+++ b/change_notes/2026-06-18-fix-fp-misra-c++-8-20-1.md
@@ -0,0 +1,4 @@
+- `INT30-C` - `UnsignedIntegerOperationsWrapAround.ql`:
+  - Fixed false positives for `/=` and `%=` assignments.
+- `INT30-C` - `UnsignedOperationWithConstantOperandsWraps.ql`:
+  - Fixed false positives for `/=` and `%=` assignments.
diff --git a/cpp/common/src/codingstandards/cpp/rules/unsignedoperationwithconstantoperandswraps/UnsignedOperationWithConstantOperandsWraps.qll b/cpp/common/src/codingstandards/cpp/rules/unsignedoperationwithconstantoperandswraps/UnsignedOperationWithConstantOperandsWraps.qll
index bc0c6d8fc..06f4cb086 100644
--- a/cpp/common/src/codingstandards/cpp/rules/unsignedoperationwithconstantoperandswraps/UnsignedOperationWithConstantOperandsWraps.qll
+++ b/cpp/common/src/codingstandards/cpp/rules/unsignedoperationwithconstantoperandswraps/UnsignedOperationWithConstantOperandsWraps.qll
@@ -26,8 +26,7 @@ query predicate problems(InterestingOverflowingOperation op, string message) {
   // Permitted by exception 3
   not op instanceof LShiftExpr and
   // Permitted by exception 2 - zero case is handled in separate query
-  not op instanceof DivExpr and
-  not op instanceof RemExpr and
+  not op instanceof DivOrRemOperation and
   message =
     "Operation " + op.getOperator() + " of type " + op.getType().getUnderlyingType() + " may wrap."
 }
diff --git a/cpp/common/test/rules/unsignedoperationwithconstantoperandswraps/test.cpp b/cpp/common/test/rules/unsignedoperationwithconstantoperandswraps/test.cpp
index 8f76fbeee..86ac7645b 100644
--- a/cpp/common/test/rules/unsignedoperationwithconstantoperandswraps/test.cpp
+++ b/cpp/common/test/rules/unsignedoperationwithconstantoperandswraps/test.cpp
@@ -80,4 +80,11 @@ void test_sub_postcheck(unsigned int i1, unsigned int i2) {
   if (i1 > i2) {
     // handle error
   }
+
+  void test_mod_rem(unsigned int i1, unsigned int i2) {
+    i1 / i2;  // COMPLIANT - exception 2
+    i1 /= i2; // COMPLIANT - exception 2
+    i1 % i2;  // COMPLIANT - exception 2
+    i1 %= i2; // COMPLIANT - exception 2
+  }
 }
\ No newline at end of file

From fb7bd2eb86917c317306e24c76f088119e57a3e6 Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Thu, 18 Jun 2026 20:13:54 +0200
Subject: [PATCH 16/17] Update autofix-instructions.md

---
 docs/autofix-instructions.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/docs/autofix-instructions.md b/docs/autofix-instructions.md
index d8546f67c..e0779003d 100644
--- a/docs/autofix-instructions.md
+++ b/docs/autofix-instructions.md
@@ -54,7 +54,9 @@ The full list of supported rules per standard is published as
   indicate that the code is not intended to be compliant with the standard, and
   that a deviation should be added instead of a code fix.
 - **New code must comply with the same standard.** Any code modified by the
-  fix must itself satisfy every rule of the coding standard being verified. 
+  fix must itself satisfy every rule of the coding standard being verified.
+  Check if there are other code scanning alerts open for the same code location,
+  try to fix all the relevant issues at once in the same PR.
   Cross-check the changed code against the COMPLIANT examples in the
   corresponding `test/rules/<rule-id>/` directory and against every other
   relevant rules (e.g. don’t fix an integer-conversion rule by introducing a

From 1cca8c38fb79f6e7700c9f76c8157efba0ce4889 Mon Sep 17 00:00:00 2001
From: Mauro Baluda <mbaluda@github.com>
Date: Thu, 18 Jun 2026 20:46:24 +0200
Subject: [PATCH 17/17] Update autofix-instructions.md

---
 docs/autofix-instructions.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/docs/autofix-instructions.md b/docs/autofix-instructions.md
index e0779003d..bc29eedf0 100644
--- a/docs/autofix-instructions.md
+++ b/docs/autofix-instructions.md
@@ -43,9 +43,11 @@ The full list of supported rules per standard is published as
   eliminates the alert. Do not refactor surrounding code, rename symbols,
   reformat unrelated lines, or change public APIs unless strictly required to
   satisfy the rule.
-- **No drive-by changes.** Do not add features, fix unrelated warnings, change
-  build flags, update dependencies, or “improve” code that the alert does not
-  point at.
+- **Multiple alerts.** Check if there are other code scanning alerts
+  for the same coding standard reported for the same code location, fix all
+  the relevant alerts at once in the same PR.
+- **No drive-by changes.** Do not add features, change build flags, update
+  dependencies, or “improve” code that the alert does not point at.
 - **Do not attempt at fixing design issues.** A fix should not attempt to
   “improve” the design of the code or address architectural issues.
   Always verify that the code section around the alert is intended to follow
@@ -55,8 +57,6 @@ The full list of supported rules per standard is published as
   that a deviation should be added instead of a code fix.
 - **New code must comply with the same standard.** Any code modified by the
   fix must itself satisfy every rule of the coding standard being verified.
-  Check if there are other code scanning alerts open for the same code location,
-  try to fix all the relevant issues at once in the same PR.
   Cross-check the changed code against the COMPLIANT examples in the
   corresponding `test/rules/<rule-id>/` directory and against every other
   relevant rules (e.g. don’t fix an integer-conversion rule by introducing a