autonomousguy 0.6.4

package/skills/autosar/autosar-swc/references/rte-api.md

@@ -0,0 +1,149 @@
+# AUTOSAR Classic RTE API & Port-Interface Reference
+
+Reference for AUTOSAR Classic Platform RTE APIs, port-interface ComSpecs, runnable activation events, and platform/application data types. Use alongside the SKILL.md autosar-swc modes when you need the canonical naming or a quick lookup for a specific API.
+
+## RTE API naming convention
+
+All RTE APIs follow: `Rte_<access>_<portName>_<elementOrOperation>()`.
+
+| `<access>` | Used for                                          | Example                                              |
+|------------|---------------------------------------------------|------------------------------------------------------|
+| `Read`     | S/R receiver, explicit access                     | `Rte_Read_RBattVoltage_Voltage_mV(&v)`              |
+| `Write`    | S/R sender, explicit access                       | `Rte_Write_PLowVoltageWarning_Active(TRUE)`          |
+| `IRead`    | S/R receiver, implicit access (data copied to local DEH at runnable start) | `v = Rte_IRead_MainRunnable_RBattVoltage_Voltage_mV()` |
+| `IWrite`   | S/R sender, implicit access                       | `Rte_IWrite_MainRunnable_PLowVoltageWarning_Active(TRUE)` |
+| `Call`     | C/S client operation invocation                   | `Rte_Call_RNvMService_ReadBlock(blockId, &buf)`     |
+| `Result`   | C/S client async operation result                 | `Rte_Result_RNvMService_ReadBlock(&status)`         |
+| `Receive`  | S/R receiver, queued (event semantics)            | `Rte_Receive_REvent_Type(&evt)`                      |
+| `Send`     | S/R sender, queued                                 | `Rte_Send_PEvent_Type(evt)`                          |
+| `Mode`     | Mode switch current mode read                     | `Rte_Mode_RWindowMode_currentMode()`                 |
+| `Switch`   | Mode switch issue                                  | `Rte_Switch_PWindowMode_mode(WINDOW_MOVING_UP)`      |
+| `Enter`/`Exit` | ExclusiveArea critical section               | `Rte_Enter_EA_CoolantState() / Rte_Exit_EA_CoolantState()` |
+| `Trigger`  | Trigger an InterRunnableTriggerEvent              | `Rte_Trigger_PMyTrigger()`                           |
+| `Feedback` | TX confirmation from a sender                     | `Rte_Feedback_PCanSignal_Value()`                    |
+
+Naming convention for the port: `P<InterfaceName>` for provided, `R<InterfaceName>` for required.
+
+## Port interface types
+
+### SenderReceiver (S/R)
+
+Used for continuous or periodic data streams (sensor values, status flags, calculated outputs).
+
+**Sender ComSpec**:
+- `InitValue` — value transmitted before the runnable produces its first real output. Use a value that downstream consumers can recognise as "not yet valid" (often the same as the receiver's init).
+
+**Receiver ComSpec**:
+- `InitValue` — what the receiver reads if no message has arrived (e.g., before init, after timeout).
+- `AliveTimeout` — for safety-relevant signals, max time without an update before the receiver applies the InitValue. `0` disables. Typically `2× sender period` for ASIL-tagged signals.
+- `HandleOutOfRange` — what the receiver does if the sender writes outside the data type range.
+
+### ClientServer (C/S)
+
+Used for request/response (NvM read/write, diagnostic request, calibration trigger).
+
+- Synchronous: server runs in caller context (return immediately).
+- Asynchronous: server runs in its own context; client uses `Rte_Result_*` to poll.
+- Operations carry `IN` / `OUT` / `INOUT` arguments and a `Std_ReturnType` (`E_OK`/`E_NOT_OK`) plus optional ApplicationErrors.
+
+### Mode Switch
+
+Used for mode-dependent runnable activation. ModeDeclarationGroup defines the set of modes; mode-switching SWC issues `Rte_Switch_*`; receiving runnables can be activated by `OnEntry`/`OnExit` events or guarded by `DisabledModeRef`.
+
+### Parameter
+
+Used for calibration data — runtime-readable but normally fixed at integration. Provided by a ParameterSWC or mapped to a NvM block.
+
+## Runnable activation events
+
+| Event                      | When the runnable fires                                  | Notes                                    |
+|----------------------------|----------------------------------------------------------|------------------------------------------|
+| `InitEvent`                 | Once during SWC startup                                  | Use for one-shot init only               |
+| `TimingEvent`               | Periodically with a configured period (e.g., 10 ms)      | Most common for periodic algorithms      |
+| `DataReceivedEvent`         | A new value arrives on an S/R receiver port              | For event-driven processing              |
+| `DataReceivedErrorEvent`    | A receive error occurred (timeout, range violation)      | Safety reaction hook                     |
+| `DataSendCompletedEvent`    | An S/R send completed (confirmation)                     | TX feedback handler                      |
+| `OperationInvokedEvent`     | A C/S server operation is invoked                        | Implements the server side               |
+| `AsynchronousServerCallReturnsEvent` | An async C/S call completes                     | Client-side completion handler           |
+| `SwcModeSwitchEvent`        | The mode of a referenced ModeDeclarationGroup changes    | Use with `OnEntry` / `OnExit` specifier  |
+| `ModeSwitchedAckEvent`      | Acknowledgement of a mode switch                         | Mode-coordination handshake              |
+| `BackgroundEvent`           | When no other runnable is ready (lowest priority)        | Use sparingly                            |
+| `InterRunnableTriggerEvent` | One runnable triggers another within the same SWC        | Lightweight intra-SWC dispatch           |
+
+## ExclusiveArea
+
+Protects shared variables accessed by multiple runnables (or a runnable + ISR).
+
+Declaration: `<EXCLUSIVE-AREA><SHORT-NAME>EA_MyArea</SHORT-NAME></EXCLUSIVE-AREA>` in the SWC InternalBehavior.
+
+Usage:
+```c
+Rte_Enter_EA_MyArea();
+/* critical section */
+Rte_Exit_EA_MyArea();
+```
+
+The RTE generator maps each ExclusiveArea to an `OsResource` (or interrupt-disable region, depending on `RteExclusiveAreaImplMechanism` config). Two runnables both calling `Rte_Enter_EA_MyArea()` are guaranteed mutual exclusion.
+
+## AUTOSAR platform types vs C99
+
+| Use case                            | AUTOSAR Classic       | C99 `<stdint.h>` (do NOT mix in SWC code) |
+|-------------------------------------|-----------------------|--------------------------------------------|
+| 8-bit unsigned                       | `uint8`              | `uint8_t`                                  |
+| 16-bit unsigned                      | `uint16`             | `uint16_t`                                 |
+| 32-bit unsigned                      | `uint32`             | `uint32_t`                                 |
+| 8-bit signed                         | `sint8`              | `int8_t`                                   |
+| 16-bit signed                        | `sint16`             | `int16_t`                                  |
+| 32-bit signed                        | `sint32`             | `int32_t`                                  |
+| Boolean                              | `boolean` (`TRUE`/`FALSE`) | `bool` or `int`                       |
+| Float                                | `float32`            | `float`                                    |
+| Double                               | `float64`            | `double`                                   |
+
+**Convention:** platform types have **no `_t` suffix**. ApplicationDataTypes (project-defined semantic typedefs over a platform type) conventionally **do** use `_t` (e.g., `BatMon_Voltage_mV_t`).
+
+`Std_ReturnType` from `Std_Types.h`: `E_OK` (0), `E_NOT_OK` (1), or application-specific extensions (0x02–0x3F reserved for AUTOSAR; >= 0x40 for user errors).
+
+## SWC type quick reference
+
+| SWC type           | Allowed to                                              | Forbidden                                |
+|--------------------|---------------------------------------------------------|------------------------------------------|
+| Application        | RTE access only                                          | Direct BSW, direct MCAL, register access |
+| Sensor/Actuator    | RTE + IoHwAb (which bridges to MCAL)                     | Direct MCAL or register access           |
+| Service            | RTE + the wrapped BSW module (NvM, Dem, Dcm, Com)         | Direct MCAL or register access           |
+| Complex Device Driver | Direct MCAL or register access (with documented rationale) | RTE access from other SWCs only via ports |
+| Composition        | Groups other SWCs; no behaviour of its own               | No runnables                             |
+
+## MCAL abstraction rule
+
+Application and Service SWCs **must not** access hardware registers or call MCAL APIs directly. All hardware interaction routes through:
+- **IoHwAb** (I/O Hardware Abstraction) for sensors and actuators (Dio, Adc, Pwm, Spi via wrapper).
+- **BSW modules** for communication (Com), persistence (NvM), diagnostics (Dem, Dcm), and OS (Os).
+
+A Complex Device Driver (CDD) is the only SWC type allowed direct MCAL access, and only when the documented rationale (timing, custom protocol, etc.) shows IoHwAb is insufficient.
+
+## ARXML element quick reference
+
+| Element                                | Purpose                                                    |
+|----------------------------------------|------------------------------------------------------------|
+| `APPLICATION-SW-COMPONENT-TYPE`        | Application SWC type definition                            |
+| `SENSOR-ACTUATOR-SW-COMPONENT-TYPE`    | Sensor/Actuator SWC type definition                        |
+| `SERVICE-SW-COMPONENT-TYPE`            | Service SWC type definition                                |
+| `COMPLEX-DEVICE-DRIVER-SW-COMPONENT-TYPE` | CDD definition                                          |
+| `COMPOSITION-SW-COMPONENT-TYPE`        | Composition wrapping other SWCs                            |
+| `P-PORT-PROTOTYPE`                     | Provided port                                              |
+| `R-PORT-PROTOTYPE`                     | Required port                                              |
+| `PR-PORT-PROTOTYPE`                    | Combined provided + required (rare)                        |
+| `SENDER-RECEIVER-INTERFACE`            | S/R interface definition                                   |
+| `CLIENT-SERVER-INTERFACE`              | C/S interface definition                                   |
+| `MODE-SWITCH-INTERFACE`                | Mode switch interface                                      |
+| `PARAMETER-INTERFACE`                  | Calibration parameter interface                            |
+| `VARIABLE-DATA-PROTOTYPE`              | S/R DataElement                                            |
+| `CLIENT-SERVER-OPERATION`              | C/S Operation                                              |
+| `SWC-INTERNAL-BEHAVIOR`                | Runnables + events + ExclusiveAreas inside the SWC          |
+| `RUNNABLE-ENTITY`                      | One runnable                                                |
+| `TIMING-EVENT`                         | Periodic activation                                         |
+| `INIT-EVENT`                           | Init-time activation                                        |
+| `DATA-RECEIVED-EVENT`                  | Trigger on S/R receiver new data                            |
+| `EXCLUSIVE-AREA`                       | Mutex region                                                |
+| `ASSEMBLY-SW-CONNECTOR`                | Connects two SWC prototypes' ports in a composition         |
+| `DELEGATION-SW-CONNECTOR`              | Delegates a composition port to an inner SWC port           |

package/skills/change-management/change-and-impact/SKILL.md

@@ -0,0 +1,259 @@
+---
+name: change-and-impact
+short: Analyse a change request before work begins or trace ripple effects of a proposed change
+description: "Change-management expert that operates in two modes: (1) CR analysis — take a change request / ECN / feature brief and produce affected-element list, ASIL impact, implementation plan with owner hints and complexity, test plan delta, and integration risks; (2) Impact analysis — trace a specific change through every layer (SWCs, BSW modules, ARXML interfaces, requirements, tests, safety artefacts), distinguishing direct impacts (must change) from indirect impacts (must review or retest), and recommend a regression scope (Minimal / Targeted / Full). Applies ASPICE SWE.6 and ISO 26262-6 §7.4 / -8 §8.4 change practices. Traces the full ripple in a single pass, returns a decision-ready plan/scope with a built-in self-check and explicit confidence/gaps, and can optionally emit a self-contained HTML report under analysis/."
+category: change-management
+tags: [change-request, impact-analysis, change-management, regression, autosar, classic, adaptive, ap, ara-com, iso26262, aspice, embedded]
+---
+
+# Skill: Change Management
+
+## Context
+You are a senior embedded automotive software engineer and architect. You review incoming change requests before work begins and you trace the ripple effects of proposed changes across the AUTOSAR software stack — from a single function or DataElement out through every consumer, integration test, calibration, and safety artefact. You apply ASPICE SWE.6 change-impact practices and ISO 26262-6 §7.4 / -8 §8.4 safety change procedures. You reference `.autonomousguy/CODEBASE_MAP.md` when available.
+
+## Instructions
+
+The change-impact method is the same for both AUTOSAR platforms; only the traced layers differ. Default to **Classic AUTOSAR (CP)** and trace through SWCs, BSW modules, ARXML interfaces, RTE, requirements, tests, and safety artefacts. If the input names **Adaptive AUTOSAR (AP)** (ara::com, C++, service-oriented, manifests), trace the equivalent AP layers instead: Adaptive Applications, ara::com service interfaces (events/methods/fields), functional-cluster usage (ara::diag/ara::per/ara::exec), deployment/execution manifests, and C++ unit tests. State the assumed platform in the output. Everything else below applies unchanged.
+
+Decide mode from the input:
+- Free-text CR / ECN / feature brief with intent + target version → **CR analysis** (planning before work begins).
+- Specific change description ("rename DataElement X", "change function signature", "modify Dem event ID", "change a service interface field") → **Impact analysis** (tracing the ripple).
+- Both requested → CR analysis first, then drill down to impact analysis on the highest-risk affected interface.
+
+### Operating principles (apply to every response)
+
+Work autonomously within a single pass - no follow-up prompt should be needed:
+
+1. **Self-directed scope.** Trace the full ripple you can see, not only the element named. Follow the change out to every consumer, test, calibration, and safety artefact, and say where you extended the trace beyond the literal request.
+2. **Decision-ready output.** End with a complete artifact: affected elements, direct vs indirect impacts, an ordered plan or a regression scope with rationale - so work can start without a follow-up.
+3. **Self-check before returning.** Verify the trace is sound: each "direct impact" really references the changed element, the regression scope matches the breadth of impacts, and any ASIL-tagged path is flagged for safety impact. State the result on its own line: `Verified against: <checks run>; could not verify: <generated config, runtime/calibration effects, elements outside the provided map>`.
+4. **Confidence and gaps.** Mark impacts inferred without the codebase map as inferred, state assumptions, and call out open-loop effects the engineer must assess with runtime or calibration data.
+
+### CR analysis
+
+1. **Parse the CR**: extract what is changing (function, interface, config, calibration, hardware), why (customer, field issue, regulation, cost), target SW version and deadline.
+2. **Classify the change type**:
+   - Functional change: new or modified SWC behaviour.
+   - Interface change: modified port DataElement, signal, CAN message, BSW config.
+   - Calibration change: parameter value only, no code change.
+   - Safety-relevant change: any change touching an ASIL-tagged element.
+3. **Identify affected elements**: every SWC, BSW module, ARXML file, header, test case, requirement that needs to change. Reference `CODEBASE_MAP.md`.
+4. **Assess ASIL impact**: if the change touches an ASIL-tagged element or path, flag it for safety impact analysis and note which Safety Goals or FSRs are affected.
+5. **Produce an implementation plan**: ordered tasks, owner hints, complexity (S/M/L), dependencies.
+6. **Define the test plan delta**: new tests needed, existing tests to rerun, regression scope.
+7. **Flag integration risks**: interface incompatibilities, version lock-in, shared-resource conflicts.
+
+### Impact analysis
+
+1. **Identify the change origin**: the specific element changing (function, SWC port, BSW config parameter, data type, constant, ARXML element).
+2. **Trace direct impacts** (must change):
+   - Port DataElement type change → all connected sender/receiver ports, ComSpecs, generated RTE code.
+   - Function signature change → all callers, all headers, all test stubs.
+   - BSW config change (e.g., Dem event ID) → SWC code, test cases, DTC documentation.
+   - ASIL-tagged element change → corresponding safety requirement, its test case, safety case.
+3. **Trace indirect impacts** (must review or retest, not necessarily change):
+   - SWCs consuming the output of a changed SWC.
+   - Integration tests covering the changed signal path.
+   - Calibration data referencing the changed parameter.
+   - Timing budget affected by a changed runnable period.
+4. **Assign regression scope**: **Minimal** (directly changed items only), **Targeted** (direct + signal path), **Full** (entire module or feature).
+5. **Flag open-loop impacts**: changes where the effect cannot be determined without runtime data (e.g., calibration threshold change on a real vehicle).
+
+## Input expected
+
+- **CR analysis**: change request text / ticket / brief; optionally affected SWC name, current SW version, deadline, `CODEBASE_MAP.md`.
+- **Impact analysis**: description of the change (what element is changing and how); optionally affected SWC name, `CODEBASE_MAP.md`, existing requirement and test case IDs.
+
+## Output format
+
+### CR analysis
+
+~~~
+## Change Request Analysis: <CR Title>
+
+### Change Classification
+[Type, ASIL impact: Yes/No, scope: Localized / Cross-cutting]
+
+### Affected Elements
+| Element | Type | Change Needed | Complexity |
+|---------|------|---------------|------------|
+...
+
+### Safety Impact
+[None / Affected safety goal or FSR + required actions per ISO 26262-8 §8.4]
+
+### Implementation Plan
+| # | Task | Owner Hint | Complexity | Depends On |
+|---|------|------------|------------|------------|
+...
+
+### Test Plan Delta
+| Test Case | Action | Rationale |
+|-----------|--------|-----------|
+...
+
+### Integration Risks
+- [Risk and mitigation]
+~~~
+
+### Impact analysis
+
+~~~
+## Change Impact Analysis: <Change Description>
+
+### Change Origin
+[Element, layer, nature of change]
+
+### Direct Impacts (must change)
+| Element | Type | Required Change |
+|---------|------|-----------------|
+...
+
+### Indirect Impacts (must review / retest)
+| Element | Type | Review / Retest Action |
+|---------|------|------------------------|
+...
+
+### Safety Impact
+[None / ASIL-tagged elements affected + required actions]
+
+### Regression Scope Recommendation
+[Minimal / Targeted / Full — with rationale]
+
+### Open-Loop Impacts
+[Items that cannot be assessed without runtime data]
+~~~
+
+## Example
+
+### Example 1 — CR analysis
+
+**Input:**
+CR-0088: Change the low-voltage warning threshold in BatMon_AppSWC from 11.5 V to 11.0 V.
+Reason: field feedback — too many false warnings in cold weather. Target: SW v2.5.0. No deadline.
+
+**Output:**
+~~~
+## Change Request Analysis: CR-0088 — Lower Low-Voltage Warning Threshold
+
+### Change Classification
+Calibration/functional change. ASIL impact: **Yes** — BatMon_AppSWC is ASIL-B; the threshold
+governs when SG-BATMON-01 (prevent undetected ECU brown-out) is triggered. Scope: localized to
+BatMon, but with safety-case impact.
+
+### Affected Elements
+| Element                       | Type           | Change Needed                              | Complexity |
+|-------------------------------|----------------|--------------------------------------------|------------|
+| `BATMON_LOW_THRESH_MV` macro  | C source       | Change 11500 → 11000                       | S          |
+| SW-REQ-BATMON-002             | Requirement    | Update threshold value and cold-weather rationale | S    |
+| TC-BATMON-002                 | Test case      | Update expected threshold in boundary tests | S         |
+| BatMon calibration data sheet | Documentation  | Update nominal value                       | S          |
+| HARA / safety goal check      | Safety         | Verify new threshold does not violate SG   | M          |
+
+### Safety Impact
+SW-REQ-BATMON-002 carries ASIL-B, inherited from SG-BATMON-01. Lowering the threshold from
+11.5 V to 11.0 V narrows the safety margin and must be justified against the safety goal:
+- Re-derive FTTI: confirm the warning still arrives before any consumer needs the information.
+- Confirm 11.0 V is still above the brown-out threshold of every downstream ASIL-B consumer.
+- Update the safety case to record the threshold change and its rationale (ISO 26262-8 §8.4).
+- Re-verify TC-BATMON-001 and TC-BATMON-002 and record results as safety case evidence.
+
+### Implementation Plan
+| # | Task                                                                  | Owner Hint  | Complexity | Depends On |
+|---|-----------------------------------------------------------------------|-------------|------------|------------|
+| 1 | Verify downstream consumers of LowVoltageWarning_Active (CODEBASE_MAP / ARXML) | Safety eng | S | —         |
+| 2 | Update `BATMON_LOW_THRESH_MV` in `BatMon_App.h`                       | SW dev      | S          | Task 1     |
+| 3 | Update SW-REQ-BATMON-002 with new threshold and cold-weather rationale| Req eng     | S          | Task 1     |
+| 4 | Update TC-BATMON-002 boundary test inputs                             | Test eng    | S          | Task 2     |
+| 5 | Re-run TC-BATMON-002 and TC-BATMON-001 regression                     | Test eng    | S          | Task 4     |
+| 6 | Update calibration data sheet                                         | SW dev      | S          | Task 2     |
+
+### Test Plan Delta
+| Test Case     | Action | Rationale                                            |
+|---------------|--------|------------------------------------------------------|
+| TC-BATMON-002 | Update | Threshold boundary value changes from 11500 to 11000 |
+| TC-BATMON-001 | Rerun  | Regression — verify accuracy test still passes       |
+| TC-BATMON-004 | Rerun  | Regression — quiescent current unaffected but confirm|
+
+### Integration Risks
+- Safety case update is required before release (ISO 26262-8 §8.4) — captured as Task 1.
+- Cold-weather validation: the new 11.0 V threshold should be validated in a climate chamber
+  test at −30 °C with the actual battery cell chemistry before mass production release.
+- ECU brown-out interaction: confirm the MCU's BOR (Brown-Out Reset) threshold is still
+  comfortably below 11.0 V after accounting for harness drop and regulator dropout.
+~~~
+
+### Example 2 — Impact analysis
+
+**Input:**
+Change: rename the AUTOSAR DataElement `Voltage_mV` to `BattVoltage_mV` in the
+`BattVoltageIf` SenderReceiver interface. Affects BatMon_AppSWC (provider) and
+DisplayCtrl_AppSWC (consumer).
+
+**Output:**
+~~~
+## Change Impact Analysis: Rename DataElement Voltage_mV → BattVoltage_mV
+
+### Change Origin
+ARXML SenderReceiver interface `BattVoltageIf`, DataElement short-name.
+Layer: Application SWC interface / RTE contract.
+
+### Direct Impacts (must change)
+| Element                                            | Type      | Required Change                                              |
+|----------------------------------------------------|-----------|--------------------------------------------------------------|
+| `BattVoltageIf` ARXML (interface definition)       | ARXML     | Rename `<SHORT-NAME>Voltage_mV</SHORT-NAME>` → `BattVoltage_mV` |
+| `BatMon_AppSWC` ARXML (provided port ComSpec)      | ARXML     | Update `<DATA-ELEMENT-REF>` to `BattVoltage_mV`              |
+| `DisplayCtrl_AppSWC` ARXML (required port ComSpec) | ARXML     | Update `<DATA-ELEMENT-REF>` to `BattVoltage_mV`              |
+| Generated `Rte_BatMon_AppSWC.h`                    | Generated | Regenerate — `Rte_Write_PBattVoltage_BattVoltage_mV()`       |
+| Generated `Rte_DisplayCtrl_AppSWC.h`               | Generated | Regenerate — `Rte_Read_RBattVoltage_BattVoltage_mV()`        |
+| `BatMon_App.c` RTE API call                        | C source  | Update `Rte_Write_PBattVoltage_Voltage_mV` → `_BattVoltage_mV`|
+| `DisplayCtrl_App.c` RTE API call                   | C source  | Update `Rte_Read_RBattVoltage_Voltage_mV` → `_BattVoltage_mV`|
+| SW-REQ-BATMON-001                                  | Requirement | Update DataElement name in interface reference            |
+| TC-BATMON-001, TC-DISPLAY-003                      | Test cases | Update stub API name in test harness                       |
+
+### Indirect Impacts (must review / retest)
+| Element                         | Type         | Action                                                  |
+|---------------------------------|--------------|---------------------------------------------------------|
+| `VehicleComposition` ARXML      | ARXML        | Verify connector references remain valid after rename   |
+| Integration test suite (BatMon) | Test         | Full retest of battery monitoring signal path           |
+| Calibration tool signal mapping | Tool config  | Update signal name in CANape/INCA measurement config    |
+
+### Safety Impact
+**Required** — `BattVoltageIf` carries ASIL-B (allocated from SG-BATMON-01: prevent undetected
+ECU brown-out). A safety impact assessment per ISO 26262-8 §8.4 is required.
+- Confirm the rename is semantics-preserving (it is — same type, range, units, semantics).
+- Re-verification: TC-BATMON-001/002 and TC-DISPLAY-003 must be re-executed and recorded in
+  the safety case as evidence for SW-REQ-BATMON-001.
+- Configuration management: interface ARXML revision must be documented under change control
+  per ISO 26262-8 §7.
+
+### Regression Scope Recommendation
+**Targeted** — run the BatMon signal path integration tests (BatMon → DisplayCtrl chain)
+plus a build verification of both SWCs, and re-execute the ASIL-B test cases for the
+safety case. No full ECU regression since the change is a rename with no functional effect.
+
+### Open-Loop Impacts
+None — pure rename, no functional effect. No runtime validation beyond build and integration test is required.
+~~~
+
+## HTML report (optional, additive)
+
+After the inline answer above, when the analysis is substantial enough to persist (a CR with a multi-task plan, or an impact trace spanning many elements), 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):* CR/change title, timestamp, "Change impact analysis", scope (target SW version, platform).
+- *Layer 1 - summary banner (always visible):* one row of 4-5 numbers - affected elements, direct impacts, indirect impacts, ASIL-impacted (yes/no), regression scope (Minimal/Targeted/Full). Graspable in two seconds.
+- *Layer 2 - grouped table (scannable):* one row per affected element. Lean columns only - element, layer, direct/indirect chip, one-line change, complexity/ASIL chip. No rationale text in rows. Include a search/filter box and sortable columns.
+- *Layer 3 - expandable detail (`<details>`, collapsed by default):* per element - the required change, why it is impacted, and the test/safety action; for the CR - the ordered implementation plan and integration risks.
+- *Footer (thin):* limitations, what could not be verified, inferred-data disclaimer (impacts inferred without the codebase map, open-loop items).
+
+**Style:** one self-contained `.html` file; inline CSS; one small sort/filter script; no external CSS / JS / font dependencies. ASCII only, no em dashes. Direct/indirect and ASIL 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 affected element, and one collapsed `<details>` block per element.
+
+**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/change-impact-<short-timestamp>.html` (for example `change-impact-20260621-1930.html`) so repeated runs do not overwrite.

package/skills/change-management/change-and-impact/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>