Versionierter Plan für den schrittweisen Aufbau der Knight's-Tour-App aus knight.md, als Lehrbeispiel für AI-gestützte Software-Entwicklung.
Der Autor möchte einen wiederholbaren professionellen Prozess demonstrieren — möglicherweise live oder online vor Mischpublikum — wie ein nicht-trivialer Software-Anwendungsfall mit AI-Unterstützung gelöst wird, wenn man bei null Code startet und nur seine Gedanken so gut wie möglich verschriftlicht hat (knight.md, 33 Zeilen). Die ursprüngliche, funktionierende Implementation (8 Dateien, ~890 Zeilen) wurde vor Beginn dieses Plans hart gelöscht; sie existiert nur noch im Git-Objektspeicher unter dem Tag pre-rebuild-2026-05-13. Während der gesamten Übung ist sie tabu — sie würde den Reinheitsanspruch und damit die didaktische Aussage zerstören.
Zielgruppe der Lehrunterlage: Mischpublikum — Programmierer mit AI-Einsteiger-Niveau bis hin zu AI-erfahrenen Praktikern, die methodisch besser werden wollen. Aufzeichnungsstil: verbatim während der Arbeit, didaktische Aufbereitung erst am Ende als separater Schritt.
Zwei Deliverables am Ende:
file:// ausführbar, alle Features aus knight.md).knight.md selbst bleibt unverändert — sie ist die "Eingabe" des Lehrbeispiels.
Sammelpunkte, die in die Lehr-Präambel gehören. Bewusst hier festgehalten, damit sie im Aufbereitungsschritt nicht verloren gehen:
Warum Spec ≠ Spezifikation. Eine 33-Zeilen-knight.md ist eine Intentionsskizze, kein vollständiger Auftrag. Pro Spec-Zeile entsteht im Schnitt ein bis zwei Mikro-Entscheidungen, die nur im Dialog beantwortbar sind (Wo platziert sich ein Button? Was bedeutet "Re-Klick" exakt? Welche Form von Symmetrie?). Eine "Ein-Rutsch"-Generation muss diese Mikro-Entscheidungen raten; die Wahrscheinlichkeit, alle simultan richtig zu raten, sinkt geometrisch mit der Featurezahl.
Warum Stufen. Jede Stufe = genau ein Feature + genau eine User-Validierung. Mikro-Entscheidung wird vor der Implementierung adressiert, getestet nach der Implementierung, committet wenn akzeptiert. Vorteile: (a) Rollback ist günstig, (b) Folgefehler-Kaskaden bleiben aus, (c) Performance-Probleme zeigen sich rechtzeitig (vor der nächsten Stufe), (d) der User behält jederzeit die Steuerung statt am Ende vor einem fait accompli zu stehen.
Warum "Mensch an die Hand nehmen". AI-Pair-Programming funktioniert nicht durch Auftrag-und-Abholen, sondern durch Mikro-Dialog: AI schlägt vor → User korrigiert/erweitert → AI implementiert → User testet → Commit. Der Lehrwert liegt in der Reibung, nicht im glatten Ergebnis. Wir zeigen die Reibung, indem wir den Dialog erhalten.
Was Profis anders machen. AI-Disziplin: Spec lesen, kritisch hinterfragen, eigene Annahmen kennzeichnen, Test-Disziplin halten, kommunikative Klarheit erzwingen. Diese Haltungen werden im Prozess sichtbar — nicht durch Erklären, sondern durch Tun.
Ziel: Garantierte Tabula rasa. Der existierende Code wird gesichert und entfernt, bevor irgendetwas Neues entsteht.
| Schritt | Aktion |
|---|---|
| 0.1 | git tag pre-rebuild-2026-05-13 auf einen Initial-Commit der existierenden Implementation gesetzt — der alte Code ist im Git-Objektspeicher auffindbar, falls didaktisch später ein Vergleich gewünscht ist. |
| 0.2 | git rm app.js board.js solver.js ui.js index.html style.css plus knight_plan.md durch diese neue Version ersetzen — Working-Tree enthält nur noch knight.md, den neuen knight_plan.md und .git/. Commit als Phase 0: tabula rasa for didactic rebuild. |
| 0.3 | Selbst-Verpflichtung, hier in Stein gemeißelt: während aller folgenden Phasen konsultiert der AI-Assistent (Claude) weder via Read noch via Bash noch über andere Werkzeuge den vor-existierenden Code. Er existiert nur noch im Git-Objektspeicher unter pre-rebuild-2026-05-13 und ist für die Übung tot. |
| 0.4 | Diesen Master-Plan als aide-knight/knight_plan.md versioniert — gleiche Datei, neuer Inhalt, sodass die Plan-Evolution ab dem ersten Schritt mit-protokolliert wird. |
Jede Phase folgt demselben Vier-Schritt-Rhythmus:
a) Mikrofragen klären → b) Implementierung → c) User-Test → d) Commit
Pro Phase: 1–3 vorgelagerte Fragen an den User (Mikro-Entscheidungen), klare Akzeptanzkriterien, ein einziger Commit am Ende. Die "Mikrofragen-Vorab"-Spalte enthält Beispiele — die Liste wird im Live-Dialog kürzer oder länger ausfallen.
| Phase | Ziel (eine Aussage) | Lieferumfang | Verifikation | Vorab-Mikrofragen-Beispiele |
|---|---|---|---|---|
| 1 | Brett rendert, Klick erkennbar | index.html, style.css, app.js (alles inline; Multi-File später) — 8×8 Schachbrett, Schachbrettfarben, Klick auf Feld zeigt im Status seine Koordinaten |
Browser per Doppelklick auf index.html öffnen, Brett sichtbar, Klick gibt Koord-Status |
Welche Schachbrett-Farben — klassisch braun/beige, Holzimitat, schwarz/weiß? Cursor-Style auf Feldern? |
| 2 | Knight's-Tour-Solver-Kern für 8×8 | solver.js mit iterativem DFS + Warnsdorff; Klick auf Feld startet Solve; Pfad wird als Linie + Felder-Nummern gerendert |
8×8 Springer-Tour löst in <100 ms; Linie + Nummern sichtbar | Linienfarbe? Strichstärke proportional zur Brettgröße? Wo wird "Zugversuche: N" angezeigt? |
| 3 | Variable Brettmaße + Performance-Fundament | W- und H-Eingaben, dynamische Canvas-Größe, Padding-Bordüre statt Bounds-Check (zukunftssicher für ungewöhnliche Move-Sets) | 100×200 löst noch (mit Warnsdorff) im einstelligen Sekundenbereich; 5×5 verweigert sinnvoll wenn keine Lösung existiert | Maximale Brettgröße eingrenzen? Wie viele Padding-Felder pro Seite (max move-radius)? |
| 4 | Drei Heuristiken, vier Figuren, Mix-Button | Dropdown Heuristik (Warnsdorff / Outside-In / Brute Force); Dropdown Figur (1,2)/(1,4)/(2,3)/(3,4); Button "Reihenfolge mischen" mit Tooltip, der die aktuelle Definitionsreihenfolge zeigt | Wechsel der Figur lädt Brett neu; Outside-In zeigt erkennbar andere Tour-Geometrie als Warnsdorff; Mix-Button erzeugt sichtbar andere Tour bei sonst gleichen Settings | Wo sitzt der Mix-Button? Permutiert er pro Klick neu oder bei jedem Reload? Persistent in localStorage? |
| 5 | Sichtbarkeits-Toggles | Checkbox "Nummern", Checkbox "Linien"; beide unabhängig | An/aus jeweils sofort sichtbar; auch bei großen Boards lesbar (Schriftgröße passt sich an?) | Schriftgröße fix oder adaptiv? Bei sehr kleinen Feldern Nummern nicht zeigen, auch wenn Checkbox an? |
| 6 | Geschlossene Touren via Beide-Enden-Verfahren | Checkbox "Geschlossen"; Solver baut alternierend an Front und Tail des Pfads an; abschließende Linie vom letzten zum ersten Feld im Render | 8×8 Springer geschlossen löst; Closing-Linie ist sichtbar deutlich (anders gestrichelt? andere Farbe?) | Wenn Closing-Linie diagonal über das Brett geht — wie wird sie visuell von der normalen Tour unterschieden? |
| 7 | Symmetrien (Achse, Punkt, Rotation-90° für Quadrate) | Dropdown oder Checkbox-Gruppe; Solver respektiert Constraint; Rotationssymmetrie wirklich nur ein Viertel der Tour suchend | Bei axisV auf 8×8 Springer Lösung sichtbar; bei point-Symmetrie ebenso; Rotation auf 6×6 Springer (falls Lösung existiert) | UI-Element: ein Dropdown mit allen Optionen, oder mehrere Checkboxes? Was passiert bei inkompatibler Kombination (Rotation auf nicht-quadratischem Brett)? |
| 8 | Blockierbare Felder via Rechtsklick | Rechtsklick togglet Feld blockiert/frei; blockierte Felder sind sichtbar anders dargestellt; Solver respektiert sie | Beliebige Form aus blockierten Feldern; Solver findet Tour um sie herum oder meldet "keine Lösung" | Rechtsklick-Visualisierung: Diagonal-Strich, anderer Farbton, X-Symbol? Browser-Kontextmenü unterdrücken? |
| 9 | Suchsteuerung: 5-s-Confirm + Re-Klick = nächste Lösung | Solver fragt alle 5 s per confirm(), ob weitergesucht werden soll; Re-Klick auf dasselbe Startfeld setzt die Suche von der aktuellen Lösung aus fort (nicht von vorn) |
Beim langen Lauf (100×200) erscheint Dialog; "Ja" sucht weiter, "Nein" bricht ab; Re-Klick liefert sichtbar andere Tour, Zugversuche-Zähler läuft weiter | Was bedeutet "dasselbe Startfeld" konkret — Cell-Koordinaten, oder Tour-ID-Erkennung? Re-Klick nach Heuristik-Wechsel — neu von vorn oder weiter? |
| 10 | Startfeld-Sensitivität-Button | Button erscheint erst nach erster Lösung; Klick startet Erstlösungs-Suche von jedem Startfeld; Zugzahl pro Startfeld wird in das jeweilige Feld geschrieben (statt der Tour-Nummer) | Auf 8×8 Springer Sensitivität-Lauf liefert 64 Zahlen, die Ecken-Felder zeigen typischerweise höhere Werte (mathematisch erwartet) | Farbcodierung der Zahlen (Heatmap)? Persistiert die Anzeige beim nächsten Tour-Start oder wird sie überschrieben? Klick auf eine Zelle danach — startet Tour mit altem Verhalten? |
| 11 | Code-Hygiene & 100×200-Stresstest | Falls Phase 1–10 alles in einer Datei zusammenhäuft: aufteilen in board.js, solver.js, ui.js, app.js (vier Module). OO-Sauberkeit (Klassen, klare Schnittstellen). 100×200-Lauf mit jeder Heuristik als Akzeptanztest |
Code-Review-tauglich: jede Datei < 250 Zeilen, klare Verantwortungstrennung, kein globaler State außerhalb der Modul-Klassen | — (keine Mikrofragen; Refaktor folgt aus dem bisherigen Code) |
Ziel: Aus dem verbatim aufgezeichneten Mensch-AI-Dialog wird zusammen mit dem User eine konsumierbare Lehrunterlage destilliert.
Schritte:
Phase 12 ist eine Co-Redaktion zwischen User und AI, kein Solo-Output.
git show pre-rebuild-2026-05-13:... oder ähnliche Tricks. Self-Verpflichtung aus Phase 0 ist bindend.knight.md steht, ist nicht Teil dieser Übung. Bei Fund neuer Wünsche im Verlauf: User entscheidet, ob die knight.md ergänzt wird (und damit ein neuer Item im Plan entsteht) oder ob der Wunsch geparkt wird.Am Ende von Phase 11 sind erfüllt:
knight.md funktionieren (gegen die Spec durchexerziert).file:// ohne Server/Node-Abhängigkeit.Am Ende von Phase 12 ist die Lehrunterlage in vom User gewähltem Format vorhanden, mit Präambel + redigiertem Verlauf der Phasen 0–11.
Diese Datei ist versioniert. Jede zukünftige Anpassung des Plans (z.B. wenn sich im Verlauf der Phasen herausstellt, dass eine Phase aufgespalten oder umgeordnet werden muss) entsteht als eigener Commit. git log -- knight_plan.md zeigt damit die historische Entwicklung des Plans selbst — ein Sekundär-Lehrmaterial: wie ein Plan unter Realität reagiert.