Rename library from AutoWire to K-Line

Library dir: lib/AutoWire/ -> lib/KLine/
Site title, docs, CLAUDE.md, platformio.ini all updated.
All 4 firmware environments build clean.

CLAUDE.md

@@ -1,4 +1,4 @@
-# AutoWire — Multi-Protocol Automotive Bus Interface (ESP32)
+# K-Line — Multi-Protocol Automotive Bus Interface (ESP32)
 
 ## Attribution
 
@@ -315,7 +315,7 @@ PlatformIO project in `firmware/` — builds for ESP32, ESP32-C3, ESP32-S3, and
 firmware/
 ├── platformio.ini              # 4 environments (BMW sniffer x3, OBD-II scanner)
 ├── include/config.h            # Pin defaults + protocol constants (IBUS_* and KLINE_*)
-├── lib/AutoWire/
+├── lib/KLine/
 │   ├── library.json            # PlatformIO lib metadata (v2026.02.13)
 │   ├── KLineTransport.h / .cpp # Hardware transport (UART, ISR, ring buffers, idle detect)
 │   ├── IbusHandler.h / .cpp    # BMW I/K-Bus FSM (FIND_SOURCE -> checksum validation)
@@ -408,7 +408,7 @@ pio device monitor         # serial monitor at 115200
 5. **SPICE simulation validated** — both RX and TX paths simulated with LTspice PC817 model at 9600 baud. RX path gives clean 0-3.13V logic at 3.3V VCC. TX path confirms signal inversion and 0.27V bus LOW on 1kΩ bus. Rise/fall times within 9600 baud budget.
 6. **R2 optimized for 3.3V** — parameter sweeps across R2, bus impedance, and CTR grade identified R2=220Ω (down from 470Ω) as the fix for 3.3V ESP32. Doubles LED drive current to 9.71mA, supports bus pull-ups down to ~530Ω.
 7. **IbusSerial ported to ESP32** — PlatformIO project with IbusEsp32 library. Bus sniffer sketch included. Builds for ESP32, ESP32-C3, ESP32-S3. Code reviewed for ISR safety, race conditions, buffer overflows.
-8. **Multi-protocol refactor (AutoWire)** — split monolithic IbusEsp32 into KLineTransport (hardware) + IbusHandler (BMW FSM). Library renamed from IbusEsp32 to AutoWire. IbusEsp32 preserved as backward-compatible facade. Zero changes to existing BMW sniffer sketch.
+8. **Multi-protocol refactor (K-Line)** — split monolithic IbusEsp32 into KLineTransport (hardware) + IbusHandler (BMW FSM). Library renamed from IbusEsp32 to KLine. IbusEsp32 preserved as backward-compatible facade. Zero changes to existing BMW sniffer sketch.
 9. **OBD-II K-line support** — KLineObd2 handler with ISO 9141 5-baud slow init, ISO 14230 fast init (TiniPulse), request/response with half-duplex echo clearing. Obd2Pids.h with ~20 common PID decode helpers (SAE J1979). Scanner example sketch polls RPM, speed, coolant temp, throttle, voltage.
 10. **OBD-II code review + hardening** — Apollo code review identified 4 critical and 7 important issues. All fixed: proper UART pin detach (`pinMatrixOutDetach`), timeout underflow guards, checksum validation, echo verification, RX buffer flush after init, structural ISO 14230 frame parsing, negative response handling, TesterPresent keepalive, and session re-initialization.
 

docs/architecture.md

@@ -1,4 +1,4 @@
-# AutoWire Library Architecture
+# K-Line Library Architecture
 
 Multi-protocol automotive bus library for ESP32. Handles BMW I/K-Bus and OBD-II K-line (ISO 9141 / ISO 14230) over a shared single-wire bus interface with PC817 optocoupler isolation.
 
@@ -63,7 +63,7 @@ IbusHandler and KLineObd2 sit as parallel protocol handlers on top of a shared K
 ## File Inventory
 
 ```
-firmware/lib/AutoWire/
+firmware/lib/KLine/
   library.json          PlatformIO metadata (v2026.02.13)
   KLineTransport.h/cpp  Shared hardware layer
   IbusHandler.h/cpp     BMW I/K-Bus protocol

docs/development-journal.md

@@ -255,10 +255,10 @@ This was the big build session. Three phases, done sequentially because each dep
 
 The rule here was: extract KLineTransport and IbusHandler from the existing IbusEsp32 code, rewire everything, and verify that all three ESP32 environments still build with zero changes to `main.cpp`. If the sniffer sketch works identically before and after, the refactor is clean.
 
-Created `lib/AutoWire/` with the new file structure:
+Created `lib/KLine/` with the new file structure:
 
 ```
-lib/AutoWire/
+lib/KLine/
   KLineTransport.h / .cpp    <-- extracted from IbusEsp32
   IbusHandler.h / .cpp        <-- extracted from IbusEsp32
   IbusEsp32.h / .cpp           <-- now just a facade
@@ -338,7 +338,7 @@ All four environments (3 BMW sniffer + 1 OBD-II scanner) built clean.
 
 ### Phase 3: Documentation
 
-Updated `library.json` metadata with the new library name (AutoWire) and file list. Updated CLAUDE.md with the architecture diagram, new file structure, OBD-II section, and the build instructions for the fourth environment. Not glamorous work but someone has to do it.
+Updated `library.json` metadata with the new library name (K-Line) and file list. Updated CLAUDE.md with the architecture diagram, new file structure, OBD-II section, and the build instructions for the fourth environment. Not glamorous work but someone has to do it.
 
 ---
 
@@ -448,10 +448,10 @@ Looking back across all four sessions, a few things stand out:
 As of the last commit, the project has:
 
 - Two validated SPICE netlists (RX and TX paths) plus four parameter sweep netlists
-- A multi-protocol PlatformIO library (AutoWire) that builds for ESP32, ESP32-C3, and ESP32-S3
+- A multi-protocol PlatformIO library (K-Line) that builds for ESP32, ESP32-C3, and ESP32-S3
 - BMW I/K-Bus sniffer sketch (tested in simulation, not yet on hardware)
 - OBD-II K-line scanner sketch (code-reviewed, not yet on hardware)
-- 13 source files in the AutoWire library
+- 13 source files in the K-Line library
 - 4 PlatformIO build environments, all clean
 
 What hasn't been done yet: breadboard prototype, loopback testing, bench testing with a 12V supply, and actual vehicle testing. That's the next chapter.

firmware/lib/KLine/library.json

@@ -1,5 +1,5 @@
 {
-    "name": "AutoWire",
+    "name": "KLine",
     "version": "2026.02.13",
     "description": "Multi-protocol automotive bus library for ESP32 — BMW I/K-Bus + OBD-II K-line",
     "keywords": ["bmw", "ibus", "kbus", "obd2", "kline", "iso9141", "iso14230", "optocoupler", "pc817", "esp32", "e46", "ford"],

firmware/platformio.ini

@@ -1,4 +1,4 @@
-; AutoWire — Multi-protocol automotive bus interface (ESP32)
+; K-Line — Multi-protocol automotive bus interface (ESP32)
 ; BMW I/K-Bus (optocoupler) + OBD-II K-line (transistor/optocoupler)
 ; Based on muki01/I-K_Bus (MIT), ported for ESP32 with R2=220 fix
 

site/Makefile

@@ -1,7 +1,7 @@
 .PHONY: help build up down logs restart dev prod clean rebuild
 
 help:
-	@echo "AutoWire K-line Docs"
+	@echo "K-Line Docs"
 	@echo ""
 	@echo "Usage:"
 	@echo "  make build    - Build Docker images"

site/astro.config.mjs

@@ -7,7 +7,7 @@ export default defineConfig({
   devToolbar: { enabled: false },
   integrations: [
     starlight({
-      title: 'AutoWire',
+      title: 'K-Line',
       description: 'BMW I/K-Bus + OBD-II K-line interface for ESP32 with PC817 optocoupler isolation',
       social: [
         { icon: 'codeberg', label: 'Source', href: 'https://git.supported.systems/warehack.ing/i-k-bus-board' },

site/package.json

@@ -1,7 +1,7 @@
 {
   "name": "k-line-docs",
   "version": "1.0.0",
-  "description": "AutoWire: BMW I/K-Bus + OBD-II K-line interface documentation",
+  "description": "K-Line: BMW I/K-Bus + OBD-II K-line interface documentation",
   "type": "module",
   "scripts": {
     "dev": "astro dev",

site/src/content/docs/guides/development-journal.mdx

@@ -258,10 +258,10 @@ This was the big build session. Three phases, done sequentially because each dep
 
 The rule here was: extract KLineTransport and IbusHandler from the existing IbusEsp32 code, rewire everything, and verify that all three ESP32 environments still build with zero changes to `main.cpp`. If the sniffer sketch works identically before and after, the refactor is clean.
 
-Created `lib/AutoWire/` with the new file structure:
+Created `lib/KLine/` with the new file structure:
 
 ```
-lib/AutoWire/
+lib/KLine/
   KLineTransport.h / .cpp    <-- extracted from IbusEsp32
   IbusHandler.h / .cpp        <-- extracted from IbusEsp32
   IbusEsp32.h / .cpp           <-- now just a facade
@@ -341,7 +341,7 @@ All four environments (3 BMW sniffer + 1 OBD-II scanner) built clean.
 
 ### Phase 3: Documentation
 
-Updated `library.json` metadata with the new library name (AutoWire) and file list. Updated CLAUDE.md with the architecture diagram, new file structure, OBD-II section, and the build instructions for the fourth environment. Not glamorous work but someone has to do it.
+Updated `library.json` metadata with the new library name (K-Line) and file list. Updated CLAUDE.md with the architecture diagram, new file structure, OBD-II section, and the build instructions for the fourth environment. Not glamorous work but someone has to do it.
 
 ---
 
@@ -451,10 +451,10 @@ Looking back across all four sessions, a few things stand out:
 As of the last commit, the project has:
 
 - Two validated SPICE netlists (RX and TX paths) plus four parameter sweep netlists
-- A multi-protocol PlatformIO library (AutoWire) that builds for ESP32, ESP32-C3, and ESP32-S3
+- A multi-protocol PlatformIO library (K-Line) that builds for ESP32, ESP32-C3, and ESP32-S3
 - BMW I/K-Bus sniffer sketch (tested in simulation, not yet on hardware)
 - OBD-II K-line scanner sketch (code-reviewed, not yet on hardware)
-- 13 source files in the AutoWire library
+- 13 source files in the K-Line library
 - 4 PlatformIO build environments, all clean
 
 What hasn't been done yet: breadboard prototype, loopback testing, bench testing with a 12V supply, and actual vehicle testing. That's the next chapter.

site/src/content/docs/guides/getting-started.mdx

@@ -1,9 +1,9 @@
 ---
 title: Getting Started
-description: "Building the AutoWire firmware with PlatformIO"
+description: "Building the K-Line firmware with PlatformIO"
 ---
 
-AutoWire is a multi-protocol automotive bus library for ESP32. It supports BMW I/K-Bus (9600 baud, 8E1, optocoupler isolated) and OBD-II K-line (10400 baud, 8N1, ISO 9141/14230). The firmware ships with two sketches: a BMW bus sniffer and an OBD-II scanner.
+K-Line is a multi-protocol automotive bus library for ESP32. It supports BMW I/K-Bus (9600 baud, 8E1, optocoupler isolated) and OBD-II K-line (10400 baud, 8N1, ISO 9141/14230). The firmware ships with two sketches: a BMW bus sniffer and an OBD-II scanner.
 
 ## Prerequisites
 
@@ -112,7 +112,7 @@ Set `KLINE_TX_INVERT=1` for PC817 optocoupler circuits, `0` for direct transisto
 firmware/
 ├── platformio.ini              # 4 environments (BMW sniffer x3, OBD-II scanner)
 ├── include/config.h            # Pin defaults + protocol constants
-├── lib/AutoWire/
+├── lib/KLine/
 │   ├── library.json            # PlatformIO lib metadata
 │   ├── KLineTransport.h/.cpp   # Shared hardware layer (UART, ISR, ring buffers)
 │   ├── IbusHandler.h/.cpp      # BMW I/K-Bus protocol FSM

site/src/content/docs/index.mdx

@@ -1,5 +1,5 @@
 ---
-title: AutoWire
+title: K-Line
 description: BMW I/K-Bus + OBD-II K-line interface for ESP32 with PC817 optocoupler isolation
 template: splash
 hero:
@@ -24,11 +24,11 @@ import { Card, CardGrid } from '@astrojs/starlight/components';
 
 An ESP32-based interface board for talking to BMW's proprietary body/instrumentation bus (I-Bus and K-Bus) and OBD-II K-line diagnostic ports. Uses PC817 optocouplers for galvanic isolation from the vehicle's 12V electrical system.
 
-The firmware library — **AutoWire** — handles both protocols through a shared transport layer, with separate protocol handlers for BMW's multi-master bus and OBD-II's master/slave diagnostic sessions.
+The firmware library — **K-Line** — handles both protocols through a shared transport layer, with separate protocol handlers for BMW's multi-master bus and OBD-II's master/slave diagnostic sessions.
 
 <CardGrid>
   <Card title="Two Protocols, One Board" icon="setting">
-    BMW I/K-Bus (9600 baud, 8E1, XOR checksum) and OBD-II K-line (10400 baud, 8N1, mod256 checksum) share the same physical layer but have completely different framing and initialization. AutoWire handles both.
+    BMW I/K-Bus (9600 baud, 8E1, XOR checksum) and OBD-II K-line (10400 baud, 8N1, mod256 checksum) share the same physical layer but have completely different framing and initialization. K-Line handles both.
   </Card>
   <Card title="SPICE Validated" icon="approve-check">
     Every circuit path simulated in LTspice before soldering. Three parameter sweeps identified the R2=220 ohm fix for 3.3V ESP32 compatibility. Six netlists document the full operating envelope.

site/src/content/docs/reference/architecture.mdx

@@ -1,6 +1,6 @@
 ---
 title: Firmware Architecture
-description: "AutoWire library composition pattern and concurrency model"
+description: "K-Line library composition pattern and concurrency model"
 ---
 
 Multi-protocol automotive bus library for ESP32. Handles BMW I/K-Bus and OBD-II K-line (ISO 9141 / ISO 14230) over a shared single-wire bus interface with PC817 optocoupler isolation.
@@ -66,7 +66,7 @@ IbusHandler and KLineObd2 sit as parallel protocol handlers on top of a shared K
 ## File Inventory
 
 ```
-firmware/lib/AutoWire/
+firmware/lib/KLine/
   library.json          PlatformIO metadata (v2026.02.13)
   KLineTransport.h/cpp  Shared hardware layer
   IbusHandler.h/cpp     BMW I/K-Bus protocol

site/src/content/docs/reference/obd2-protocol.mdx

@@ -5,7 +5,7 @@ description: "ISO 9141/14230 initialization, PID requests, and session managemen
 
 OBD-II over K-line (ISO 9141-2 and ISO 14230 / KWP2000) is a standard vehicle diagnostic protocol. Unlike BMW I/K-Bus which is multi-master and always-on, K-line is master/slave -- the tester (ESP32) initiates all communication, and the ECU only responds when asked.
 
-The AutoWire library implements K-line support through `KLineObd2`, which handles initialization, request/response framing, echo clearing, checksum validation, and session keepalive.
+The K-Line library implements K-line support through `KLineObd2`, which handles initialization, request/response framing, echo clearing, checksum validation, and session keepalive.
 
 ## Protocol Parameters
 
@@ -204,7 +204,7 @@ PID `0x00` returns a 4-byte bitmask indicating which PIDs `0x01` through `0x20`
 | Vehicle Info | `0x09` | VIN, calibration IDs, etc. |
 | Permanent DTCs | `0x0A` | Permanent DTCs (cannot be cleared) |
 
-The current AutoWire implementation handles Mode 01 (current data) PID requests. Modes 03 and 04 (DTC read/clear) are planned.
+The current K-Line implementation handles Mode 01 (current data) PID requests. Modes 03 and 04 (DTC read/clear) are planned.
 
 ## Session Management
 

site/src/content/docs/reference/vehicle-compatibility.mdx

@@ -5,7 +5,7 @@ description: "Which vehicles use BMW I/K-Bus and OBD-II K-line protocols, organi
 
 import { Aside, Tabs, TabItem } from '@astrojs/starlight/components';
 
-AutoWire supports two distinct protocols that share the same physical layer (single-wire K-line) but target completely different vehicle systems. This page documents which vehicles use which protocol — and when manufacturers transitioned away from K-line to CAN bus.
+K-Line supports two distinct protocols that share the same physical layer (single-wire K-line) but target completely different vehicle systems. This page documents which vehicles use which protocol — and when manufacturers transitioned away from K-line to CAN bus.
 
 ## BMW I-Bus and K-Bus
 
@@ -90,7 +90,7 @@ The following tables cover which manufacturers used K-line protocols and when th
 
 #### Ford (Europe)
 
-European Fords are completely different from US Fords — they use ISO 9141 / KWP2000 over K-line, not J1850 PWM. This is the primary target for AutoWire's OBD-II mode alongside the [Tucker k-line-board](https://git.supported.systems/warehack.ing/k-line-board) project.
+European Fords are completely different from US Fords — they use ISO 9141 / KWP2000 over K-line, not J1850 PWM. This is the primary target for K-Line's OBD-II mode alongside the [Tucker k-line-board](https://git.supported.systems/warehack.ing/k-line-board) project.
 
 | Model | Generation | Years | Protocol | Notes |
 |-------|-----------|-------|----------|-------|
@@ -271,7 +271,7 @@ Chrysler used ISO 9141-2 almost exclusively for OBD-II diagnostics before the 20
 
 #### Ford (US Market)
 
-US-market Fords used J1850 PWM — a different protocol that AutoWire does not support. Pin 2 on the OBD-II connector instead of pin 7.
+US-market Fords used J1850 PWM — a different protocol that K-Line does not support. Pin 2 on the OBD-II connector instead of pin 7.
 
 <Aside type="caution">
 **European Fords are different!** Ford Fiesta, Focus, Mondeo, Ka, Transit, and other European-market Fords use ISO 9141 / KWP2000 over K-line. See the **European** tab for model-level detail. US-market Fords used J1850 PWM instead.
@@ -313,9 +313,9 @@ The OBD-II connector pinout tells you which protocol(s) your vehicle supports. C
 | 15 | ISO 9141 / ISO 14230 (optional) | L-line |
 | 16 | Battery positive | +12V |
 
-**If pin 7 is populated and pins 6/14 are not**, the vehicle uses K-line exclusively — this is the target for AutoWire's OBD-II mode.
+**If pin 7 is populated and pins 6/14 are not**, the vehicle uses K-line exclusively — this is the target for K-Line's OBD-II mode.
 
-**If pin 7 AND pins 6/14 are populated**, the vehicle supports both K-line and CAN. The ECU may respond on either protocol, but CAN is generally preferred by modern scan tools. AutoWire can still use the K-line path.
+**If pin 7 AND pins 6/14 are populated**, the vehicle supports both K-line and CAN. The ECU may respond on either protocol, but CAN is generally preferred by modern scan tools. K-Line can still use the K-line path.
 
 **If only pins 6/14 are populated** (no pin 7), the vehicle is CAN-only and cannot be reached via K-line.
 
@@ -331,12 +331,12 @@ A multimeter or continuity tester on the OBD-II connector is the definitive way
 | OBD-II K-line | Optocoupler or transistor | Engine diagnostics (ISO 9141/14230) | Hundreds of models (1996–2008) |
 | OBD-II CAN | Not supported (different physical layer) | — | All vehicles 2008+ |
 
-The optocoupler circuit in this project was designed for BMW I/K-Bus but works for OBD-II K-line as well — both protocols use the same electrical signaling (open-drain/collector on a single wire, idle HIGH). The AutoWire firmware handles the protocol differences (baud rate, framing, checksum, initialization) in software.
+The optocoupler circuit in this project was designed for BMW I/K-Bus but works for OBD-II K-line as well — both protocols use the same electrical signaling (open-drain/collector on a single wire, idle HIGH). The K-Line firmware handles the protocol differences (baud rate, framing, checksum, initialization) in software.
 
 ## References
 
 - [muki01/OBD2_K-line_Reader](https://github.com/muki01/OBD2_K-line_Reader) — Arduino/ESP32 K-line reader supporting ISO 9141 and ISO 14230 with automatic protocol detection. Includes transistor, comparator (LM393), and dedicated IC (L9637D, MCZ33290, SN65HVDA195) schematics.
-- [muki01/I-K_Bus](https://github.com/muki01/I-K_Bus) — BMW I/K-Bus library that AutoWire's protocol handler is based on. Optocoupler schematic, E46 command codes, and bus documentation.
+- [muki01/I-K_Bus](https://github.com/muki01/I-K_Bus) — BMW I/K-Bus library that K-Line's protocol handler is based on. Optocoupler schematic, E46 command codes, and bus documentation.
 - SAE J1979 — OBD-II PID definitions and decode formulas (Mode 01 current data).
 - ISO 9141-2 — K-line 5-baud slow initialization protocol.
 - ISO 14230-4 (KWP2000) — K-line fast initialization and enhanced diagnostic services.

site/src/styles/custom.css

@@ -1,4 +1,4 @@
-/* AutoWire docs — clean automotive theme */
+/* K-Line docs — clean automotive theme */
 
 :root {
   --sl-color-accent-low: #1a2332;