update-stack-spec

Stack-Spezifikation aktualisieren

Fakten (Versionen, Daten, Messungen, Quellen) aktualisieren Sie. Entscheidungen schlagen Sie dem Autor vor und warten ab. Argumente benennen die zu prüfenden Tools; andernfalls alle prüfen.

1. Bestandsaufnahme

Aus stack-spec.md auflisten:

• jede Zeile von §2 mit ihrer Versionszeile;
• jede Version, jedes Veröffentlichungsdatum oder jede Stabilitätsangabe in §3 und §4 („stable“, „release candidate“, „alpha“, „experimental“, eine Versionsnummer neben einem Tool);
• jede Zeile von Revisit when als zu testende Bedingung;
• das Versionsdatum der Kopfzeile.

2. Prüfung anhand von Primärquellen

Registry, Release-Notes, offizielle Dokumentation. Niemals aus dem Gedächtnis.

• npm: npm view <pkg> dist-tags time --json. Aktuell = neuestes Release, das mindestens 14 Tage alt ist; jüngere Releases als kommend auflisten.
• nixpkgs-Tools (Node.js, Biome, nixfmt, Wrangler, Playwright Browser): nix eval --raw nixpkgs#<pkg>.version auf nixos-unstable, plus die Release-Seite des Projekts.
• Plattform-Features (Cloudflare, Browser-Support): die offizielle Dokumentationsseite und ihr Datum.

Pro Tool aufzeichnen: Versionszeile der Spezifikation, aktuelle Version und ob ein Major-Release (oder ein Release, auf das die Spezifikation wartet) dazwischenliegt.

3. Klassifizierung jeder Änderung

Das Changelog oder den Migrationsleitfaden jedes neuen Major-Release vollständig lesen, sowie die Dokumentation, auf die sich die Spezifikation stützt. Dann klassifizieren:

• Fakt (Versionszeile, Datum, Paketanzahl): aktualisieren.
• Grund (ein genanntes Hindernis behoben, ein neues eingeführt): den Text des Grunds aktualisieren; im Bericht auflisten.
• Entscheidung (die Wahl selbst, eine Alternative nun besser, ein ausgelöster Revisit when-Auslöser): nicht bearbeiten. Berichten: was sich geändert hat, Quelle, Optionen mit Kosten, Empfehlung. Abwarten.

4. Bearbeitung

• Den Stil der Spezifikation beibehalten: knapp, Regel zuerst, Grund danach, ISO-Daten; geänderten Entscheidungstext mit „Geändert : …“ kennzeichnen.
• Neue Fakten → neue Quelle am Ende der nummerierten Liste, mit „geprüft “. Quellen nie umnummerieren; eine Quelle nur löschen, wenn nichts darauf verweist.
• Abschnitte nie umnummerieren. Ein neues Thema wird der nächste Unterabschnitt seines Abschnitts; den Autor fragen, ob eine Site diese Nummer bereits verwendet, und die gewählte Nummer melden.
• Das Versionsdatum der Kopfzeile aktualisieren.
• Keine Site, keinen Benutzer und kein Repository nennen, das die Spezifikation verwendet.

5. Verifikation und Commit

• Jede neue oder geänderte URL auflöst: curl -sIL <url>.
• Keine Site, kein Benutzer und kein Repository, das die Spezifikation verwendet, wird genannt.
• Jujutsu, signiert, ein Commit pro Thema (z. B. „Record Astro 8“, „Propose TypeScript 7“), die Nachricht enthält, was geändert wurde, warum und welche Quellen geprüft wurden. Nicht pushen, außer auf Anfrage.

6. Berichterstellung

Pro Tool: Spezifikationsversion → aktuell. Dann: aktualisierte Fakten, geänderte Gründe, vorgeschlagene Entscheidungen mit Empfehlungen, kommende Releases, die noch keine 14 Tage alt sind.