#2 (framework): bi-directional / service-function engine

Profile-defined UDS action sequences, run safely -- the framework for #2 (real
per-vehicle actuator tests/resets are follow-on, added as verified profile data).

- obdcore/actions.py: Action model + run_action() executing session (Mode 10) ->
  security (Mode 27 seed->key) -> command steps (2F/31/11/3E/... any hex) with
  positive/negative response checks. Security KEY algorithms are per-vehicle
  secrets and NOT bundled -- only trivial transforms (xor-ff/invert/add-ff)
  known; an action naming an unknown algorithm is BLOCKED (fails safe). Never
  synthesizes bytes -- runs only what the profile defines. validate_action()
  rejects malformed hex at load.
- profile.py: load/save an actions[] block; ElmLink/MockLink read_raw(hex).
- GUI: Diagnostics -> Service & Bi-directional dialog -- lists the profile's
  actions with risk badges; caution/danger gated behind a warning confirmation.
- generic-obd2: two safe STANDARD actions (Tester-Present ping; ECU-Reset,
  caution + engine-off warning). PROFILE_SPEC.md documents the actions schema
  + safety rules.
- tests/test_actions.py: runner, session+reset, security handshake, unknown-algo
  block, hex validation, profile load. All 5 suites pass.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016yT89n4zR4qbrySoSiEyZs

profiles/PROFILE_SPEC.md

@@ -137,6 +137,47 @@ vehicle reports trims/O2).
 flags drive-disabling faults (shown bold red). Include generic `P0xxx` plus
 manufacturer-specific `P1xxx` you can source.
 
+## 7b. `actions` — bi-directional / service functions (optional)
+
+Manufacturer service functions (actuator tests, service resets, module writes)
+are UDS (ISO 14229) sequences, so they live in the profile as **data**. OBDash
+runs ONLY the hex bytes you define — it never synthesizes commands.
+
+```jsonc
+"actions": [
+  {
+    "key": "ECU_RESET",
+    "name": "Reset ECU (soft reboot)",
+    "kind": "reset",                 // test | actuator | reset | write
+    "risk": "caution",              // safe | caution | danger  (caution/danger prompt to confirm)
+    "description": "shown in the list",
+    "warning": "shown in the confirmation for caution/danger actions",
+    "session": "03",                // OPTIONAL Mode 10 subfunction hex (enter extended session)
+    "security": {"level":"01","algorithm":"xor-ff"},  // OPTIONAL seed->key unlock
+    "steps": [ {"send":"1101", "expect":"51"} ],      // send hex; expect = hex the reply must contain
+    "success_msg": "ECU reset acknowledged."
+  }
+]
+```
+
+Execution order: `session` (Mode 10) → `security` (Mode 27 seed→key) → each
+`step` in order. A step succeeds if the reply contains `expect`, or (when
+`expect` is omitted) the UDS positive-response byte (`send` SID + 0x40). Any
+negative response (`7F …`) aborts.
+
+**Security access:** real per-vehicle seed→key algorithms are proprietary and are
+**not** bundled. Only trivial/standard transforms are known (`xor-ff`, `invert`,
+`add-ff`); an action naming any other `algorithm` is **blocked** (fails safe) —
+don't put a real secret algorithm name and expect it to work. Most simple
+functions need no security block.
+
+**Safety rules for authors:**
+- Only include commands with **verified** bytes (service manual / bench-confirmed).
+  A wrong `2F`/`31`/`2E` command can mis-actuate or misconfigure a module.
+- Mark anything that writes/actuates `caution` or `danger` and write a clear
+  `warning` (e.g. "engine off", "wheels chocked").
+- `kind:"write"` (module config / As-Built) is the highest-risk — reserve `danger`.
+
 ## 8. Rules for authors / agents
 
 - **Standard Mode-01 PIDs are the reliable backbone** — include the ones this