aspice-code-review

name	aspice-code-review
description	Combined ASPICE SWE.3 + MISRA-C:2012 + AUTOSAR C++14 deep code review workflow for automotive embedded software. Use when performing a thorough pre-merge review of C or C++ source files, checking file and function headers, inline traceability tags, ASIL defensive programming, MISRA-C or AUTOSAR C++14 rule compliance, testability, and producing a formal review record with all findings classified by severity.
argument-hint	File path or paste C/C++ source code to review
user-invocable	true

ASPICE Code Review Skill (SWE.3 + Coding Standards)

When to Use

• Pre-merge code review for a feature or fix branch targeting an ASIL A/B component
• Formal SWE.3 review before a status transition from DRAFT to IN_REVIEW
• Reviewing code for MISRA-C:2012 compliance (.c / .h files)
• Reviewing code for AUTOSAR C++14 compliance (.cpp / .hpp files)
• Verifying traceability tags and function contracts are complete
• Producing a formal review record as a CL2 work product

---

Workflow

Phase 1 — Setup

1. Determine the language from file extension:
   • .c / .h → apply MISRA-C:2012 rules
   • .cpp / .hpp → apply AUTOSAR C++14 rules
2. Extract ASIL level from @asil file header tag.
3. Extract SWC-XXXX and SWE-REQ-XXXX IDs from the file header.
4. Note the @status field — only DRAFT files are expected in this workflow.

Phase 2 — CL2 Work Product Header Audit

Check	Status
File header present with all mandatory fields	✅ / ❌
@file, @component, @req, @asil, @version, @status, @author, @reviewer all present	✅ / ❌
Status is appropriate for current phase	✅ / ❌

Phase 3 — Function Contract Audit

For every non-static public function:

Check	Status
@req SWE-REQ-XXXX traceability tag present	✅ / ❌
@asil tag present and consistent with file ASIL	✅ / ❌
@pre precondition documented	✅ / ❌
@post postcondition documented	✅ / ❌
All @param entries present with range and unit	✅ / ❌
@return documents all possible values	✅ / ❌
At least one /* [SWE-REQ-XXXX] */ inline tag inside body	✅ / ❌

Phase 4 — ASIL Defensive Programming Audit (ASIL A/B Only)

For every function tagged @asil A or @asil B:

Defensive Check	Status
All pointer parameters checked for NULL before dereference	✅ / ❌
All scalar inputs validated against documented range before first use	✅ / ❌
Every fallible function call result is checked	✅ / ❌
Every switch has a default case with error handler	✅ / ❌
No implicit narrowing conversions	✅ / ❌
No file-scope non-static writable variables	✅ / ❌

Phase 5 — Coding Standard Deep Scan

MISRA-C:2012 Checks (C files)

Scan for each category in misra-c-coding-standard.instructions.md:

Mandatory (zero tolerance):

• goto usage (Rule 15.1)
• Missing return value on non-void exit path (Rule 17.4)
• Pointer type casts between incompatible types (Rule 11.3)

Required (must fix or deviate):

• Dynamic memory allocation post-init (Rule 21.3)
• Recursion (Rule 17.2)
• printf/scanf family (Rule 21.6)
• Missing default in switch (Rule 16.4)
• Essential type violations (Rules 10.1, 10.3)
• Integer constants without type suffixes (Rule 7.2)

Advisory (enforce for ASIL A/B):

• Unchecked function return values (Dir 4.7)
• Non-essentially-Boolean controlling expression (Rule 14.4)
• Multiple return points (Rule 15.5)

AUTOSAR C++14 Checks (C++ files)

Scan for each category in autosar-cpp14-coding-standard.instructions.md:

Mandatory (zero tolerance):

• dynamic_cast / typeid / RTTI (A27-0-1)
• longjmp (A6-6-2)
• goto (A6-6-1)

Required (must fix or deviate):

• new / delete after init (A18-5-2/3)
• C-style casts (T)expr (A5-2-2)
• NULL instead of nullptr (A27-0-4)
• reinterpret_cast without deviation record (A5-2-4)
• throw in ASIL code path (A15-0-1)
• Enum without explicit underlying type (A7-2-2)

Phase 6 — Forbidden Constructs Final Scan

Check for any occurrence of:

• goto, setjmp, longjmp — always forbidden
• malloc, calloc, realloc, free, new, delete outside init code — flag for review
• Recursive call chains — trace function calls for any direct or indirect recursion

Phase 7 — Testability Assessment

• Logic separated from hardware I/O (no register access in business logic)
• Module state is resettable via _Init() or _Reset() for unit testing
• No hard-coded magic numbers without named constants
• Functions are ≤ 60 lines of executable code

Phase 8 — Deviation Record Completeness

For any known existing deviation comments in the code, verify:

• Rule ID is cited
• Justification is documented
• Risk assessment is present
• Reviewer name and date are included
• PRQA / NOLINT suppression annotation is present

Phase 9 — Produce Formal Review Record

ASPICE SWE.3 Code Review Record
================================
File          : <filename>
Component     : SWC-XXXX
ASIL Level    : QM | A | B
Language      : C (MISRA-C:2012) | C++ (AUTOSAR C++14)
Review Date   : <today's date>
Reviewer      : GitHub Copilot (automated pre-review)

FINDINGS
--------
[CR-001] Severity: MANDATORY | REQUIRED | ADVISORY
  Rule       : <Rule ID>
  Function   : <function name>
  Description: <specific violation>
  Remediation: <exact corrective action>

SUMMARY
-------
Work Product Header  : PASS / FAIL (<n> gaps)
Function Contracts   : PASS / FAIL (<n> incomplete headers)
Inline Traceability  : PASS / FAIL (<n> missing tags)
Defensive Programming: PASS / FAIL (<n> gaps) [N/A for QM]
Coding Standard      : PASS / FAIL  (MANDATORY: <n>, REQUIRED: <n>, ADVISORY: <n>)
Testability          : PASS / FAIL (<n> concerns)
Total Findings       : <n>
Overall Verdict      : APPROVED_FOR_REVIEW | NEEDS_REWORK

Note: This is an automated pre-review. Human review sign-off is required for
      status transition to IN_REVIEW → APPROVED.

---

Output Artefacts

• Formal Code Review Record (CL2 work product — attach to file review history)
• Classified findings list (MANDATORY/REQUIRED/ADVISORY)
• Deviation record stubs for any violations that cannot be fixed

References

• SWE.3 Instructions
• MISRA-C Instructions
• AUTOSAR C++14 Instructions
• Code Review Prompt