Unsicher? Starte mit Aufgabe 1 am eigenen Rechner. Willst du aufs echte Gerät, nimm Aufgabe 2. Beide sind read-only und verändern keinen Produktionscode.
Einfachster Startread-onlyLinux
1. Läuft das Linux-System gesund? (am eigenen Rechner)
Das bringt's: In Minuten ein reproduzierbarer Erstbefund statt Stochern. Du weisst danach, wo du weitersuchst.
Wähle das, wenn: ein Gerät langsam, instabil, voll oder auffällig wirkt, oder du den Check am eigenen Rechner ausprobieren willst.
Nach 12 Minuten: health_check_report.md mit Ampelstatus, Rohdaten und nächstem sicheren Check.
Prüfen: test -s health_check_report.md && sed -n '1,160p' health_check_report.md
Was bringt mir das?
Du bekommst in Minuten einen reproduzierbaren Erstbefund statt einer unsystematischen Suche. Der Report löst das Problem noch nicht, zeigt aber, ob du bei CPU, RAM, Datenträger, Prozess, Logs oder Netzwerk weitersuchen solltest. Auf einem Zielgerät nur in einer bereits autorisierten Sitzung und weiterhin read-only ausführen.
Aufs echte Gerätread-onlyi.MX6
2. Denselben Befund direkt vom i.MX6 holen
Das bringt's: Ein Ampel-Befund vom echten Gerät, ohne dich durch 200 Zeilen dmesg zu wühlen. Und ohne dass Gerätedaten in die Cloud gehen.
Wähle das, wenn: ein verbautes i.MX6-Gerät klemmt und du wissen willst, was es selbst über sich sagt: SD-Karte, Speicher, Kernel, Dienste.
So läuft es: ein kleines read-only Skript sammelt am Gerät, du ziehst die Textdatei auf den Laptop, Gemma fasst sie zusammen. Die KI berührt das Gerät nie.
Nach 12 Minuten: device_report.md mit Ampelstatus, zitierten Zeilen und einem nächsten sicheren Check.
Prüfen: Nimm einen 🔴 oder 🟡 Punkt aus dem Report und finde die zitierte Zeile in health_*.txt wieder.
Warum das Skript sammelt und die KI nur zusammenfasst
Auf einem i.MX6 mit knappem RAM und SD-Karte willst du kein Modell laufen lassen. Das Skript ist winzig, überall gleich und nur lesend. Die KI bleibt auf dem Laptop und sieht nur einen Textausschnitt. So bleibt das Gerät unberührt, vertrauliche Daten im Haus, und derselbe Ablauf skaliert auf viele Geräte.
read-onlyLogsHypothesen
3. Was ist in diesem Log-Zeitraum passiert?
Das bringt's: Aus einem Log-Ausschnitt der nächste prüfbare Diagnoseschritt. Geraten wird nicht.
Wähle das, wenn: du einen Absturz, Ladeabbruch, Timeout, Config-Reset oder Reboot anhand eines Log-Ausschnitts verstehen willst.
Nach 12 Minuten: eine kurze Timeline und höchstens drei prüfbare Ursachenhypothesen.
Prüfen: Suche zwei zitierte Zeitstempel in der Originaldatei und kontrolliere, ob die Reihenfolge stimmt.
Warum nicht einfach das ganze Log an ein stärkeres Modell senden?
Für grosse Archive ist ein stärkeres Modell oft besser. Der lokale E4B-Versuch ist sinnvoll, wenn Logs vertraulich sind, keine Cloud verfügbar ist oder du bereits einen engen Zeitraum und ein konkretes Symptom hast. Der Nutzen ist nicht „die Ursache erraten“, sondern aus Logs den nächsten überprüfbaren Diagnoseschritt abzuleiten.
nur TestdateiTDDLegacy Python
4. Einen Legacy-Fehler als Test reproduzieren
Das bringt's: Ein vages Problem wird reproduzierbar rot. Und bleibt es, wenn der Fix kommt.
Wähle das, wenn: ein bekanntes Fehlverhalten existiert, aber noch kein automatischer Test zeigt, wann es auftritt.
Nach 12 Minuten: ein fokussierter Test, der den Fehler reproduzierbar rot zeigt, oder bestehendes Verhalten dokumentiert.
Prüfen: Der Test schlägt aus dem erwarteten Grund fehl, nicht wegen Import, Setup oder Syntax.
Was bringt mir ein absichtlich roter Test?
Er macht ein vages Problem reproduzierbar und schützt später vor Rückfällen. Erst wenn du den Fehler zuverlässig rot gesehen hast, weisst du, dass ein grüner Test nach dem Fix wirklich etwas belegt. Genau diese Reihenfolge unterstützt der TDD-Skill.
nur TestdateiSafety-RegelRegression
5. Eine wichtige Geräteregel automatisch prüfen
Das bringt's: Eine Regel aus dem Kopf wird zum Wächter, den jeder Build erneut prüft.
Wähle das, wenn: eine Regel bei jeder Änderung gelten muss, heute aber nur im Kopf, Ticket oder Review existiert.
- ohne Autorisierung kein Start der Ladung
- ein Retry erzeugt keine zweite Session
- ungültige Config überschreibt keine gültige Config
- ein Grenzwert bleibt innerhalb des Hardwarebereichs
Nach 12 Minuten: ein kleiner Tabellen-Test mit mehreren Grenzfällen und einem klaren Ergebnis.
Prüfen: Kannst du die Regel verletzen, wenn du einen der vier Testfälle gezielt veränderst?
Was ist der konkrete Nutzen?
Die Regel wird vom Wissen im Kopf zu einem automatischen Wächter. Jeder spätere Build kann sie erneut prüfen. Das ist besonders wertvoll für Ladefreigabe, Zustandsautomaten, Retries, Config-Migrationen und Hardwaregrenzen. Der Test deckt nur die gewählten Fälle ab; er ist noch kein mathematischer Beweis. Er ist aber der verständliche erste Schritt in Richtung Property Testing und formaler Verifikation.