Skip to content

Cleanup aus dem Framework-Review: CapabilitiesView raus, __version__ aus Metadaten, CHANGELOG konsolidiert - #18

Merged
rrolf merged 1 commit into
mainfrom
chore/review-cleanup
Oct 2, 2026
Merged

rrolf merged 1 commit into
mainfrom
chore/review-cleanup

Conversation

@rrolf

@rrolf rrolf commented Oct 2, 2026

Copy link
Copy Markdown
Contributor

Was

Letzter PR der Review-Serie (#13 Security, #14/#17 Template, #15 ui, #16 auth):

  • basicbar-integrations 0.3.0 — CapabilitiesView entfernt. Kein Tool hat GET /api/capabilities/ je aufgerufen (grep über alle vier Tools und das Template: null Treffer); alle mischen die Flags in ihr whoami. Dafür capabilities.capabilities_payload() mit genau den drei Schlüsseln, die die Tools heute von Hand zusammensetzen (ai_enabled, content_default_language, content_translation_enabled). basicbar_integrations.urls enthält nur noch translate/. Tests umgestellt (Payload statt Endpunkt, 404-Test für die alte URL).
  • __version__ via importlib.metadata in allen drei Django-Paketen (auth 0.2.1, lti 0.1.5, integrations 0.3.0) — die Strings drifteten im Review auseinander; Single Source ist jetzt pyproject.toml, ein nicht installierter Checkout meldet 0.0.0.dev0.
  • CHANGELOG konsolidiert: 17 längst getaggte Releases standen unter „[Unreleased] (→ wird …)“. Jetzt je ein datierter ## <tag> — <datum>-Abschnitt (Daten aus den Tags), die Template-Änderungen als eigener datierter Abschnitt, chronologisch sortiert. Inhalte unverändert.
  • Doku-Drift: README-Paket-Tabelle ohne die Versionsspalte (stand auf Juli-Ständen; Verweis auf Tags/CHANGELOG), Beschreibungen aktualisiert; Capabilities-Endpunkt in CLAUDE.md und EXTRAKTIONSPLAN (Entscheidung 2 + Phase-2-Notiz) bereinigt.

Bewusst nicht angefasst: die @basicbar/ui-Exporte ohne Tool-Nutzer (prePaintScript, useTranslationForm, MAX_TRANSLATE_LENGTH, Typen) — dokumentierte API, Entfernen brächte nichts; die validate() im lti-LtiPlatformSerializer (dupliziert zwar den UniqueConstraint, liefert aber die deutsche Fehlermeldung); das Template nutzt capabilities_payload() erst mit dem nächsten Pin-Bump (die Template-CI installiert vom Tag).

Verifiziert

Alle drei Paket-Suiten grün (im Container, aus dem nackten Checkout); __version__ geprüft: uninstalliert 0.0.0.dev0, nach pip install 0.3.0 / 0.2.1 / 0.1.5.

Danach

Tags integrations/v0.3.0, auth/v0.2.1, lti/v0.1.5 auf den main-Commit. Konsumenten-Bumps sind optional (keine Verhaltensänderung außer dem toten Endpunkt) — sinnvoll beim nächsten ohnehin anstehenden Bump, dann mit capabilities_payload() im whoami.

🤖 Generated with Claude Code

…rsion__ aus Metadaten, CHANGELOG konsolidiert

basicbar-integrations 0.3.0: CapabilitiesView/`capabilities/` entfernt (kein
Tool hat den Endpunkt je aufgerufen); stattdessen
capabilities.capabilities_payload() mit den drei Schlüsseln, die alle vier
Tools heute von Hand in ihr whoami mischen.

Alle Django-Pakete (auth 0.2.1, lti 0.1.5, integrations 0.3.0): __version__
via importlib.metadata statt eines zweiten handgepflegten Strings.

CHANGELOG: 17 längst getaggte Releases standen unter "[Unreleased] (→ wird
…)" — jetzt je ein datierter Abschnitt pro Tag (Daten aus den Tags).
README-Paket-Tabelle ohne veraltete Versionsspalte; Doku-Drift zum
Capabilities-Endpunkt in CLAUDE.md und EXTRAKTIONSPLAN bereinigt.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@rrolf
rrolf merged commit 4620aae into main Oct 2, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant