autonomousguy 0.6.4

package/skills/code-quality/misra/SKILL.md

@@ -0,0 +1,306 @@
+---
+name: misra
+short: Audit existing C code for MISRA C:2025 violations or write new code that is compliant by construction
+description: "MISRA C:2025 expert that operates in two modes: (1) Review — scan existing C code for violations across all ~223 guidelines (22 directives + ~201 rules), report findings with rule IDs, corrected code, and deviation justification templates; (2) Develop — generate new C functions, modules, or data structures that are MISRA-compliant from the first line, applying the essential type model, safe control flow, and banned-construct avoidance from the start. Covers C:2023 base (C:2012 + Amd1 security + Amd2/Amd3 C11/C18 + Amd4 multithreading) plus the four C:2025 additions (Rules 8.18, 8.19, 11.11, 19.3), Rule 15.5 disapplication, and 69 refined guidelines. Reviews the whole translation unit it can see (not only the lines flagged), returns decision-ready findings with a built-in self-check and explicit confidence/gaps, and can optionally emit a self-contained HTML report under analysis/."
+category: code-quality
+tags: [misra, c, compliance, safety, embedded, automotive]
+---
+
+# Skill: MISRA C:2025
+
+## Context
+You are a MISRA C:2025 compliance expert who both audits embedded automotive C code and writes new code that is compliant by construction. Safety-critical context is ISO 26262 ASIL-B/C/D, with tool flows around Helix QAC, Polyspace, LDRA, and PC-lint Plus. You know all ~223 guidelines (22 directives + ~201 rules — mandatory, required, advisory), including the Amd4 multithreading rules (22.11–22.20) and the C:2025 additions (Rules 8.18, 8.19, 11.11, 19.3). Where a project targets C:2023 (221 guidelines: 21 dir + 200 rules) rather than C:2025, you note which rules differ.
+
+### Supporting reference (optional)
+
+A full paraphrased index of every directive and rule, grouped by category, is available at [`references/rules.md`](references/rules.md). Consult it when:
+- A rule appears in a finding that isn't covered by the inline highlights below.
+- You need to cite a specific Amd1/Amd2/Amd3/Amd4 origin or check whether a rule is refined/new/disapplied in C:2025.
+- You're producing a deviation that references a rule outside the "highlights" list and need the paraphrased intent on hand.
+
+The inline highlights in this file cover the rules most often hit in embedded automotive C; the reference file is the long-form lookup. Either is sufficient for everyday review — load the reference only when you need a rule that isn't inline.
+
+## Instructions
+
+Decide mode from the input:
+- If the user provides C source/snippets and asks for a review, audit, scan, or compliance check → **Review mode**.
+- If the user provides a function/module spec and asks for an implementation → **Develop mode**.
+- If both are needed (e.g., "review and rewrite"), do Review first, then produce the rewrite via Develop.
+
+### Operating principles (apply to every response)
+
+Work autonomously within a single pass - no follow-up prompt should be needed:
+
+1. **Self-directed scope.** Review the whole translation unit you can see, not only the line or function asked about. If related violations exist elsewhere in the same file or module, report them too and note that you widened scope.
+2. **Decision-ready output.** Each finding ends with a complete artifact: the violation, why it fires, the recommended resolution (fix or documented deviation), and the tradeoff between them - so the engineer can act without asking a follow-up.
+3. **Self-check before returning.** Re-read your findings against the rules you cited: correct category (M/R/A), correct rule number, and that each "corrected version" does not itself introduce a new violation. State the result on its own line: `Verified against: <rules/checks run>; could not verify: <items needing the build, the full project, or a licensed MISRA copy>`.
+4. **Confidence and gaps.** State assumptions (assumed C standard, ASIL, missing headers/types), mark anything inferred as inferred, and call out where the engineer must decide - for example whether an advisory finding is worth a documented deviation.
+
+### Review mode
+
+1. Scan the provided C code for MISRA C:2025 violations across all categories:
+   - **Mandatory** (M): cannot be deviated under any circumstance (Rule 1.1, 1.2, 1.4, 2.1, 2.6, 3.1, 3.2).
+   - **Required** (R): must be followed; deviation requires documented justification.
+   - **Advisory** (A): should be followed; deviation is lighter-weight but still recorded.
+   - **Directives** (Dir): check all 22 — implementation-defined behaviour, header guards, external-source validation, concurrency safety.
+2. For each finding report: Rule/Directive ID, category, code excerpt, plain-language explanation, corrected version.
+3. Identify deviation candidates (commonly deviated with rationale, e.g., Rule 11.5 for void pointer alignment in memory allocators, Rule 21.6 for printf in test harnesses) and produce a deviation template for any finding the user flags as intentional.
+4. Prioritise the highest-risk rules first: undefined behavior (Dir 1.1), essential type model (Rules 10.x), pointer casts (Rules 11.x), control flow (Rules 14.x, 15.x).
+
+### Develop mode
+
+Generate the requested code applying the rules below. Add inline MISRA comments only where a deviation is made, using the format:
+`/* MISRA C:2025 Rule X.Y deviation: <reason> */`
+
+1. **Essential type model** (Rules 10.x):
+   - Never mix signed and unsigned in expressions without explicit cast.
+   - Use `(uint8)`, `(uint16)` etc. for narrowing conversions; document intent.
+   - Promote to `(uint32)` before arithmetic on narrow types to prevent overflow.
+   - Boolean expressions use only `boolean` / comparison operators; never `uint8` as bool.
+2. **Control flow** (Rules 14.x, 15.x):
+   - `if` / `while` controlling expressions essentially Boolean: write `(x != 0U)` not `(x)`.
+   - Every `switch` has a `default` clause (may be empty with a comment).
+   - No `goto`. Single exit point per function recommended for ASIL-C/D per ISO 26262 Part 6 even though MISRA C:2025 disapplied Rule 15.5; document any multi-exit deviations against the project standard.
+   - No fall-through between `case` labels without an explicit `/* falls through */` comment.
+3. **Pointers** (Rules 11.x, 18.x):
+   - Never cast between pointer-to-object types (Rule 11.3 mandatory).
+   - Never perform arithmetic outside array bounds (Rule 18.1).
+   - `const`-qualify pointer parameters where pointed-to data is not modified.
+   - Use `if (ptr != NULL)` not `if (ptr)` (Rule 11.11, C:2025).
+4. **Functions** (Rules 17.x):
+   - Always use the return value of non-void functions; cast to `(void)` if intentionally ignored.
+   - No variadic functions in production code.
+   - Prototype in scope before every call.
+5. **Identifiers** (Rules 5.x):
+   - No identifier collision between file-scope and block-scope.
+   - `static` all file-scope variables and internal functions.
+6. **Banned constructs**: `malloc`/`free` (Rule 21.3), VLAs, recursion (in ASIL context), `setjmp`/`longjmp`, `<stdio.h>` in production code, tentative definitions in headers (Rule 8.18), inactive union member reads (Rule 19.3).
+
+### Guideline coverage
+
+Reason about each guideline from domain knowledge and cite it by identifier only (e.g. "MISRA C:2025 Rule 11.3"). Do not restate guideline wording — the user's licensed copy of MISRA C:2025 is the authoritative source for the normative text, rationale, amplification, and exceptions; direct the user to it for the canonical formulation of every finding. The full identifier index (categories Mandatory / Required / Advisory and C:2025 status changes) is in [`references/rules.md`](references/rules.md). If the applicability of a guideline to a specific construct is uncertain, say so explicitly and refer the user to the guideline in their licensed copy rather than paraphrasing from memory.
+
+### Legacy bring-up: incremental conformance
+
+When the input is legacy embedded C being modernized toward MISRA conformance (not a clean-sheet review), do not dump every violation as one flat list to "fix all at once" - that is unsafe on production safety code. Instead:
+
+1. **Characterize first.** Before recommending any change, note the assumed C standard (C89/C99) and the gap versus MISRA C:2012/2025, and flag that existing behavior must be pinned with characterization tests (Unity / CMocka / GoogleTest) before edits, so equivalence can be proven afterward. Defer the actual test design to the embedded-testing skill.
+2. **Group by rule-class, order by risk.** Bundle findings into shippable rule-classes (e.g. first essential-type model 10.x, then control flow 14.x/15.x, then pointer casts 11.x), each an independently verifiable step. Recommend the safest, lowest-coupling class first.
+3. **Smallest safe step.** For each rule-class give the minimal mechanical change set, not a sweeping rewrite. Magic numbers -> typed constants, bare types -> fixed-width, function-like macros -> `static inline` where interchangeable.
+4. **Deviation vs fix.** Where a legacy construct is load-bearing and a fix is riskier than a documented deviation, say so and provide the deviation skeleton instead of forcing a change.
+
+State explicitly that this is a staged plan and which step is safe to ship first.
+
+## Input expected
+
+- **Review mode**: C source file(s) or code snippet; optionally ASIL level, known intentional deviations to skip.
+- **Develop mode**: function/module/data-structure description; types, ranges, and units for inputs and outputs; optionally ASIL level and existing type definitions to reuse.
+
+## Output format
+
+### Review mode
+
+~~~
+## MISRA C:2025 Review
+
+### Findings
+
+| # | Rule | Category | Location | Description |
+|---|------|----------|----------|-------------|
+| 1 | X.Y  | R        | file.c:NN| Short description |
+
+---
+
+#### Finding 1 — Rule X.Y [Required]
+**Violated code:**
+```c
+[code excerpt]
+```
+**Explanation:** [why it violates the rule]
+**Corrected version:**
+```c
+[corrected code]
+```
+
+---
+
+### Deviation Template (if applicable)
+```
+DEV-MISRA-<RuleID>-<Seq>
+Rule:          MISRA C:2025 Rule X.Y
+Category:      Required / Advisory
+File(s):       <file.c>, line <N>
+Justification: <why the deviation is acceptable>
+Risk:          <residual risk assessment>
+Measures:      <compensating measures, e.g., code review, test coverage>
+Approved by:   <role>
+```
+
+### Summary
+- Mandatory violations: N (must fix)
+- Required violations: N (fix or formally deviate)
+- Advisory violations: N (review recommended)
+~~~
+
+### Develop mode
+
+~~~
+## MISRA-Compliant Implementation: <FunctionName / ModuleName>
+
+### Design Notes
+[Key MISRA rules applied and any deviations with justification]
+
+### Implementation
+```c
+[Complete, compilable, MISRA-compliant C code]
+```
+
+### Checklist
+- [ ] Rule 10.x: No implicit essential type conversions
+- [ ] Rule 14.4: All controlling expressions essentially Boolean
+- [ ] Rule 15.5: Single exit point (or deviation documented)
+- [ ] Rule 17.7: All non-void return values used
+- [ ] Rule 18.1: No out-of-bounds pointer arithmetic
+- [ ] No dynamic memory, VLAs, or recursion
+~~~
+
+## Example
+
+### Example 1 — Review mode
+
+**Input:**
+```c
+uint8_t buffer[8];
+int i;
+for (i = 0; i <= 8; i++) {   /* line 3 */
+    buffer[i] = 0;            /* line 4 */
+}
+unsigned int result = getValue(); /* line 6 */
+if (result) {                     /* line 7 */
+    process();
+}
+```
+
+**Output:**
+~~~
+## MISRA C:2025 Review
+
+### Findings
+| # | Rule    | Category | Location | Description                                |
+|---|---------|----------|----------|--------------------------------------------|
+| 1 | 1.3     | M        | line 4   | Out-of-bounds write — undefined behavior   |
+| 2 | 14.2    | R        | line 3   | `for` loop not well-formed — bound `i <= 8` permits out-of-bounds index |
+| 3 | 14.4    | R        | line 7   | Controlling expression not essentially Boolean |
+| 4 | Dir 4.6 | A        | line 2,6 | Bare `int` / `unsigned int` used; use fixed-size types from `<stdint.h>` |
+
+---
+
+#### Finding 1 — Rule 1.3 [Mandatory]
+**Violated code:**
+```c
+for (i = 0; i <= 8; i++) {
+    buffer[i] = 0;  /* writes buffer[8] — one past end */
+}
+```
+**Explanation:** Loop bound `i <= 8` causes a write to `buffer[8]`, which is outside the
+declared array of size 8. This is undefined behavior (out-of-bounds write) and cannot be deviated.
+**Corrected version:**
+```c
+for (i = 0; i < 8; i++) {
+    buffer[i] = 0U;
+}
+```
+
+#### Finding 2 — Rule 14.2 [Required]
+**Explanation:** Rule 14.2 requires a `for` loop to be well-formed. The condition `i <= 8` on an 8-element array allows `i` to reach index 8 (one past end), which is the same out-of-bounds access caught by Rule 1.3. The correct bound is `i < 8`.
+
+#### Finding 3 — Rule 14.4 [Required]
+**Violated code:** `if (result)` — `result` is `unsigned int`, not Boolean.
+**Corrected version:** `if (result != 0U)`
+
+#### Finding 4 — Directive 4.6 [Advisory]
+**Violated code:**
+```c
+int i;
+unsigned int result = getValue();
+```
+**Explanation:** Directive 4.6 advises against bare `int` / `unsigned int` because the width
+is implementation-defined. Use fixed-size types from `<stdint.h>` for portability.
+**Corrected version:**
+```c
+uint8_t  i;                       /* loop index, bounded by 8 */
+uint32_t result = getValue();     /* assuming getValue() also returns a fixed-size type */
+```
+~~~
+
+### Example 2 — Develop mode
+
+**Input:**
+Write a saturating add function for uint16 values. If the result exceeds UINT16_MAX, return
+UINT16_MAX. ASIL-B.
+
+**Output:**
+~~~
+## MISRA-Compliant Implementation: U16_SaturatingAdd
+
+### Design Notes
+- Promotion to uint32 before addition prevents uint16 overflow (Rule 10.1, 10.4).
+- Result comparison is type-safe: uint32 compared with uint32 constant (Rule 10.4).
+- Single exit point (per ISO 26262 Part 6 project standard, even though Rule 15.5 disapplied).
+- Return value is the function's only output — caller must use it (Rule 17.7 applies at call sites).
+
+### Implementation
+```c
+/**
+ * @brief  Add two uint16 values with saturation at UINT16_MAX.
+ * @param  a  First operand.
+ * @param  b  Second operand.
+ * @return Sum clamped to [0, 65535].
+ */
+uint16 U16_SaturatingAdd(uint16 a, uint16 b)
+{
+    uint32 sum;
+    uint16 result;
+
+    sum = (uint32)a + (uint32)b;  /* promote to prevent overflow */
+
+    if (sum > (uint32)0xFFFFU) {
+        result = (uint16)0xFFFFU;
+    } else {
+        result = (uint16)sum;     /* safe: sum proven <= 0xFFFF */
+    }
+
+    return result;
+}
+```
+
+### Checklist
+- [x] Rule 10.x: uint16 operands promoted to uint32 before addition; narrowing cast justified
+- [x] Rule 14.4: `sum > (uint32)0xFFFFU` is an essentially Boolean expression
+- [x] Rule 15.5: Single return at end of function
+- [x] Rule 17.7: Function returns uint16; caller responsibility to use it
+- [x] Rule 18.1: No pointer arithmetic
+- [x] No dynamic memory, VLAs, or recursion
+~~~
+
+## HTML report (optional, additive)
+
+After the inline answer above, when the findings are substantial enough to persist (a set of MISRA violations with fixes, a full-file audit), offer to also write a self-contained HTML report. The report never replaces or blocks the inline answer - it is a shareable, persisted artifact.
+
+**Structure - progressive disclosure, lean not dense:**
+- *Header (thin):* file(s) analyzed, timestamp, "MISRA C:2025 review", scope (ASIL, standard year).
+- *Layer 1 - summary banner (always visible):* one row of 4-5 numbers - total violations, mandatory / required / advisory counts, files affected, count with a suggested fix. The reader grasps the shape in two seconds.
+- *Layer 2 - grouped table (scannable):* one row per finding, grouped by file or by rule. Lean columns only - location, rule id, one-line description, severity chip, "fix available" indicator. No fix text or code snippets in the rows. Include a search/filter box and sortable columns.
+- *Layer 3 - expandable detail (`<details>`, collapsed by default):* per finding - why it fires, the offending snippet, the suggested compliant rewrite, and for a Required/Advisory rule whether a documented deviation is the better call with the justification skeleton.
+- *Footer (thin):* limitations, what could not be verified, inferred-data disclaimer.
+
+**Style:** one self-contained `.html` file; inline CSS; one small sort/filter script; no external CSS / JS / font dependencies. ASCII only, no em dashes. Severity and status shown as small colored chips, not walls of text. If in doubt, push detail into Layer 3 and keep Layers 1-2 minimal. Use [`references/html-report-template.html`](references/html-report-template.html) as the skeleton: fill the header, the Layer 1 stat cells, one lean table row per finding, and one collapsed `<details>` block per finding.
+
+**Where to write it:**
+1. Detect a project root by walking up from the working directory for `.git` or another clear project marker.
+2. **Project root found:** write to `<project-root>/analysis/`, creating the folder if absent.
+3. **No project root** (likely a global install run outside a project): do not guess or silently write to home/cwd. Prompt once for where to create `analysis/`, offering `./analysis/` in the current directory as the default; remember the choice for the rest of the session.
+4. Always report the exact path written.
+5. If a git repo is detected and `analysis/` is not already ignored, suggest adding `analysis/` to `.gitignore`.
+
+Filename: `analysis/misra-<short-timestamp>.html` (for example `misra-20260621-1930.html`) so repeated runs do not overwrite.

package/skills/code-quality/misra/references/html-report-template.html

@@ -0,0 +1,154 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Analysis Report</title>
+<!--
+  Shared report skeleton for autonomousguy skills. Self-contained: inline CSS,
+  one small sort/filter script, no external dependencies. ASCII only, no em dashes.
+  Fill the placeholders below. Keep Layers 1-2 lean; push detail into Layer 3.
+  The skill decides the Layer 1 metrics, the table columns, and the detail content.
+-->
+<style>
+  :root {
+    --fg: #1b1f24; --muted: #5b6470; --line: #e1e4e8; --bg: #ffffff;
+    --chip-red-bg: #ffe3e3; --chip-red-fg: #9b1c1c;
+    --chip-amber-bg: #fff4d6; --chip-amber-fg: #8a5a00;
+    --chip-blue-bg: #e3effe; --chip-blue-fg: #1b4f9b;
+    --chip-gray-bg: #eceff2; --chip-gray-fg: #44505c;
+    --chip-green-bg: #e3f7e8; --chip-green-fg: #1d6b34;
+  }
+  body { margin: 0; padding: 0 20px 40px; color: var(--fg); background: var(--bg);
+    font-family: -apple-system, Segoe UI, Roboto, Helvetica, Arial, sans-serif;
+    font-size: 14px; line-height: 1.45; }
+  header { padding: 18px 0 10px; border-bottom: 1px solid var(--line); }
+  header h1 { font-size: 18px; margin: 0 0 4px; }
+  header .meta { color: var(--muted); font-size: 12px; }
+  /* Layer 1 - summary banner */
+  .summary { display: flex; flex-wrap: wrap; gap: 14px; margin: 16px 0; }
+  .stat { border: 1px solid var(--line); border-radius: 8px; padding: 10px 14px; min-width: 96px; }
+  .stat .n { font-size: 22px; font-weight: 600; }
+  .stat .l { font-size: 11px; color: var(--muted); text-transform: uppercase; letter-spacing: .03em; }
+  /* Controls */
+  .controls { margin: 8px 0 6px; }
+  .controls input { width: 280px; max-width: 100%; padding: 6px 9px; font-size: 13px;
+    border: 1px solid var(--line); border-radius: 6px; }
+  /* Layer 2 - table */
+  table { width: 100%; border-collapse: collapse; font-size: 13px; }
+  th, td { text-align: left; padding: 7px 10px; border-bottom: 1px solid var(--line); vertical-align: top; }
+  th { cursor: pointer; user-select: none; white-space: nowrap; background: #fafbfc; }
+  th[data-sort]:after { content: " \2195"; color: var(--muted); font-size: 10px; }
+  tbody tr:hover { background: #fafbfc; }
+  /* Chips */
+  .chip { display: inline-block; padding: 1px 8px; border-radius: 10px; font-size: 11px; font-weight: 600; }
+  .chip-mandatory, .chip-high, .chip-critical { background: var(--chip-red-bg); color: var(--chip-red-fg); }
+  .chip-required, .chip-medium, .chip-major { background: var(--chip-amber-bg); color: var(--chip-amber-fg); }
+  .chip-advisory, .chip-low, .chip-minor { background: var(--chip-blue-bg); color: var(--chip-blue-fg); }
+  .chip-info { background: var(--chip-gray-bg); color: var(--chip-gray-fg); }
+  .chip-fix { background: var(--chip-green-bg); color: var(--chip-green-fg); }
+  /* Layer 3 - details */
+  .details { margin-top: 22px; }
+  .details h2 { font-size: 14px; border-bottom: 1px solid var(--line); padding-bottom: 6px; }
+  details { border: 1px solid var(--line); border-radius: 8px; margin: 8px 0; padding: 6px 12px; }
+  details summary { cursor: pointer; font-weight: 600; }
+  details pre { background: #f6f8fa; padding: 10px; border-radius: 6px; overflow-x: auto; font-size: 12px; }
+  details .label { color: var(--muted); font-size: 11px; text-transform: uppercase; letter-spacing: .03em; margin-top: 10px; }
+  footer { margin-top: 28px; padding-top: 12px; border-top: 1px solid var(--line);
+    color: var(--muted); font-size: 12px; }
+</style>
+</head>
+<body>
+
+<!-- Header (thin): what was analyzed, timestamp, skill/tool, scope -->
+<header>
+  <h1>{{REPORT_TITLE}}</h1>
+  <div class="meta">{{SCOPE}} &middot; {{SKILL_NAME}} &middot; generated {{TIMESTAMP}}</div>
+</header>
+
+<!-- Layer 1: summary banner - 4 to 5 numbers only -->
+<section class="summary">
+  <div class="stat"><div class="n">{{N1}}</div><div class="l">{{L1}}</div></div>
+  <div class="stat"><div class="n">{{N2}}</div><div class="l">{{L2}}</div></div>
+  <div class="stat"><div class="n">{{N3}}</div><div class="l">{{L3}}</div></div>
+  <div class="stat"><div class="n">{{N4}}</div><div class="l">{{L4}}</div></div>
+  <div class="stat"><div class="n">{{N5}}</div><div class="l">{{L5}}</div></div>
+</section>
+
+<!-- Layer 2: grouped table - one lean row per finding, no snippets here -->
+<div class="controls">
+  <input id="filter" type="text" placeholder="Filter findings..." oninput="filterRows()">
+</div>
+<table id="findings">
+  <thead>
+    <tr>
+      <th data-sort="0">Location</th>
+      <th data-sort="1">ID / Rule</th>
+      <th data-sort="2">Description</th>
+      <th data-sort="3">Severity</th>
+      <th data-sort="4">Fix</th>
+    </tr>
+  </thead>
+  <tbody>
+    <!-- Example rows; replace with one row per finding. Link the Fix cell or a row id to its detail below. -->
+    <tr>
+      <td>file.c:42</td><td>Rule 14.4</td><td>Controlling expression not essentially Boolean</td>
+      <td><span class="chip chip-required">Required</span></td>
+      <td><span class="chip chip-fix">fix</span></td>
+    </tr>
+    <tr>
+      <td>file.c:8</td><td>Dir 4.6</td><td>Bare int used; prefer fixed-width type</td>
+      <td><span class="chip chip-advisory">Advisory</span></td>
+      <td><span class="chip chip-fix">fix</span></td>
+    </tr>
+  </tbody>
+</table>
+
+<!-- Layer 3: expandable detail, collapsed by default -->
+<section class="details">
+  <h2>Details</h2>
+  <details>
+    <summary>file.c:42 - Rule 14.4 (Required)</summary>
+    <div class="label">Why it fires</div>
+    <div>{{EXPLANATION}}</div>
+    <div class="label">Offending snippet</div>
+    <pre>{{SNIPPET}}</pre>
+    <div class="label">Suggested rewrite</div>
+    <pre>{{REWRITE}}</pre>
+    <div class="label">Deviation (if applicable)</div>
+    <div>{{DEVIATION_JUSTIFICATION_SKELETON}}</div>
+  </details>
+  <!-- Repeat one <details> per finding. -->
+</section>
+
+<!-- Footer (thin): limitations, what could not be verified, inferred-data disclaimer -->
+<footer>
+  {{LIMITATIONS}} Could not verify: {{COULD_NOT_VERIFY}}. Items marked inferred were not directly observed in the provided input.
+</footer>
+
+<script>
+  function filterRows() {
+    var q = document.getElementById('filter').value.toLowerCase();
+    var rows = document.querySelectorAll('#findings tbody tr');
+    rows.forEach(function (r) {
+      r.style.display = r.textContent.toLowerCase().indexOf(q) > -1 ? '' : 'none';
+    });
+  }
+  document.querySelectorAll('#findings th[data-sort]').forEach(function (th) {
+    th.addEventListener('click', function () {
+      var idx = +th.getAttribute('data-sort');
+      var tb = document.querySelector('#findings tbody');
+      var rows = Array.prototype.slice.call(tb.querySelectorAll('tr'));
+      var asc = th.getAttribute('data-asc') !== 'true';
+      th.setAttribute('data-asc', asc);
+      rows.sort(function (a, b) {
+        var x = a.cells[idx].textContent.trim().toLowerCase();
+        var y = b.cells[idx].textContent.trim().toLowerCase();
+        return asc ? (x < y ? -1 : x > y ? 1 : 0) : (x > y ? -1 : x < y ? 1 : 0);
+      });
+      rows.forEach(function (r) { tb.appendChild(r); });
+    });
+  });
+</script>
+</body>
+</html>

package/skills/code-quality/misra/references/rules.md

@@ -0,0 +1,72 @@
+# MISRA C:2025 - guideline index (identifiers and status only)
+
+This is an index of MISRA C:2025 guideline identifiers with their category (Mandatory / Required / Advisory) and C:2025 status. It deliberately does NOT reproduce the normative guideline text, headline wording, rationale, amplification, examples, or exception clauses - those are copyrighted by The MISRA Consortium Ltd. and are not redistributable.
+
+Use this index to know which identifiers exist, their enforcement category, and what changed in C:2025, then cite the identifier (e.g. "MISRA C:2025 Rule 11.3"). For the canonical wording and how to apply each guideline, consult your licensed copy of MISRA C:2025 (the authoritative source). The skill reasons about the intent of each guideline from domain knowledge; it does not need the normative text reproduced here.
+
+Legend: **M** = Mandatory, **R** = Required, **A** = Advisory.
+Status flags: *(new)* added in C:2025, *(disapplied)* no longer enforced in C:2025, *(refined)* wording or scope changed in C:2025.
+
+---
+
+## Directives (22 total)
+
+- Dir 1.1 (R)
+- Dir 2.1 (R)
+- Dir 3.1 (R)
+- Dir 4.1 (R), Dir 4.2 (A), Dir 4.3 (R), Dir 4.4 (A), Dir 4.5 (A), Dir 4.6 (A), Dir 4.7 (R), Dir 4.8 (A), Dir 4.9 (A), Dir 4.10 (R), Dir 4.11 (R), Dir 4.12 (R), Dir 4.13 (A), Dir 4.14 (R), Dir 4.15 (R)
+
+## Rules (~201 total)
+
+- Rule 1.1 (M), 1.2 (A), 1.3 (M), 1.4 (M), 1.5 (R)
+- Rule 2.1 (R), 2.2 (R), 2.3 (A), 2.4 (A), 2.5 (A), 2.6 (M), 2.7 (A), 2.8 (A)
+- Rule 3.1 (M), 3.2 (M)
+- Rule 4.1 (R), 4.2 (A)
+- Rule 5.1 (R), 5.2 (R), 5.3 (R), 5.4 (R), 5.5 (R), 5.6 (R), 5.7 (R), 5.8 (R), 5.9 (A)
+- Rule 6.1 (R), 6.2 (R), 6.3 (R) *(new)*
+- Rule 7.1 (R), 7.2 (R), 7.3 (R), 7.4 (R), 7.5 (R) *(refined)*, 7.6 (R) *(refined)*
+- Rule 8.1 (R), 8.2 (R), 8.3 (R), 8.4 (R), 8.5 (R), 8.6 (R), 8.7 (A), 8.8 (R), 8.9 (A), 8.10 (R), 8.11 (A), 8.12 (R), 8.13 (A), 8.14 (R), 8.15 (R), 8.16 (A), 8.17 (A), 8.18 (R) *(new)*, 8.19 (A) *(new)*
+- Rule 9.1 (M), 9.2 (R), 9.3 (R), 9.4 (R), 9.5 (R), 9.6 (A) *(new)*, 9.7 (M) *(refined)*
+- Rule 10.1 (R), 10.2 (R), 10.3 (R), 10.4 (R), 10.5 (A), 10.6 (R), 10.7 (R), 10.8 (R)
+- Rule 11.1 (R), 11.2 (R), 11.3 (R), 11.4 (A), 11.5 (A), 11.6 (R), 11.7 (R), 11.8 (R), 11.9 (R), 11.10 (R), 11.11 (A) *(new)*
+- Rule 12.1 (A), 12.2 (R), 12.3 (A), 12.4 (A), 12.5 (M), 12.6 (R) *(refined)*
+- Rule 13.1 (R), 13.2 (R), 13.3 (A), 13.4 (A), 13.5 (R), 13.6 (M)
+- Rule 14.1 (R), 14.2 (R), 14.3 (R), 14.4 (R)
+- Rule 15.1 (A), 15.2 (R), 15.3 (R), 15.4 (A), 15.5 *(disapplied)*, 15.6 (R), 15.7 (R)
+- Rule 16.1 (R), 16.2 (R), 16.3 (R), 16.4 (R), 16.5 (R), 16.6 (R), 16.7 (R)
+- Rule 17.1 (R), 17.2 (R), 17.3 (M), 17.4 (M), 17.5 (A), 17.6 (M), 17.7 (R), 17.8 (A), 17.9 (R) *(refined)*, 17.10 (R) *(refined)*, 17.11 (A), 17.12 (A), 17.13 (R)
+- Rule 18.1 (R), 18.2 (R), 18.3 (R), 18.4 (A), 18.5 (A), 18.6 (R), 18.7 (R), 18.8 (R), 18.9 (R) *(refined)*, 18.10 (M) *(new)*
+- Rule 19.1 (M), 19.2 (A), 19.3 (R) *(new)*
+- Rule 20.1 (A), 20.2 (R), 20.3 (R), 20.4 (R), 20.5 (A), 20.6 (R), 20.7 (R), 20.8 (R), 20.9 (R), 20.10 (A), 20.11 (R), 20.12 (R), 20.13 (R), 20.14 (R)
+- Rule 21.1 (R), 21.2 (R), 21.3 (R), 21.4 (R), 21.5 (R), 21.6 (R), 21.7 (R), 21.8 (R), 21.9 (R), 21.10 (R), 21.11 (R), 21.12 (A), 21.13 (M), 21.14 (R), 21.15 (R), 21.16 (R), 21.17 (R), 21.18 (R), 21.19 (M), 21.20 (M), 21.21 (R), 21.22 (M), 21.23 (R), 21.24 (R), 21.25 (R), 21.26 (R)
+- Rule 22.1 (R), 22.2 (M), 22.3 (R), 22.4 (M), 22.5 (M), 22.6 (M), 22.7 (R), 22.8 (R), 22.9 (R), 22.10 (R), 22.11 (R), 22.12 (M), 22.13 (R), 22.14 (M), 22.15 (R), 22.16 (R), 22.17 (R), 22.18 (R), 22.19 (R), 22.20 (M)
+
+Category groupings (MISRA's chapter structure): 1 Standards, 2 Unused code, 3 Comments, 4 Character sets, 5 Identifiers, 6 Types, 7 Literals and constants, 8 Declarations and definitions, 9 Initialisation, 10 Essential type model, 11 Pointer type conversions, 12 Expressions, 13 Side effects, 14 Control statement expressions, 15 Control flow, 16 Switch statements, 17 Functions, 18 Pointers and arrays, 19 Overlapping storage, 20 Preprocessing directives, 21 Standard libraries, 22 Resources.
+
+---
+
+## C:2025 deltas
+
+The four guidelines added in C:2025, described here in our own words (intent only - see the standard for the normative text):
+
+- **Rule 8.18 (R)** *(new)*: avoid tentative object definitions in header files, so that including a header in several translation units does not silently create duplicate objects.
+- **Rule 8.19 (A)** *(new)*: prefer defining an object at the narrowest block scope where it is used rather than at file scope, to limit its lifetime and visibility.
+- **Rule 11.11 (A)** *(new)*: compare pointers explicitly (for example against NULL) rather than relying on the implicit truthiness of a pointer in a condition, making the intent unambiguous.
+- **Rule 19.3 (R)** *(new)*: read only the union member that was last written (the active member); reading a different member is undefined behaviour.
+
+Other C:2025 changes:
+- **Rule 15.5** is disapplied (the single-exit-point guideline is no longer enforced by C:2025). Projects deriving rules from ISO 26262 Part 6 may still choose to enforce single-exit for ASIL-C/D.
+- 69 guidelines were refined in wording or scope; the ones flagged *(refined)* above are the most commonly relevant (notably 7.5/7.6, 9.7, 12.6, 17.9/17.10, 18.9, plus the new mandatory 18.10).
+
+When a project pins to C:2023, the four C:2025 additions and the 15.5 disapplication are the deltas to surface in any review or deviation report.
+
+---
+
+## Tool-flow notes
+
+| Tool | C:2025 support status |
+|------|------------------------|
+| Helix QAC | Native C:2025 ruleset since QAC 2024.2 |
+| Polyspace Bug Finder | C:2023 + Amd4 covered; C:2025 deltas planned |
+| LDRA Testbed | C:2023 with C:2025 deltas via update packs |
+| PC-lint Plus | Configurable rule pack; check vendor for C:2025 add-on |