Angebot: PR für openapi.yaml (Jahre bis 2026) und README (statischer XML-Bestand)

Hallo zusammen,

wir haben die Bundeshaushalt-API über alle verfügbaren Jahrgänge hinweg
durchgearbeitet und dabei ein paar Notizen gesammelt, die der Spezifikation
vermutlich helfen. Wir würden das gerne als PR beisteuern statt hier nur eine
Mängelliste abzuladen. Bevor wir etwas schicken, fragen wir lieber, ob euch die
Richtung passt und in welcher Form ihr es pflegen wollt.

Vorab: wir fragen die Quelle sparsam ab, cachen alles lokal und haben für die
Prüfungen unten insgesamt eine Handvoll Requests gebraucht.

## 1. `year`-Enum, wir würden 2022 bis 2026 ergänzen

Geprüft am 09.08.2026:

```bash
curl -s -o /dev/null -w '%{http_code}\n' \
'https://www.bundeshaushalt.de/internalapi/budgetData?year=2026&account=expenses'
# 200
```

Die Antwort trägt `"meta":{"year":2026, ... ,"modifyDate":"23.12.2025"}`.
`year=2011` und `year=2027` liefern 404, der Endpunkt deckt also derzeit 2012
bis 2026 ab. In `openapi.yaml` und `openapi_en.yaml` endet das Enum bei 2021.

Frage an euch: sollen wir die fehlenden Jahre einfach eintragen, oder hättet
ihr lieber ein offenes `type: integer` mit `minimum: 2012`, damit das Enum
nicht jedes Haushaltsjahr nachgezogen werden muss? Wir haben da keine
Präferenz und machen es so, wie es für euch wartbar ist.

## 2. Statischer XML-Bestand, Vorschlag für einen README-Abschnitt

Neben `/internalapi/budgetData` liegt auf demselben Host ein statischer
XML-Bestand, der in README und OpenAPI bisher nicht vorkommt:

```
https://www.bundeshaushalt.de/static/daten/{jahr}/soll/haushalt_{jahr}.xml
https://www.bundeshaushalt.de/static/daten/{jahr}/ist/rechnung_{jahr}.xml
https://www.bundeshaushalt.de/static/daten/{jahr}/soll/draft/regierungsentwurf_{jahr}.xml
https://www.bundeshaushalt.de/static/daten/{jahr}/soll/n{n}/nachtragshaushalt_{jahr}_n{n}.xml
```

Stichproben von heute, jeweils `content-type: application/xml`:
`haushalt_2026.xml` 200 mit 1.333.335 Bytes, `rechnung_2024.xml` 200 mit
2.181.053 Bytes, `regierungsentwurf_2026.xml` 200, `nachtragshaushalt_2020_n1.xml`
200. Nicht jede Kombination existiert, `nachtragshaushalt_2026_n1.xml` liefert
zum Beispiel 404.

Interessant ist die Granularität: `haushalt_2026.xml` enthält geparst 26
``, 234 `` und 6995 `` mit ``-Werten. Das ist
die Titelebene, die die JSON-Antwort so nicht ausgibt.

Vorschlag: ein kurzer Abschnitt in `README.md` und `README_en.md`, der das
Pfadmuster dokumentiert, samt deutlichem Hinweis, dass das kein zugesicherter
Endpunkt ist und sich jederzeit ändern kann. In die `openapi.yaml` würden wir
es nur aufnehmen, wenn ihr das ausdrücklich wollt, sonst bläht es die Spec
unnötig auf. Sagt uns gerne, was euch lieber ist.

## 3. Kleinigkeit: `detail` statt `details`

Die Live-Antwort hat als Top-Level-Keys `meta`, `detail`, `children`, bei einer
`id`-Abfrage zusätzlich `parents`. Das Schema `BudgetDataResponse` nennt das
Feld `details`. Im Detailobjekt tauchen außerdem `tableLabel` und
`selectionLabel` auf, die im Schema fehlen. Sollen wir das im selben PR
mitziehen oder lieber getrennt halten?

## 4. Nur als Hinweis, kein PR möglich: bundeshaushalt.api.bund.dev

```
dig +short bundeshaushalt.api.bund.dev CNAME # bundesapi.github.io.
curl -I https://bundeshaushalt.api.bund.dev/
# subject: CN=*.github.io
# curl: (60) subjectAltName does not match host name
curl -sk -o /dev/null -w '%{http_code}\n' https://bundeshaushalt.api.bund.dev/ # 404
```

Am CNAME liegt es nicht, `smard.api.bund.dev` und `autobahn.api.bund.dev` haben
dasselbe Ziel und funktionieren mit korrektem Zertifikat. Die GitHub-API meldet
für dieses Repo `"has_pages": false`, GitHub Pages scheint hier also nie
aktiviert worden zu sein, obwohl `CNAME` und `index.html` im Repo liegen.
Das lässt sich nur in den Repo-Settings umlegen, per PR kommen wir da nicht
ran. Eilig ist es nicht, api.bund.dev verlinkt für dieses Projekt aktuell die
rohe `openapi.yaml` und nicht die Subdomain. Wollt ihr Pages überhaupt an
haben, oder ist die Subdomain bewusst inaktiv? Dann würden wir es einfach so
lassen.

## Woher die Prüfung kommt

Wir haben die API als Datenquelle für den KI-Haushaltsmonitor genutzt, der alle
13 Jahrgänge und 9 offizielle Revisionsstände durchspielt:
https://i6eal.de/tools/ki-haushaltsmonitor/ . Dabei sind die Punkte oben
aufgefallen, deshalb der Bericht mit konkreten Befehlen statt bloßer Behauptung.

## Lizenz

Für beigesteuertes YAML: Lizenz noch zu klären. Sagt uns, unter welcher Lizenz
Beiträge hier laufen sollen, dann richten wir uns danach.

Sagt einfach kurz, welche der vier Punkte ihr im PR haben wollt und in welcher
Form, dann bauen wir genau das. Wenn euch gerade etwas anderes wichtiger ist
oder ihr das lieber selbst macht, ist das auch völlig in Ordnung.

Start by reading openapi.yaml, openapi_en.yaml, README.md, and README_en.md, then compare the documented response schema with the reported live responses and endpoint behavior. Before editing, get a maintainer decision on which of the four proposals and licensing approach are in scope; done means the selected documentation and specification updates are consistent and include the requested README warning.

Written by the indexing model from the issue text.