after-care 2026-09-08: kein AST-Parser hinter der AST-Behauptung, drei Advisories geschlossen, drei Test-Pins umgedreht

[lukisch]

Surface-After-Care-Runde, Zeile 25 der ellmos-ai-Rotation. Sechs thematisch getrennte Commits, alle drei Test-Gates lokal grün (189 Vitest, 35 MCP-stdio, 43 i18n), npm audit auf 0.

master ist über klassischen Branch-Schutz geschützt (rules/branches/master liefert [], erst branches/master/protection zeigt required_approving_review_count: 1) — deshalb PR statt Direkt-Push, und deshalb braucht dieser PR ein echtes Approval, nicht nur einen Merge.

Hauptfund: die Doku bewarb einen AST-Parser, den es nicht gibt

README, README_de und llms.txt versprachen AST-based class/method extraction. Die Quelle widerspricht dem selbst — der Kommentar über analyzePythonCode lautet // Simple Python AST-like parser, die Implementierung liest Zeilen und Regexe, und das Paket hat überhaupt keine Parser-Abhängigkeit (nur Format-Parser für JSON/YAML/TOML/XML). Ein echtes ast.parse läuft an genau zwei Stellen: als Subprozess-Sperre vor jedem apply in cc_python_structural_edit und in cc_runtime_import_diagnose.

Das ist kein Wortstreit. An verschachtelten und mehrzeiligen Konstrukten verhält sich ein Scanner anders als ein Parser, und wer „AST" liest, rechnet mit Letzterem.

Beim Nachlesen fiel die zweite, bisher nirgends dokumentierte Grenze auf: 9 der 23 Tools setzen Python voraus und prüfen die Dateiendung nicht. Eine .ts-Datei liefert deshalb kein Fehlersignal, sondern ein plausibel aussehendes falsches Ergebnis — typischerweise null Klassen und eine fehlgelesene Import-Liste. Beides steht jetzt in einem Abschnitt Scope and limits / Geltungsbereich und Grenzen in beiden READMEs plus einer Scope-Notiz in llms.txt, zusammen mit der Angabe, welche zwei Tools einen lokalen python-Interpreter brauchen.

Den fehlenden Extension-Guard behebt dieser PR nicht — das ist eine Verhaltensänderung und als Aufgabe vorgemerkt.

Sicherheit: drei offene Advisories, jetzt 0

Paket	vorher	nachher	Advisory
@toon-format/toon	^2.1.0	^2.3.1	GHSA-p95v-992w-h6c3 — high, Prototype Pollution beim Dekodieren von TOON
qs (override)	^6.15.2	^6.16.0	GHSA-x5fp-wj9c-mxmx, GHSA-4mjr-xmp4-gh2g
fast-uri (override)	^3.1.5	^3.1.7	löst Dependabot-PR #10 ab

Das TOON-Advisory ist das ernsteste, weil es genau auf einem beworbenen Pfad liegt: cc_convert_format nimmt TOON als Eingabeformat entgegen, also untrusted input by design. Bewusst auf der 2er-Linie geblieben — 2.3.1 schließt das Advisory, latest (4.1.1) wären zwei Major-Sprünge und ein Verhaltensrisiko für die Konvertierung.

PR #10 stand seit dem 2026-09-03 auf BLOCKED und blieb deshalb liegen; der Bump ist hier enthalten.

Vierter Fall in Folge: Tests, die verteidigen, was sie finden sollten

test/metadata.test.ts pinnte an drei Stellen den Ist-Zustand statt der Eigenschaft — jede dieser Zusicherungen hätte genau die Änderung rot gemacht, für die sie gedacht war:

1. badge/Vitest-187%20passed als Literal → jeder neue Test hätte die Suite gebrochen. Der Test bestrafte das Testen. Jetzt: Format prüfen und zusätzlich, dass README, README_de und llms.txt dieselbe Zahl nennen — das fängt die Divergenz, um die es eigentlich geht. (Belegt: dieser PR fügt zwei Tests hinzu, 187 → 189.)
2. Last-checked: 2026-09-06 als Literal → jede Auffrischung des Frischestempels, also sein Zweck, hätte den Test gebrochen. Jetzt Datumsformat statt Datum.
3. actions/checkout@v4 / setup-node@v4 als Literale → hätten jede SHA-Pinnung blockiert. Jetzt Tag oder 40-stelliger SHA, und die Workflow-Datei ist entsprechend gepinnt (checkout v7.0.1 3d3c42e5…, setup-node v7.0.0 82076278…; beide über die GitHub-API zum Release-Tag aufgelöst, nicht geraten).

Dazu war EXPECTED_TOOL_COUNT eine handgepflegte Konstante, die dieselbe Änderung hätte mitpflegen müssen, die sie absichern soll — sie wird jetzt aus src/index.ts gezählt (23). Neu ist ein Negativ-Guard gegen die Rückkehr der AST-based-Behauptung.

Privacy

docs/MEHRSPRACHIGKEIT-ANALYSE_2026-08-25.md war getrackt und damit öffentlich. Es ist keine Nutzerdokumentation, sondern eine interne Entscheidungsvorlage, und gab preis: eine interne Ticket-ID samt Ticketsystem und Hostname, den absoluten lokalen Repo-Pfad, die auf dem Maintainer-Rechner installierten Plugins samt Pfad, Portfolio-Interna und die wörtlich zitierte Nutzerfrage aus einer privaten Sitzung. Kein Secret, deshalb kein Force-Push — git rm --cached plus .gitignore. Der öffentlich relevante Teil steckt jetzt im Scope-Abschnitt der README.

Changelog

## [1.3.23] stand dreimal da (08-24, 08-21, 08-16) und las sich wie drei Releases derselben Nummer. npm kennt genau ein 1.3.23, veröffentlicht am 2026-08-25 — also nach allen drei Blöcken. Jetzt eine Überschrift mit dem echten Veröffentlichungsdatum, die drei Arbeitsdaten als Unterabschnitte. Nebenbefund im Hinweis vermerkt: 1.3.19, 1.3.20, 1.3.21 sind auf npm veröffentlicht, haben aber keinen Changelog-Eintrag.

Der 1.3.25-Block steht bewusst als unreleased, die Versionsträger bleiben auf 1.3.24 — eine deklarierte Version, die es auf keiner Fläche gibt, wäre genau der Versions-Drift, den diese Runde sonst aufräumt.

Sonstiges

• .gitattributes mit LF-Pin ergänzt (sechster Phantom-Diff-Fall der Rotation): ohne ihn meldet ein Checkout unter Linux/macOS alle 40 getrackten Textdateien als vollständig geändert. Renormalisierung geprüft — sie ändert keine einzige Datei.
• llms.txt: DokuReader stand mit | statt : und brach als Listeneintrag; Last-checked auf 2026-09-08.
• Alle 24 in README und llms.txt verlinkten Repos gegen die API auf public geprüft — kein 404, anders als bei den beiden Vorläufern der Rotation.

Offen (als Aufgaben erfasst, nicht in diesem PR)

• Extension-Guard für die neun Python-Tools statt stillem Fehlbefund.
• Release 1.3.25 + Tag nach dem Merge; die npm-Paketseite zeigt sonst weiter die alte, falsche AST-Aussage.
• Sieben veröffentlichte npm-Versionen (1.3.17–1.3.23) haben keinen Git-Tag.
• Fünf Geschwister-Flächen nennen CodeCommander weiter mit 22 Tools (FileCommander README/README_de/llms.txt, Clatcher README/llms.txt) — der 1.3.24-Changelog behauptete „sibling sync", der aber nur in eine Richtung lief. Beide Nachbar-Repos sind ebenfalls branch-geschützt.
• FileCommanders eigene GitHub-Beschreibung sagt „44 tools", seine README sagt 50.

[github-actions]

Welcome! 👋 Thanks for your first pull request in this repository.

A maintainer will review it soon. Please make sure:

• Your changes are tested
• Documentation is updated if needed
• The PR description explains what and why

Thanks for contributing!