Neues Default-Shell-Feld in der Projekt-Sektion (nach ---), damit der Agent die richtige Shell-Syntax waehlt. Bootstrap erkennt $SHELL (Fallback fish, Whitelist gegen sed-Injection) und schreibt es in frisch erzeugte copilot-instructions.md; manuell aenderbar und ueberlebt copilot-update. selftest +3 Faelle (sh & fish), beide MAINTAINER.md dokumentiert.
3.7 KiB
Session History
Prompt 1
nimm mal mit auf was die default shell auf dem system ist auf dem entwickelt wird, bei mir ist das fast immer fish und das sollte als default drin stehen aber auch änderbar sein bzw. bei einem neuen repo neu hinzugefügt werden muss.
Antwort 1
Ich habe ein Default-Shell-Feld eingeführt, das (a) standardmäßig fish enthält, (b) jederzeit manuell änderbar ist und (c) beim Bootstrap eines neuen Repos automatisch aus $SHELL des Entwicklungssystems gesetzt wird.
Zentrale Designentscheidung: Das Feld liegt in der Projekt-Sektion der copilot-instructions.md (nach dem ersten ---). Grund: copilot-update schreibt die Framework-Sektion (vor ---) bei jedem Update neu — nur hinter --- überlebt ein repo-/maschinenspezifischer Wert. Diese Constraint habe ich zusätzlich im Repo-Memory festgehalten.
Geänderte Dateien (7):
.github/copilot-instructions.md # neue Sektion "🖥 Entwicklungsumgebung" mit "- **Default-Shell:** fish" (nach ---)
git-templates/.github/copilot-instructions.md # gleiche Sektion im Template (Wert wird beim Bootstrap ersetzt)
scripts/copilot-bootstrap.sh # $SHELL-Erkennung (basename, Fallback fish, Whitelist ^[a-z0-9_-]+$) + _set_dev_shell()
scripts/copilot-bootstrap.fish # Parität zur sh-Version (string match -qr Validierung, functions -e Cleanup)
scripts/selftest.sh # neue Fälle: Default-Shell-Zeile vorhanden + SHELL=zsz/leer → korrekter Wert (sh & fish)
docs/MAINTAINER.md # Designentscheidung + Fallstrick "Feld nach --- platzieren" dokumentiert
git-templates/docs/MAINTAINER.md # Default-Shell-Feld für neue Repos erklärt
Implementierungsdetails der Erkennung (identisch in sh und fish):
$SHELL→basename(z. B./usr/bin/fish→fish); leeres$SHELL→ Fallbackfish.- Wert gegen
^[a-z0-9_-]+$geprüft (verhindert sed-Injection), sonst Fallbackfish. _set_dev_shell()ersetzt die- **Default-Shell:** …-Zeile nur in frisch erzeugtencopilot-instructions.md(bestehende Dateien bleiben unangetastet → User-Anpassung bleibt erhalten).
Prompt 2
War das hier alles abgeschlossen und committed, dokumentiert und gepusht?
Antwort 2
Nein — der Code war fertig und validiert, aber nicht committed, nicht in die History dokumentiert und nicht gepusht; zusätzlich lag der lokale Branch 1 Commit hinter origin/master. Ich habe den Zustand geprüft, das fehlende Remote-Commit integriert, alles validiert und anschließend History + Kontext geschrieben, committed und gepusht.
Statusprüfung:
git status → 7 unstaged Dateien, "behind 'origin/master' by 1 commit"
git log --oneline @{u}.. → leer (nichts unpushed, weil nichts committed)
sh -n / fish -n → bootstrap.sh OK, selftest.sh OK, bootstrap.fish OK
sh scripts/selftest.sh → 6/6 PASS (inkl. neuer Shell-Erkennungsfälle)
Integration des Remote-Commits (e83c333 docs: add rd13 infrastructure conventions) trotz dirty tree — die 3 überlappenden Dateien hatten Hunks an unterschiedlichen Stellen, daher konfliktfrei:
git stash push -m dev-shell-feature-wip -- <7 Dateien>
git pull --ff-only # 5dc89f0 → e83c333, Fast-forward
git stash pop # Auto-merge: docs/MAINTAINER.md, git-templates/{.github/copilot-instructions,docs/MAINTAINER}.md → exit 0, keine Konflikte
Verifikation nach Merge: beide Änderungssätze (rd13_-Blöcke + Default-Shell) in allen überlappenden Dateien vorhanden, Selftest erneut 6/6 PASS.
Danach: Session-History (diese Datei) angelegt, PROJECT_CONTEXT.md aktualisiert, committed (pre-commit Quality Gate bestanden) und nach origin/master gepusht.