Problem
Wer AAMS per curl -sO aktualisiert, hat keinen Mechanismus der zeigt was sich zwischen der alten und neuen Version geaendert hat. Der Agent weiss nicht ob er von 1.0 auf 1.3 springt oder ob Breaking Changes vorliegen.
Aktueller Zustand
- Kein CHANGELOG.md im Repo (konzipiert in Workpaper
2026-03-27-versioning-system.md, nie umgesetzt)
- Keine Git-Tags / Releases auf GitHub
- Keine
.aams-version Datei im Zielrepo (konzipiert in 2026-04-10-AAMS-UPD, nie umgesetzt)
.agent.json enthaelt spec_version: AAMS-MINI/1.0 — aber kein Vergleichsmechanismus
Szenarien die nicht abgedeckt sind
| Szenario |
Was passiert heute |
| User aktualisiert 1.0 -> 1.3 |
Agent merkt nichts, kein Diff |
| User aktualisiert 1.x -> 2.0 (Breaking) |
Agent merkt nichts, bricht evtl. |
| Neuer Agent in bestehendem Repo |
Liest alte agent.json, keine Warnung |
WORKING/ existiert aber mit alter Struktur |
Kein Migrations-Hinweis |
Bereits konzipiert aber nicht umgesetzt
- Versioning-System (
2026-03-27): SemVer + CHANGELOG + GitHub Releases
- Update-Detection-Protocol (
2026-04-10): Fresh Install vs. Update vs. Major Upgrade Erkennung, .aams-version Datei
Beide Workpapers enthalten fertige Konzepte. Keines wurde implementiert — ein weiterer Beweis fuer das Decision-Kompoundierungs-Leck (Issue #48).
Vorgeschlagener Fix
- CHANGELOG.md im Repo-Root anlegen (Keep a Changelog Format)
- Git-Tags + GitHub Releases fuer jede Version
.aams-version Datei die der Agent im Zielrepo anlegt und bei jedem curl-Update vergleichton_update Handler in .agent.json (neben on_first_entry und on_session_start)- Migrations-Hinweise pro Version in CHANGELOG oder separatem
MIGRATIONS.md
Prioritaet
Hoch — Voraussetzung fuer jedes AAMS/2.0 Release. Ohne Upgrade-Transparenz ist jedes Update ein Blindflug.
Referenzen
Problem
Wer AAMS per
curl -sOaktualisiert, hat keinen Mechanismus der zeigt was sich zwischen der alten und neuen Version geaendert hat. Der Agent weiss nicht ob er von 1.0 auf 1.3 springt oder ob Breaking Changes vorliegen.Aktueller Zustand
2026-03-27-versioning-system.md, nie umgesetzt).aams-versionDatei im Zielrepo (konzipiert in2026-04-10-AAMS-UPD, nie umgesetzt).agent.jsonenthaeltspec_version: AAMS-MINI/1.0— aber kein VergleichsmechanismusSzenarien die nicht abgedeckt sind
agent.json, keine WarnungWORKING/existiert aber mit alter StrukturBereits konzipiert aber nicht umgesetzt
2026-03-27): SemVer + CHANGELOG + GitHub Releases2026-04-10): Fresh Install vs. Update vs. Major Upgrade Erkennung,.aams-versionDateiBeide Workpapers enthalten fertige Konzepte. Keines wurde implementiert — ein weiterer Beweis fuer das Decision-Kompoundierungs-Leck (Issue #48).
Vorgeschlagener Fix
.aams-versionDatei die der Agent im Zielrepo anlegt und bei jedem curl-Update vergleichton_updateHandler in.agent.json(nebenon_first_entryundon_session_start)MIGRATIONS.mdPrioritaet
Hoch — Voraussetzung fuer jedes AAMS/2.0 Release. Ohne Upgrade-Transparenz ist jedes Update ein Blindflug.
Referenzen
WORKING/WORKPAPER/2026-03-27-versioning-system.mdWORKING/WORKPAPER/2026-04-10-AAMS-UPD-update-install-detection-protocol.mdWORKING/WORKPAPER/2026-04-17-RES-WIKI-karpathy-llm-wiki-vergleich.md