66 lines
3.2 KiB
Markdown
66 lines
3.2 KiB
Markdown
# Auftrag: Quelldatei in Einheiten zerlegen
|
||
|
||
Du bekommst unten den vollständigen Inhalt der Datei `<DATEI>` aus einem
|
||
Python-Projekt. Zerlege sie in **Einheiten** und gib GENAU EINE Markdown-Datei im
|
||
unten definierten Format zurück — nichts davor, nichts danach, keine Code-Fences
|
||
um das Gesamtergebnis.
|
||
|
||
## Was ist eine Einheit
|
||
|
||
Das Kleinste mit **eigener Verantwortung**, das sich in einem Satz beschreiben lässt —
|
||
meist eine Funktion oder Klasse; mehrere kleine, zusammengehörige Symbole dürfen eine
|
||
Einheit bilden. Jede Funktion/Klasse der Datei gehört zu genau einer Einheit (MECE).
|
||
Modul-Konstanten und Imports darfst du unzugeordnet lassen.
|
||
|
||
## Ausgabeformat (exakt einhalten)
|
||
|
||
```
|
||
# Einheiten: <DATEI>
|
||
stand: UNBEKANNT
|
||
|
||
## <DATEI>::<hauptsymbol>
|
||
beschreibung: <genau ein Satz: die Verantwortung der Einheit, ohne „und"-Aufzählung>
|
||
input: <was die Einheit entgegennimmt — Parameter/Quellen, eine knappe Zeile>
|
||
output: <was sie liefert bzw. bewirkt — Rückgabe/Effekt, eine knappe Zeile>
|
||
entscheidungen:
|
||
- <kurzer Satz: eine im Code getroffene Design-Entscheidung oder Garantie>
|
||
beleg: "<kurzes WÖRTLICHES Zitat aus der Datei, das sie stützt>"
|
||
- <weitere Entscheidungen nach demselben Muster>
|
||
kanten:
|
||
- ruft-auf: <einheiten-id>
|
||
- nutzt: <einheiten-id>
|
||
- wird-genutzt-von: <einheiten-id>
|
||
```
|
||
|
||
Regeln:
|
||
- Einheiten-ID = `<DATEI>::<symbolname>` (bei gebündelten Symbolen: das
|
||
Hauptsymbol als ID, zusätzliche Symbole je als Zeile `anker: <DATEI>::<symbol>`
|
||
direkt unter der Überschrift).
|
||
- `beschreibung:` ist genau EIN Satz und beschreibt EINE Aufgabe — keine
|
||
„und"-Aufzählungen.
|
||
- `input:` und `output:` sind Pflicht: je EINE knappe Zeile (was geht rein, was kommt
|
||
raus bzw. welcher Effekt tritt ein). Bei Klassen: was sie zum Bau braucht / was sie
|
||
bereitstellt. Keine Prosa.
|
||
- 2–5 Entscheidungen je Einheit: kurze Sätze über im Code getroffene Design-
|
||
Entscheidungen und Garantien (was ist zugesichert, was wurde bewusst so gebaut) —
|
||
KEIN Nacherzählen der Implementierung. Jede Entscheidung gehört zu der Einheit, in
|
||
deren Code-Körper der Beleg steht (Modul-Ebene nicht einer Klasse zuschlagen).
|
||
- Jede Entscheidung hat GENAU EINE `beleg:`-Zeile. Das Zitat muss WÖRTLICH (Zeichen für
|
||
Zeichen, inkl. Klammern und Unterstrichen) in der Datei vorkommen und ein
|
||
zusammenhängender Ausschnitt aus GENAU EINER Quellzeile sein — NIEMALS mehrere
|
||
Zeilen zu einer zusammenziehen (kein `if x: return y`, wenn das `return` in der
|
||
nächsten Zeile steht; zitiere dann nur `if x:` oder nur `return y`). Max. ~60 Zeichen.
|
||
- Kanten-Typen nur: `ruft-auf`, `nutzt`, `wird-genutzt-von`, `löst-aus`, `wird-ausgelöst-von`.
|
||
Hinter dem Ziel steht NICHTS mehr — kein Kommentar, keine Klammern. Richtungen:
|
||
`ruft-auf`/`nutzt` = diese Einheit verwendet das Ziel in ihrem Code-Körper;
|
||
`wird-genutzt-von` = das Ziel verwendet diese Einheit in SEINEM Code-Körper.
|
||
Ziele innerhalb der Datei: `<DATEI>::<symbol>`. Ziele in anderen Modulen
|
||
(aus den Imports ableitbar): `backend/<modul>.py::<symbol>`, z. B. nutzt die Datei
|
||
`db.kanban_pull` → `backend/database.py::kanban_pull`.
|
||
- Keine Kante erfinden, die nicht im Code steht. Lieber weniger Kanten als falsche.
|
||
- Schreibe auf Deutsch.
|
||
|
||
## Quelldatei `<DATEI>`
|
||
|
||
<QUELLE>
|