initla commit
This commit is contained in:
commit
bf439383e8
|
|
@ -0,0 +1,7 @@
|
||||||
|
{
|
||||||
|
"permissions": {
|
||||||
|
"allow": [
|
||||||
|
"Skill(review)"
|
||||||
|
]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
@ -0,0 +1,32 @@
|
||||||
|
# Projekt Framework "Planung der Planung"
|
||||||
|
|
||||||
|
## Ziel
|
||||||
|
Das Ziel dieses Projektes ist die Planung der Planung für ein Reverse-Engineering-Projekt — also nicht das eigentliche Reverse-Engineering-Projekt, sondern die Frage: Wie strukturiere ich ein komplexes, multi-session Claude Code Projekt so, dass es kohärent bleibt?
|
||||||
|
Konkret erarbeitet haben wir:
|
||||||
|
Ein Projektgerüst mit drei Clustern (Discovery, Planung, Umsetzung), einer zentralen CLAUDE.md als Projekt-Gedächtnis, und dem Prinzip dass das Projekt in Dateien lebt — nicht in Sessions.
|
||||||
|
Ein Session-Protokoll mit festem Einstiegs- und Abschluss-Muster, das den Kontext jeder Session zuverlässig wiederherstellt.
|
||||||
|
Die konkreten ersten Schritte, um von einem leeren Ordner mit Legacy-Code zu einem startbereiten Projektgerüst zu kommen — bevor auch nur eine Zeile Legacy-Code angefasst wird.
|
||||||
|
Und schließlich Templates für die wiederkehrenden Dokumente, die Claude Code als Vorlage nutzt und nie selbst verändert.
|
||||||
|
Der rote Faden war durchgehend: Struktur vor Inhalt. Das Gerüst steht, bevor die eigentliche Arbeit beginnt.
|
||||||
|
|
||||||
|
## Legacy-Code
|
||||||
|
Liegt in: legacy/
|
||||||
|
Regel: Keine Datei in legacy/ wird verändert. Nur lesen.
|
||||||
|
|
||||||
|
## Aktiver Scope
|
||||||
|
Aktuelle Phase: 1 — Discovery
|
||||||
|
Arbeitsverzeichnis: docs/A_discovery/
|
||||||
|
Schreibrechte: docs/A_discovery/**, docs/B_planning/decisions-log.md,
|
||||||
|
phase-1/status.md
|
||||||
|
Keine Änderungen an: src/**, legacy/**
|
||||||
|
|
||||||
|
## Konventionen
|
||||||
|
- Entscheidungen immer in decisions-log.md eintragen (oben anfügen, nie editieren)
|
||||||
|
- Jede Session endet mit aktuellem status.md
|
||||||
|
- Offene Fragen explizit notieren, nicht stillschweigend überspringen
|
||||||
|
|
||||||
|
## Session-Einstieg
|
||||||
|
1. Diese Datei lesen
|
||||||
|
2. phase-N/task.md lesen
|
||||||
|
3. phase-N/status.md lesen
|
||||||
|
4. Kurze Zusammenfassung, dann auf Bestätigung warten
|
||||||
|
|
@ -0,0 +1,18 @@
|
||||||
|
# Phase 1 — Discovery
|
||||||
|
|
||||||
|
## Ziel
|
||||||
|
Den Legacy-Code so weit verstehen, dass das Domänenmodell,
|
||||||
|
die Capabilities und die KI-Kandidaten dokumentiert sind.
|
||||||
|
|
||||||
|
## Ergebnisse (Definition of Done)
|
||||||
|
- [ ] docs/A_discovery/domain-model.md — Entitäten, Beziehungen, Kernregeln
|
||||||
|
- [ ] docs/A_discovery/capabilities-inventory.md — Was kann das System?
|
||||||
|
- [ ] docs/A_discovery/data-candidates.md — Welche Daten eignen sich für KI?
|
||||||
|
- [ ] docs/A_discovery/open-questions.md — Was bleibt unklar?
|
||||||
|
|
||||||
|
## Nicht in Scope
|
||||||
|
- Architekturentscheidungen für das neue System
|
||||||
|
- Embedding- oder KI-Strategie
|
||||||
|
- Irgendwelcher neuer Code
|
||||||
|
```
|
||||||
|
|
||||||
|
|
@ -0,0 +1,28 @@
|
||||||
|
<!--
|
||||||
|
Eintrag oben in decisions-log.md einfügen.
|
||||||
|
Niemals bestehende Einträge editieren.
|
||||||
|
Datum: YYYY-MM-DD
|
||||||
|
-->
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## YYYY-MM-DD — [Kurztitel, max. 8 Wörter]
|
||||||
|
|
||||||
|
**Phase / Session:** Phase N, Session M
|
||||||
|
**Typ:** [ ] Architektur [ ] Datenmodell [ ] KI-Strategie [ ] Prozess [ ] Sonstiges
|
||||||
|
|
||||||
|
**Kontext**
|
||||||
|
Warum stand diese Entscheidung an? Was war der Auslöser?
|
||||||
|
|
||||||
|
**Entscheidung**
|
||||||
|
Was genau wurde entschieden? Konkret und eindeutig formuliert.
|
||||||
|
|
||||||
|
**Verworfene Alternativen**
|
||||||
|
- Alternative A — verworfen weil:
|
||||||
|
- Alternative B — verworfen weil:
|
||||||
|
|
||||||
|
**Konsequenzen**
|
||||||
|
Was folgt daraus? Welche anderen Dokumente oder Phasen sind betroffen?
|
||||||
|
|
||||||
|
**Offen / Revisierbar?**
|
||||||
|
[ ] Endgültig [ ] Revisierbar wenn: _______________
|
||||||
|
|
@ -0,0 +1,42 @@
|
||||||
|
<!--
|
||||||
|
Discovery-Dokument
|
||||||
|
Erstellt: YYYY-MM-DD
|
||||||
|
Zuletzt aktualisiert: YYYY-MM-DD
|
||||||
|
Status: [ ] Entwurf [ ] Review [ ] Abgeschlossen
|
||||||
|
Quelle: [Aus welchem Teil des Legacy-Codes wurde dies abgeleitet?]
|
||||||
|
-->
|
||||||
|
|
||||||
|
# [Dokumenttitel]
|
||||||
|
|
||||||
|
## Zweck
|
||||||
|
Was dokumentiert dieses Dokument, und warum ist es relevant für das Projekt?
|
||||||
|
|
||||||
|
## Methode
|
||||||
|
Wie wurde dieses Wissen gewonnen?
|
||||||
|
(z.B. Schema-Analyse, Code-Lektüre, UI-Flows, Validierungsregeln)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Befunde
|
||||||
|
|
||||||
|
[Hier der eigentliche Inhalt — struktur je nach Dokumenttyp:]
|
||||||
|
|
||||||
|
### [Abschnitt 1]
|
||||||
|
...
|
||||||
|
|
||||||
|
### [Abschnitt 2]
|
||||||
|
...
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Unsicherheiten
|
||||||
|
Dinge, die unklar geblieben sind oder nur vermutet werden.
|
||||||
|
- [ ] [Unsicherheit] → Klärung nötig durch: _______________
|
||||||
|
|
||||||
|
## Querverweise
|
||||||
|
Welche anderen Discovery-Dokumente oder Entscheidungen hängen damit zusammen?
|
||||||
|
- docs/discovery/___
|
||||||
|
- docs/planning/decisions-log.md → Eintrag vom ___
|
||||||
|
|
||||||
|
## Nächste Schritte
|
||||||
|
Was muss auf Basis dieses Dokuments als nächstes passieren?
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
Am Ende der Session, bevor du aufhörst:
|
||||||
|
- Aktualisiere phase-N/status.md mit dem aktuellen Stand
|
||||||
|
- Trage getroffene Entscheidungen in decisions-log.md ein
|
||||||
|
- Markiere in task.md, was abgeschlossen ist
|
||||||
|
- Notiere offene Fragen oder nächste Schritte explizit
|
||||||
|
|
@ -0,0 +1,3 @@
|
||||||
|
Das Ziel dieser Session ist: [konkrete Aufgabe].
|
||||||
|
Nicht in Scope heute: [was du explizit ausklammern willst].
|
||||||
|
Ergebnis am Ende soll sein: [konkretes Artefakt — Datei, Funktion, Dokument].
|
||||||
|
|
@ -0,0 +1,14 @@
|
||||||
|
Lies zunächst diese Dateien in dieser Reihenfolge, ohne sofort zu handeln:
|
||||||
|
1. CLAUDE.md
|
||||||
|
2. docs/planning/session-plan.md
|
||||||
|
3. docs/planning/decisions-log.md (nur die letzten 5 Einträge)
|
||||||
|
4. phase-N/task.md
|
||||||
|
5. phase-N/status.md
|
||||||
|
|
||||||
|
Fasse danach in 3-5 Sätzen zusammen:
|
||||||
|
- Was ist das Gesamtziel des Projekts?
|
||||||
|
- Was ist das Ziel dieser Phase?
|
||||||
|
- Was wurde zuletzt erreicht, und wo stehen wir gerade?
|
||||||
|
- Was sind bekannte offene Fragen oder Blocker?
|
||||||
|
|
||||||
|
Warte auf meine Bestätigung, bevor du anfängst.
|
||||||
|
|
@ -0,0 +1,21 @@
|
||||||
|
# Status — Phase N: [Phasenname]
|
||||||
|
|
||||||
|
Letzte Aktualisierung: YYYY-MM-DD
|
||||||
|
Session-Nr.: N
|
||||||
|
|
||||||
|
## Erledigtes
|
||||||
|
- [ ] Aufgabe A → erledigt, Ergebnis: [Datei/Befund]
|
||||||
|
- [ ] Aufgabe B → erledigt, Ergebnis: [Datei/Befund]
|
||||||
|
|
||||||
|
## Aktueller Stand
|
||||||
|
[2-3 Sätze: Wo stehen wir? Was ist der Zwischenstand?]
|
||||||
|
|
||||||
|
## Nächste Schritte
|
||||||
|
1. [Konkrete nächste Aufgabe]
|
||||||
|
2. [Übernächste Aufgabe]
|
||||||
|
|
||||||
|
## Offene Fragen / Blocker
|
||||||
|
- [Frage oder Problem, das nicht in dieser Session lösbar war]
|
||||||
|
|
||||||
|
## Nicht angefasst (bewusst ausgeklammert)
|
||||||
|
- [Was in Scope war, aber verschoben wurde — und warum]
|
||||||
Loading…
Reference in New Issue