AGENTS.md: dokumentiert den Update-Vorfall - Selbst-Update hat unveroeffentlichte Sitzungsarbeit ueberschrieben

Der Nutzer fuehrte ein Selbst-Update aus, das Gitea's letzten committeten Stand
(80d73e8) zog - alle Fixes dieser Sitzung waren bis dahin nur per docker cp an
audi_ha_test ausgeliefert, nie committet. Manifest fiel auf 2026.8.27.8 zurueck,
alle Symptome (Batteriespannung "unbekannt", Diagramm-Maximalwert 13,99V) passten
exakt zum Vor-Sitzungs-Stand. Container wiederhergestellt, jetzt committet -
Lehre fuer kuenftige Sitzungen im Dokument festgehalten.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

AGENTS.md

@@ -3717,6 +3717,59 @@ Verified: `py_compile` clean on `ablage.py`, `audi_ha_test` restarted clean on `
 above via direct file inspection, not just a trusted service-call return. No companion-app source changed
 (backend-only), no OTA rebuild needed.
 
+**Follow-ups (2026.8.27.16-.17), same session:** two corrections from the owner after `.15`, both applied
+to the same three "which voltage counts as what" spots (`audi-dashboard-app.js`, companion-app's
+`Batterie.tsx`): (1) `AGM_RUHE_MAX_V` (classification: "is this a battery reading or already the
+generator") raised from 12.8 → 13.0 V, owner-set directly ("max voltage for AGM Battery is 13V"). This
+also meant the diagram's dot set had to go back to filtering by this threshold - a mid-session detour
+(section U's later rounds) had made the diagram plot *every* measurement including generator readings; the
+owner's "13,01 shall be generator und not part of the diagram" reinstated the filter, just at the new 13.0
+ceiling instead of the old 12.8 one. (2) The owner then separately clarified the SOC curve's own "100% /
+voll" anchor should **stay** at 12.8 V ("12,8v voll was already right") - so `AGM_RUHE_MAX_V` (13.0,
+classification) and `BV_SOC_TABELLE`'s last point (12.8, the SOC-100% anchor) are now two deliberately
+different numbers, not one; a reading between 12.8-13.0 V counts as a valid battery measurement (gets a
+dot, feeds the SOH trend) but still displays 100% SOC via the table's existing clamp-above-last-point
+behavior - no new code needed for that overlap, just careful separation of the two constants and their
+captions/comments. Also added, same round: "Mein Audi"/Zustand's Batteriespannung row now shows the
+**last plausible voltage** instead of "unbekannt" when the live reading is currently implausible (e.g.
+dongle offline reporting 0V) - a small RAM-only cache in `veroeffentlichung.py`
+(`_letzte_gueltige_spannung`), updated whenever a valid reading is observed, read as fallback otherwise.
+Deliberately not persisted (same reasoning as this project's other RAM-only runtime state) - a restart
+shows "unbekannt" again until the next real reading, rather than resurrecting a possibly very old value
+from disk.
+
+**A real reachability report that could not be reproduced.** Owner reported the Batteriespannung row in
+"Mein Audi"/Zustand isn't clickable specifically in wide/desktop layout ("cursor changes but click does
+nothing"). Investigated thoroughly and could not reproduce: `document.elementFromPoint()` hit-testing at
+the row's exact screen position at 1400px width correctly resolved to the row itself (not an overlapping
+element); a full pointerdown→pointerup→click sequence dispatched there navigated correctly; a genuine
+OS-level trusted click via the browser tool's `computer` action (not a scripted DOM event - this is the
+closest thing to a real click available for remote testing) also navigated correctly. No `pointer-events`
+rule in the desktop `@container` CSS block touches `.row`. Left open, pending the owner's exact window
+width and a browser-console check at the moment of the failed click - flagging here rather than guessing
+further blindly.
+
+**A significant process gap, found and fixed the hard way: the self-update mechanism (section J) silently
+undid this entire session's work.** The owner ran "check for update" / "install" via the Einstellungen
+tile, which is designed to work exactly as documented - it pulled the latest **committed** state from
+Gitea and replaced the live `custom_components/audi_dashboard/` folder with it. The problem: every fix in
+this session (going back through sections U-W and all of this section) had only ever been deployed to
+`audi_ha_test` via direct `docker cp`, never committed - so Gitea's `HEAD` was still sitting at `80d73e8`,
+several rounds behind. The self-update did precisely what it's built to do; the gap was entirely on this
+session's side for not committing incrementally. Confirmed directly: `audi_ha_test`'s live manifest read
+back `2026.8.27.8` immediately after the owner's update, not `.17` - and every symptom the owner reported
+(Batteriespannung showing "unbekannt" again, the diagram's max reading back at 13,99 V, "Ruhespannung"
+back at a stale value) was exactly consistent with the pre-session code, not a new regression. Fixed in
+two steps: re-deployed the current local files to `audi_ha_test` via `docker cp` (restoring `.17`
+behavior for continued testing), then committed and pushed everything to Gitea (`172db54`) so the
+self-update path is no longer stale. **Lesson for future sessions, stated plainly: `docker cp` to
+`audi_ha_test` is a testing convenience, not a delivery mechanism - it is invisible to the self-updater and
+to `install.ps1` alike. Commit and push considerably more often than "when the owner explicitly says
+so," specifically before suggesting or allowing a self-update/install run, or a long session's worth of
+verified, deployed fixes can vanish in one click.** (`git push` needed one retry for the
+already-documented Gitea Credential Manager flakiness - consistent with every other push this project has
+made.)
+
 ---
 
 ## Working conventions (observed — keep them)