Home Chat Übersicht Ideen Einstellungen

👋 Praktikums-Roadmap

Was in den nächsten Monaten ansteht — und woran wir am Ende jeder Phase merken, dass sie geschafft ist. Die Reihenfolge ist bewusst nach Risiko gebaut, nicht nach Wichtigkeit: zuerst lesen und aufräumen, dann Oberflächen, dann Daten, dann ein eigenes Projekt.

Praxissemester ~5–6 Monate 22 Wochen in 6 Phasen Schwerpunkt Automation & Software-Agenten
Jeden Tag eintragen: Anwesenheit und Tätigkeit gehören ins Praktikums-Tagebuch — daraus entstehen am Ende der Tätigkeitsnachweis und die Praxisberichte. Die Hochschule verlangt mindestens 95 Präsenztage; das lässt sich später nicht rekonstruieren.
0 von 25 erledigt0 %
Worum es hier geht

RUDI ist das selbstgebaute Betriebssystem der Regio Frucht: rund 30 Module, die den ganzen Weg der Ware abbilden — Bestellung beim Lieferanten, Wareneingang an der Rampe, Produktionsplanung, Schneideplan, Tour, Rechnung, Qualitätsnachweis. Dazu eine KI-Schicht: ein Chat, der Werkzeuge auf die echten Daten anwenden darf, und Wächter, die nachts und stündlich prüfen, ob etwas aus dem Ruder läuft.

Technisch: Node.js/Express im Hintergrund, statische HTML-Seiten im Vordergrund, SQLite als Datenhaltung, Nginx davor, angebunden an das ERP (Haufe X360) und Microsoft 365. Alles läuft auf einem einzigen Produktivserver — es gibt keine Testumgebung, die man kaputtmachen darf. Das erklärt die meisten Regeln weiter unten.

Die wichtigste Eigenschaft: Fast jedes Modul hängt an einem anderen. Wer den Bestand ändert, ändert den Bedarf; wer den Bedarf ändert, ändert den Bestellvorschlag. Deshalb gibt es die Schnittstellen-Landkarte mit einem Register aller Kopplungen — vor jeder Änderung, die zwei Module berührt, dort nachsehen.

Phase für Phase
0✓
👋
Ankommen
Woche 1

Ziel: Du verstehst, was der Betrieb macht, bevor du verstehst, was die Software macht. Das ist keine Höflichkeitsrunde — wer nie gesehen hat, wie ein Salat verarbeitet wird, baut an der Produktionsplanung vorbei.

Das machst du
1✓
🧹
Aufräumen und erste Änderungen
Woche 2–4

Ziel: Git, Testlauf und Review-Schleife müssen sitzen, bevor du etwas anfasst, das wehtun kann. Aufräumarbeit ist dafür ideal: du liest dabei quer durch die Codebasis, und das Risiko ist minimal.

Das machst du
2✓
🎨
Frontend
Woche 5–9

Ziel: Du kannst eine Seite im RUDI-Design bauen, die auf dem Handy genauso funktioniert wie am Rechner.

Aufsteigend nach Schwierigkeit
Zwei Fallen, in die hier schon jeder getreten ist: Jedes Modul-CSS muss den kompletten Grundlayer selbst mitbringen — sonst weiße Seite mit Serifenschrift. Und die Klasse .hidden verträgt sich nicht damit, display per JavaScript auf leer zu setzen; das Element bleibt dann unsichtbar.
3✓
⚙️
Backend und Daten
Woche 10–13

Ziel: Express-Routen, SQLite, Parser. Ab hier arbeitest du an Daten, die zählen — entsprechend mit Review vor dem Livegang.

Das machst du
4✓
🚀
Eigenprojekt
Woche 14–20

Ziel: Ein Feature komplett allein — Konzept, Plan, Bau, Härtung, Livegang, Doku. Das wird typischerweise auch dein Thema für den Praxisbericht.

Zwei Kandidaten, Entscheidung fällt in Woche 12
🤖 A — Informationsfluss-Agent

Ein Agent liest den Posteingang mit, erkennt Wartungshinweise zum Fuhrpark — Werkstatttermin, TÜV, Reifenangebot — und legt daraus selbstständig einen Wartungseintrag an. Trifft den Studienschwerpunkt direkt.

📄 B — Dokumentenablage für die eigenen Belege

Rund 1.500 Eingangsrechnungen, 1.500 Belegdateien, 9.700 Wareneingangs-Fotos und die Leergut-Scans liegen heute in vier getrennten Silos — gesucht werden kann jeweils nur im eigenen Modul. Eine gemeinsame Ablage mit Suche, dazu die automatische Erkennung von Belegart und Kennzahlen — Lieferant, Nummer, Datum — aus Text und Scan. Der Erkennungsteil ist Python und trifft deinen Studienschwerpunkt; die Bestände werden nur gelesen, damit kein Produktivdatenrisiko entsteht.

So entsteht hier jedes größere Feature
  1. Interview über die offenen Entscheidungen, bevor eine Zeile Code entsteht
  2. Schriftlicher Plan, abgenommen
  3. Bau in einem eigenen Git-Arbeitsbereich, nicht im Produktivpfad
  4. Härtungsrunde: ein eigener kritischer Durchgang gegen den eigenen Code
  5. Sicherheitsprüfung mit Checkliste
  6. Livegang mit Rückrollpunkt
  7. Doku — und die Landkarte ergänzen, wenn eine neue Kopplung entsteht
5✓
🎓
Abschluss und Übergabe
Woche 21–22
Das machst du
Die fünf Regeln, die wirklich zählen
  1. Erst lesen, dann ändern. Nie eine Datei anfassen, die du nicht vorher ganz gelesen hast. Nie raten, wie ein Endpunkt heißt — nachsehen.
  2. Du testest selbst, bevor du „fertig" sagst. Der Chef ist nicht dein Tester. Frontend: Layout-Test für Desktop und Mobil, Screenshots ansehen, jeden Knopf der geänderten Seite anklicken. Backend: Dienst neu starten und den echten Aufruf durch Nginx machen, nicht nur direkt.
  3. Committen nach jeder Änderung. Es gibt drei getrennte Git-Bereiche — Frontend, Backend, Skripte. Bei allem über drei Dateien vorher einen Ausgangs-Commit, damit es einen sauberen Rückrollpunkt gibt.
  4. Keine Kundennamen, Preise oder personenbezogenen Daten in Dateien, Notizen, Screenshots oder Chats, die den Server verlassen könnten. Keine Schlüssel oder Zugangsdaten irgendwo ausgeben.
  5. Einfach schlägt clever. Der minimale Code, der das Problem löst. Keine Abstraktion für einen einzigen Anwendungsfall, keine Fehlerbehandlung für unmögliche Fälle. Wenn dein erster Wurf 200 Zeilen hat und 50 gereicht hätten: neu schreiben.
Dazu eine Gewohnheit, die viel Ärger spart: Bei Unsicherheit fragen, bevor du baust. Widersprüchliche Anforderung, unklares Datenformat, zwei plausible Auslegungen — sag es. Das kostet zehn Minuten. Die falsche Annahme kostet drei Tage.
Dein Werkzeugkasten
WerkzeugWofür
layout-test.jsFrontend-Prüfung: Überlauf, abgeschnittener Text, Navigation, JS-Fehler, tote Links. Screenshots landen in ~/layout-tests/
rudi-test.jsAPI- und Funktionstests
rudi-health.jsGesundheitscheck des Gesamtsystems
security-quick-check.jsPflicht nach jedem neuen Modul und jeder neuen Route
Schnittstellen-LandkarteRegister aller Modul-Kopplungen — vor Arbeit über Modulgrenzen hinweg lesen
Frontend-RegelnDesign-System: Glasmorphismus, Farben, Kopfleiste, graue Kästen, Dunkelmodus
Coding-PrinzipienWie hier Code entsteht
Offene-Punkte-ListeDer Aufgabenvorrat, aus dem die Phasen gespeist werden
Rhythmus
WannWasDauer
Täglich morgensKurzer Abgleich: was heute, was hakt10 Min
FreitagsWoche durchgehen, nächste festlegen, Roadmap nachschärfen30 Min
Ende jeder PhaseAbnahme gegen das genannte Kriterium, Entscheidung über die nächste Phase1 Std
Bei Aufgaben über drei Dateien gilt auch für dich die Phasen-Abfrage: nach jedem Abschnitt kurz rückfragen, ob weitergemacht werden soll. Das verhindert, dass eine falsche Annahme drei Tage lang wächst.
Aufgabenpool

Konkrete Aufgaben, aus denen du dir welche nimmst. Jede Karte anklicken — dahinter stehen Ziel, Ausgangslage, Schritte, Testweg und die bekannten Fallstricke.

Mit Claude Code: Nenne einfach die Kennung im Chat, also A-01 oder „mach A-03". Claude Code liest die zugehörige Datei unter docs/aufgaben/ und kennt damit Ziel, betroffene Dateien und Testweg — du musst nichts abtippen.

Aufgaben werden geladen …

Lebendes Dokument — wird freitags nachgeschärft. Stand 31.07.2026.
Abgehakte Punkte werden lokal in diesem Browser gespeichert.