aSPARK liest Flask: 21 von 21 Quellen stimmen, eine Spur nicht

aSPARK ist bereits in einer Reihe von Projekten über die des Autors hinaus im Einsatz. Die meisten davon sind nicht Open Source, deshalb gibt es dazu keine Links. Diese Serie ergänzt, was jene Projekte nicht leisten können: Läufe auf bekanntem Open-Source-Code, die jeder selbst nachprüfen kann. Wir nehmen ein Repository, lassen aSPARK auf einem frischen Klon laufen und veröffentlichen, was herauskam: das Gute, das Falsche und wie wir es geprüft haben. Den Anfang macht Flask.

An das Flask-Projekt ging dabei nichts, weder ein Issue noch ein Pull Request. Alles lief auf einem lokalen Klon mit festem Commit, pallets/flask@d73fa1c (8. September 2026).

Was wir ausgeführt haben

/charter im Discovery-Modus. Auf einem Repository, das schon Code hat, fragt der Facilitator nicht, was das Projekt ist. Er liest es und schreibt §9 Project Context der Constitution: einen Produkt-Steckbrief und ein Systembild aus sieben Einträgen, jeder mit der Fundstelle file:line, aus der er stammt.
Die Bestätigungsrunde. Danach lässt /charter einen Menschen das Bild einmal bestätigen. Das waren wir. Da wir nicht das Flask-Team sind, haben wir die vier Produktfragen als fiktives Team beantwortet, das an Flask selbst arbeitet. Diese Antworten sind unten als unsere gekennzeichnet.
aspark-graph auf demselben Klon: Größe, Bauzeit, Determinismus und welche Module im Zentrum stehen.
/next-steps: Der Product Owner sichtet das Projekt und schlägt ein nächstes Feature vor. Er schreibt nichts; es ist eine Empfehlung.

Was aSPARK über Flask geschrieben hat

Das Systembild, wie geschrieben (leicht gekürzt):

Einstiegspunkte: die Klasse Flask und die CLI flask (src/flask/app.py:110, src/flask/cli.py:1122, pyproject.toml:81-82).
Modulstruktur: ein I/O-freier Kern in sansio/, darüber die WSGI-Schicht, json/ als Unterpaket.
Datenmodell: not found. In src/ gibt es keine Persistenz, und zwar mit Absicht: „Flask will never have a database layer" (docs/design.rst:210).
Testpraxis: pytest über tox für Python 3.10 bis 3.15 und PyPy, Warnungen gelten als Fehler, dazu mypy und pyright über tests/type_check/.
Konventionen: Jede Änderung bringt Test, Doku, einen CHANGES-Eintrag und versionchanged mit; ruff und codespell.
Starten: uv run --group dev tox run.
Bekannte Baustellen: Async-Views laufen auf Threads (kein ASGI), und die Zusammenlegung von RequestContext und AppContext steckt mitten in der Deprecation (docs/design.rst:191-202, CHANGES.rst:8-16).

Dazu fand er einen kleinen Widerspruch im Repository: Das Pull-Request-Template verweist auf eine CONTRIBUTING.rst, die es im Repo nicht gibt; der Leitfaden für Beiträge liegt auf der Pallets-Website.

Das vorgeschlagene und von uns bestätigte Profil: eine library mit cli, dazu handles-auth, weil Flask signierte Cookie-Sessions mit Rotation der Secret Keys umsetzt (src/flask/sessions.py:309). Damit ist für spätere Phasen die security-Lens aktiv.

Der Faktencheck: 21 von 21

Ein Bild mit Quellen ist nur so viel wert wie seine Quellen. Ein kurzes Skript hat jede Fundstelle file:line aus §9 gegen den Klon geprüft: Die Datei muss existieren, die Zeile muss im Bereich liegen, und die zitierte Zeile wird ausgegeben, damit ein Mensch beurteilen kann, ob sie sagt, was der Eintrag behauptet.

21 von 21 Fundstellen existieren. Anschließend haben wir die zitierten Zeilen gelesen: Sie zeigen auf das, was ihr Eintrag beschreibt. Einige zitieren eine Datei über ihre erste Zeile statt über eine bestimmte Aussage (der Eintrag zur Modulstruktur zeigt auf sansio/scaffold.py:1). Das ist ein schwächerer Beleg, aber kein falscher. Der stärkste ist docs/design.rst:210, dort steht wörtlich „Flask will never have a database layer."

Der ganze Discovery-Lauf dauerte knapp drei Minuten.

Der Graph

aspark-graph baut einen deterministischen Graphen aus dem Code (und aus dem Delivery-Trail, den Flask nicht hat):

1.663 Code-Elemente, 171 Import-Kanten.
Dreimal gebaut, jedes Mal byte-identisch (sha256 7a6150df…), jeweils in wenigen Sekunden auf einem ausgelasteten Laptop.
Das Zentrum der Codebasis: flask/__init__.py wird 52-mal importiert, globals.py 17-mal, helpers.py und wrappers.py je 10-mal.

Ohne .spark/-Trail gibt es noch keine Stories, also hat eine Frage wie „Welche Stories berührt diese Änderung?" nichts, worauf sie antworten könnte. Diese Ebene wächst mit jedem Durchlauf, den ein Team macht.

Der Vorschlag: ein Upgrade-Leitfaden für 3.2

/next-steps empfahl ein Feature, Größe S, reine Doku: einen Upgrade-Leitfaden für die Kontext-Zusammenlegung in Flask 3.2 und die neuen Dispatch-Signaturen.

Die Begründung, die wir Zeile für Zeile geprüft haben:

In 3.2 bekommen zwölf überschreibbare Methoden ctx: AppContext als ersten Parameter. Flask.__init_subclass__ erkennt Überschreibungen im alten Stil und warnt (src/flask/app.py:261-306).
Die Liste dieser zwölf Methoden und die genaue Regel, was als neue Signatur gilt, stehen nur im Quelltext. Die Doku hat zwei deprecated:: 3.2-Hinweise (docs/api.rst:309-316) und keine Migrationsseite.
docs/shell.rst erklärt noch, wie man einen RequestContext baut und push()/pop() aufruft, also genau die API, die jetzt ein veralteter Alias ist.
3.2.0 ist noch nicht veröffentlicht. Und viele Test-Suites von Erweiterungen behandeln Warnungen als Fehler, wie Flasks eigene, sodass eine undokumentierte Deprecation am Upgrade-Tag als roter CI-Lauf ankommt.

Zwei Alternativen hat er mit Begründung verworfen: das eine offene Issue zu beantworten (eine Hosting-Anbieter-Liste, eine Grundsatzfrage für die Maintainer) und die Entfernung in 4.0 zu planen (verfrüht, solange der Migrationsweg nicht dokumentiert ist).

Außerdem stellte er dem Team eine berechtigte Frage, statt sie selbst zu beantworten: redirect liefert jetzt standardmäßig 303 statt 302 (CHANGES.rst:22-26), ohne Deprecation-Warnung. Flasks Changelog begründet, dass sich GET und POST wie bisher verhalten. Die Spannung besteht nur zu einer Regel, die unser fiktives Team in seine Constitution geschrieben hat („erst deprecaten, dann Verhalten ändern"). Genau so etwas sollte ein Product Owner denen vorlegen, die entscheiden.

Die Spur, die nicht hielt

Der Product Owner ergänzte einen Nebenhinweis: __init_subclass__ ruft setattr(Flask, …) auf, also wird die Basisklasse gepatcht, sobald irgendeine Unterklasse eine alte Signatur verwendet, was „andere Unterklassen beeinflussen könnte". Das klingt nach einem Bug.

Wir haben den Code gelesen. Es ist keiner. Der Ersatz-Wrapper add_ctx (src/flask/app.py:98-107) fügt den Kontext nur ein, wenn er im Aufruf fehlt; Aufrufe, die ihn schon mitgeben, laufen unverändert durch. Das Patchen der Basisklasse ist Absicht, damit eine Überschreibung im alten Stil, die super() ohne Kontext aufruft, weiter funktioniert. Unterklassen im neuen Stil merken keinen Unterschied.

Das veröffentlichen wir mit Absicht. Ein Agent, der Code schnell liest, liest ihn manchmal falsch, und er klingt dabei überzeugt. Genau deshalb endet jede aSPARK-Phase an einem Gate, über das ein Mensch entscheidet, und deshalb wurde jede Aussage in diesem Beitrag vor der Veröffentlichung am Quelltext geprüft.

Was das zeigt, und was nicht

Es zeigt, dass /charter in Minuten ein Bild einer fremden, ausgereiften Codebasis erstellen kann, mit überprüfbaren Quellen statt mit Eindrücken.
Es zeigt nicht, dass die Flask-Maintainer genau diesen Leitfaden wollen. Sie kennen ihre Roadmap; wir haben eine Momentaufnahme gelesen.
Die Produktantworten stammen von uns als fiktivem Team. Profil und Constitution haben wir bestätigt, nicht Pallets.
aspark-graph hat Flasks Python-Imports gut aufgelöst. Auf den zwei anderen Repositories, die wir vor Flask ausprobiert haben, Express (CommonJS-require) und ripgrep (Rust-use-Pfade), löste er fast keine auf. Die nächsten Folgen wählen Projekte, bei denen das weniger ins Gewicht fällt, und die Lücke kommt ins Backlog des Graphen.

Als Nächstes in der Serie: ein weiteres bekanntes Repository, gleiches Vorgehen, gleicher Faktencheck. Wenn Sie ein Projekt betreuen und möchten, dass wir aSPARK darauf laufen lassen (oder eben nicht), sagen Sie es uns.