Was ich gebaut habe

Lernplattform in Produktionsqualität, end-to-end unter einem Agent-Roster gebaut. Ich war Product Owner, Business-Vertretung und Content-Reviewer; das Roster hat Curriculum, Plattform und Begleit-Agent geschrieben.

Content-Authoring als Produktionssystem.

• Achtzehnwöchiges, strukturiertes Curriculum, von Grund auf von einem Roster rollenspezialisierter Agenten geschrieben — Curriculum-Design, Pädagogik, Plattform-Engineering — jeder mit einem schriftlichen Profil und einem klar abgegrenzten Mandat.
• Dieselbe Hire-through-one-Channel-, Propose-with-Reasoning- und Scope-Boundary-Disziplin wie ein menschliches Team.
• Resultat: 126 Tagesmodule, Mini-Projekte an den Wendepunkten Woche 3 und Woche 12, Free-Tier-Only-Constraint zur Design-Zeit verankert, DE-primär mit einem EN-Mirror.

Die manuelle Testlücke mit einem Simulated-Learner-Agenten geschlossen. Standard-„alles reviewen“-Prompts verfehlten echte Nutzerreibung — Content-Video-Diskrepanzen, unvollständige EN-Übersetzungen, nicht eingeführte Voraussetzungen. Der Fix: ein Simulated-Learner-Agent mit fixer Persona (Schweizer HR-Direktorin, Mitte vierzig, ohne Programmierhintergrund, ChatGPT auf dem Niveau „schreib mir diese E-Mail um“).

• Geht das Curriculum Tag für Tag durch wie eine Anfängerin; markiert jeden Begriff, der vor seiner Einführung verwendet wird; routet jeden Reibungspunkt an die richtige Spezialistin (Content → Curriculum-Agent, Pacing/Ton → Pädagogik, defekte Links → Plattform-Engineer).
• Jeder Durchgang ist eine frische Instanz, die nur das kumulierte Wissensprofil der Vortage mitträgt — keine Erinnerung an die letzte Kritik, sodass unbehobene Reibung erneut gefunden wird. Die Schleife läuft, bis ein Durchgang leer zurückkommt, dann wird der Tag eingefroren.
• Als ausführbares Orchestrator-Skill kodiert (dispatchen → Verdict → routen → überarbeiten → frischer Pass → validieren → committen → nächster Tag). Über alle 126 Tage gelaufen.

Eine Hälfte davon, wie ich die manuelle Testlücke über den Cluster geschlossen habe; das Test-Framework und die agentenausführbare Harness auf Racket Book sind die andere.

Plattform.

• Next.js 15 App Router, serverseitige Authentifizierung, Progress-Tracking pro Nutzer, Gamification (XP, Badges, Streaks), Offline-fähiger Service Worker, Admin-Progress-View, Multi-Device-Sync.
• Dediziertes Postgres mit Row-Level Security, Raw-SQL-Migrationsleiter über einen separaten Migrator-Container.
• In-Site-Begleit-Agent mit eigenen API-Routen und einem schriftlichen Motivations-Playbook.
• Ursprünglich auf eigener VPS plus Managed Database; später auf die Application-Plattform migriert — siehe Keystone — um die Kostenlinie zu senken.

Scope-Entwicklung. Entworfen und ausgeliefert für eine einzige primäre Nutzerin; die Multi-User-Shape kam, als der Nutzerkreis wuchs. Heute eine Live-Kohorte, zehn-plus onboardete Nutzer.

Die Plattform unter dem Rest des Build-Clusters.

Harte Entscheidung — auf der Substrat-Ebene mitigieren, nicht auf der Projektebene. Die Kostenlinie ist beim dritten Projekt gerissen. Billige Lösung: jede App-Rechnung einzeln drücken. Die Entscheidung unter Constraint: drei separat abgerechnete Stacks auf einen geteilten Host mit Per-Tenant-Contract zusammenführen, sodass der nächste Tenant die Einsparung umsonst erbt, statt das Kostenproblem noch dreimal neu zu lösen. Genau das hat aus dem Ganzen eine Plattform gemacht statt eines einmaligen Kostenschnitts.

Der Kostenfall. Vor der Migration CHF 76–86/Monat — drei Supabase-Pro-Projekte (~CHF 40), GitLab Premium (~CHF 26, für Small-Team-CI gehalten), zwei Per-App-VPS (CHF 10–20). Nach der Migration rund CHF 18/Monat — ein Hetzner-Host (CHF 14.50) plus 1 TB Backup (CHF 3.10). Einsparung CHF 58–68/Monat. Das Premium-Abo wurde rückerstattet — der selbst gehostete Runner machte seine CI-Features überflüssig.

Die Disziplin. Die Agent-Oberfläche erlaubt es, den Cluster ganzheitlich zu betrachten — ein Infrastruktur-Problem mit einer Mitigations-Form, nicht N Anwendungsrechnungen. Re-Architektur mit dem Roster geplant, Steady-State modelliert, ausgeführt. Substrat-Entscheidungen, Kostenmodellierung und Infrastrukturplanung gehören in dieselbe operative Hülle wie der Anwendungscode.

In der Öffentlichkeit publizieren. Das Repository, dessen Inhalt Sie gerade lesen, ist ein kuratierter öffentlicher Snapshot, nicht die operative Live-Historie. Jedes Release läuft durch zwei klar abgegrenzte Tools: einen Security-Sweep, der die Veröffentlichungsreife prüft (Secrets, Infrastruktur, operative Details), und einen Publish-Snapshot-Schritt, der den release-getaggten Stand zu einem einzigen Commit auf dem öffentlichen Mirror zusammenfasst, die Deploy-CI entfernt und ein Vorwort voranstellt. Die Ein-Commit-Historie ist bewusst so.

Plattform-Contract pro Tenant.

• Jeder Tenant: zugewiesener Port, UID, GitLab-Slug, Caddy-Snippet, das <tenant>.wagen.io plus <tenant>-test.wagen.io an das Host-Loopback bindet; Postgres-Rolle pro Tenant mit RLS, optionalem Realtime-Channel.
• Onboarding und Deploys laufen über separate skriptbasierte Contracts. Tenants halten sich an ${PORT}-Listen plus /healthz mit 200 ok plus die zugewiesene UID. Der Contract ist in jedem Tenant-Repo benannt, damit die Apps portabel bleiben.

Plattform-Internals.

• Bootstrap, Härtung, Ingress, Shared Postgres, Monitoring, Backups, selbst gehosteter CI-Runner, geplante Cron-Timer — jeweils ein nummeriertes idempotentes Skript, das sicher gegen einen bestehenden Host re-run werden kann.
• CI-Lint-Gates bei der Tenant-Promotion, Disk-Garbage-Collection, nächtliche Backups auf eine separate Storage-Box.

Tenants. AI Learning Journey und Courtside Desk von Per-App-VPS migriert; Racket Book war der erste von Grund auf neu aufgesetzte Tenant gegen den Contract aus einer sauberen Codebase; diese Site läuft ebenfalls auf der Plattform. Jede Migration hat die Plattform verbessert; jede Verbesserung hat den nächsten Tenant sauberer gemacht.

Management-Tool. Ein kleines Begleit-Tool für Tenant-Onboarding und operative Aufgaben, das dieselben Contracts in einer brauchbaren Form an die Oberfläche bringt.

Erstes Projekt des Build-Clusters. Zwölf Monate zuvor hatte ich eine einfache Python-Version ausgeliefert — rund zehn Prozent der Funktionalität, die ich im Sinn hatte. Der Neustart unter einem Agent-Roster hat die operative Form verändert.

Domain-Expertise war der Input.

• Jahrelang Tennisturniere als Vereinsfunktionär organisiert; seit 2018 kompetitiver Spieler. Ich kenne die Formate, die Tableau-Formen, den Ablauf am Turniertag und wo bestehende Tools versagen.
• Das Roster musste kein Tennis lernen — es musste eine auslieferbare Spezifikation aus mir extrahieren.

BA- und Architect-Agenten haben den Scope herausgezogen.

• Die Schleife, die ich heute auf jedem Projekt fahre: das Ziel beschreiben, den BA-Agenten die Anforderungen herausfordern lassen, den Architect die Form des Systems herausfordern lassen, dagegenhalten, wo es nicht trägt, akzeptieren, wo es trägt.
• Die Reibung ist die Arbeit — eine „tragende“ Anforderung ist es nicht; eine „offensichtliche“ Journey braucht drei weitere Screens; ein übersehenes Constraint treibt das Modell. Wer die Schleife überspringt, baut das Falsche.

Harte Entscheidung — die Scoring-Domain brauchte Iteration, keinen einzigen Wurf.

• Tragendes Designproblem: das Scoring-Modell — mehrere Match-Formate und die jeweilige Tiebreak-Logik. Nicht beim ersten Durchgang gelandet.
• Eine für offensichtlich gehaltene Format-Regel unterspezifizierte den Tiebreak; ein Sonderfall, den ich als Turnierleiter nie hatte aufschreiben müssen, zwang zu einem Rebuild um ihn herum. Wurde ein eigenes geteiltes TypeScript-Paket — der Teil, der stimmen musste, bevor irgendetwas darüber tragen konnte.

Stack vom Architect-Agenten gewählt, nicht von mir.

• Unter Constraints (Free-Tier-Substrat wo möglich, modernes Frontend, type-safe geteilte Domain) um einen Architektur- und Deployment-Vorschlag gebeten. Geprüft und freigegeben.
• Turborepo-Monorepo, Next.js-15-App-Router-Frontend, Hono- plus tRPC-API im selben Next.js-Prozess, drei geteilte TypeScript-Pakete (Scoring-Domain, Datenbankschema, tRPC-Router-Definitionen).

Status. Substanzielle, reale Arbeit, deployt auf der Application-Plattform (siehe Keystone — einer der zwei Tenants, die in der Kosten-Re-Architektur von einer dedizierten VPS migriert wurden). Weiter in aktiver Entwicklung.

Serverseitig gerenderte FastAPI-App für den Arbeitsloop einer Bespannerin oder eines Bespanners: Kunden, Racket, Bespannungsaufträge, Zahlungen, Historie. Beide Seiten der Stringer-/Kundenbeziehung sitzen auf demselben Datensatz — die operative Sicht und die kundenseitige Oberfläche.

Status. ~80 % gebaut, in aktiver Entwicklung, noch nicht produktiv.

Wo sie sitzt. Greenfield zu dem Zeitpunkt, als die Application-Plattform stand — siehe den Keystone-Eintrag — und damit der natürliche erste von Grund auf neu aufgesetzte Tenant: kein Migrations-Gepäck, der Deploy-Contract (Port, UID, Healthcheck, Datenbankrolle, CI) ab dem ersten Commit gegen eine saubere Codebase aufgebaut.

Testing — wo die manuelle Testlücke geschlossen wurde.

• Echtes Test-Framework: pytest mit pytest-asyncio, ~1’138 Test-Funktionen über 94 Dateien. Real-Postgres-Fixtures (keine Mocks), transaktionale Isolation pro Test, Enumeration von Tenancy-Regressionen.
• Agentengeschriebene Walkthrough-Harness (.claude/skills/walkthrough): Die Agenten leiten die zu testenden Workflows selbst aus Anforderungen und Spezifikation ab — keinen davon habe ich geschrieben. Modus A: In-Process-ASGI gegen den Working Tree, Modus B: Playwright-Browser gegen das deployte Environment. Prüft strukturelle Invarianten — Locale-Bindung, Auth-Header auf jeder authentifizierten Seite, HTMX-Fragment-Korrektheit, keine toten Links.
• Playwright-E2E-Suite, CI-gated: Der E2E-Job gated die Prod-Deploys.

Wo die anderen Einträge Web-Apps sind, die über ein Code-Authoring-Roster dispatcht werden, fährt dieses hier dieselbe Disziplin über ein Chat-Interface: Die Eingangstür ist Telegram, ein Operating-Model-Roster ist die Engine, persistenter Per-Role-State ist das Substrat.

Architektur.

• Python-systemd-Unit auf einem Home-Ubuntu-Host. Ein Telegram-Bot pro Rolle; pro eingehender Nachricht ein Claude-Code-Subprozess mit der passenden Rolle gespawnt.
• Filesystem-Contract pro Rolle: inbox/, outbox/, attachments/, state/<domain>/ für langlebigen Kontext, archive/ monatsweise bucket-isiert.
• Rollenprofile leben als Source-of-Truth-Markdown, über einen Pre-Commit-Hook in die Agent-Runtime-Form kompiliert, sodass Source und Runtime nie auseinanderdriften.

Operating Model.

• Eine Rolle orchestriert Anfragen, fährt geplante Digests, besitzt das Backlog. Eine separate Rolle entwirft neue Rollen — dieselbe Hire-through-one-Channel-Disziplin wie der Rest des Clusters.
• Spezialisten-Rollen für Systems-Arbeit, Scheduling und weitere Domänen, jede mit eigener Scope-Grenze und eigenem Tonprofil. Keine Cross-Role-Writes auf Internals.

Fähigkeiten.

• Geplante Jobs: Morgen-Digest, Wochen-Review, Flight-Watch mit steckbaren Providern, Kalender-Sync, Zeitzonen-Resync nach Reisen.
• Sprachantworten über eine TTS-Schicht mit Provider-Abstraktion und Voice-Profil pro Rolle; Bildgenerierung über mehrere Provider.
• Async-Dispatch-Tracing, Idle-Mode-Handling, Latenz-Reporting — jeweils als separates instrumentiertes Modul.

Älter als die meisten anderen; dieselbe Operating-Model-Disziplin über ein Chat-Interface statt über eine Web-App. Die Architektur ist das Artefakt; die persönlichen Inhalte bleiben privat. Kein Repository-Link aus diesem Grund — der Text trägt den Scope.

Die Site, die die Cluster-Schleife schliesst — auf der Application-Plattform gebaut, sobald sie stand, die Oberfläche, die den Rest des Clusters für eine Leserin lesbar macht.

End-to-end von einem Agent-Roster geschrieben.

• Der Career-Editor hat die CV-Bullets geschrieben; der Frontend-Engineer hat Layout und Rendering-Regeln geformt; der Portfolio-Curator hat diese Einträge geschrieben; der Orchestrator dispatcht und synthetisiert; die HR-Rolle ist die einzige Rolle, die neue Rollen entwerfen darf.
• Jeder Agent hat ein schriftliches Profil in team/ — Rolle, Reportinglinie, Scope-Grenzen, Operating-Instructions, Anti-Patterns, Eskalation. Die Profile lesen sich wie Arbeitsverträge. Ich reviewe und gebe frei; die Roster bauen.

Architektur.

• Astro-5-Static-Site, Tailwind v4 mit CSS-Variable-Theme-Tokens, MDX-Content-Collections unter src/content/<section>/<locale>/.
• Per-Locale-Collections sind separate Astro-Collections, nicht eine Collection mit einem Locale-Diskriminator — die Missing-Translation-hides-Regel wird durch den Loader selbst durchgesetzt, nicht durch Filter pro Seite. Das schliesst die Fehlerklasse aus, bei der ein vergessener Filter EN-Inhalte in die DE-Site lecken lässt.
• Static-first mit einer kleinen serverseitig gerenderten Oberfläche (Kontakt-Endpunkt plus Healthcheck), unter dem Tenant-Contract der Application-Plattform (Port, UID, Healthcheck).

Eine abgeschlossene dreirundige Übung gegen das Agent-Roster — Runde 1 am 2026-05-16, Runde 2 und 3 am 2026-05-29. Die Frage: Wie liest sich dieses CV für einen Hiring Manager, der mich nie getroffen hat, und wie verhält sich dieser Cold Read zur fundierten Sicht der Inside-Editorin? Die Wiederholungen machten daraus ein Instrument — in jeder Runde habe ich genau eine Sache geändert, die der Cold Reader verlangt hatte, alles andere konstant gehalten und erneut laufen lassen, um zu sehen, ob sich das Verdict bewegt.

Setup.

• Roster: Orchestrator, Career-Editorin, HR-/Rollen-Scoping, Frontend-Engineer, Portfolio-Kurator und — hier ergänzt — eine Hiring-seitige CV-Screening-Rolle. HR entwarf das Profil, der Orchestrator dispatchte. Jede Wiederholung nutzte eine frische Hiring-seitige Instanz, ohne Erinnerung an die Runde davor.
• Der Cold Reader lief in striktem Blind-/External-Review-Modus. Input-Lock: die öffentliche Site, die öffentlichen Repos, auf die sie verlinkt (/projects repo →-Links), die acht Rollenprofile. Verboten: jedes andere interne Artefakt (Schwesterprofile, Source-Notes, Grounding-Dossier, Personal-Context-Stores, private Repos). Das Deliverable listete die gelesenen Artefakte, sodass ein Modus-Bleed sichtbar gewesen wäre. Er scrapte die Site, schrieb ein Kandidaten-Briefing, bewertete jede Rolle in Bändern (Strong / Plausible / Stretch / No Fit) mit Begründung und schloss mit einem Verdict.
• Acht Rollenprofile, von der Editorin entworfen, um die Next-Rung- Landschaft zu triangulieren — Senior-IC mit KI-Shape, EM, Director-lastig, über Financial Services und Big-Tech, überwiegend Zürich-verankert, eines Singapur-geformt, eines EU-remote. Nur Archetypen. Bewusst breiter als das kalibrierte Publikum des CVs. Über alle drei Runden konstant gehalten — das ist die Kontrolle.

Runde 1. Zwei Strong Fits (die Wealth-Management-EM-Shapes, auf die das CV kalibriert ist); drei Stretches auf den Senior-IC-Agentic-Rollen, alle an einer Sache hängend — kein extern verifizierbares KI-Build-Artefakt auf der Site; zwei Stretches auf Director-lastiger Ebene (die Manager-of-Managers-Tour, die das CV nicht zeigt); ein No Fit (eine tech-native Platform-Org-Director-Rolle, deren Substrat-Sprache nicht transferiert). Edit mit dem grössten Hebel: ein öffentlicher Link vom KI-Build-Cluster zum ausgelieferten Code.

Zwischen den Runden. Vier Cluster-Repos als kuratierte öffentliche Snapshots publiziert; die /projects-Karten erhielten repo →-Links. Genau die Edit, die Runde 1 benannte.

Runde 2. Der frische Reader folgte den Links und las die Repos. Bei Runde 1s Frage — existiert ein verifizierbares Artefakt? — kippte die Antwort: Der Cluster las sich als reale, ausgelieferte, offen lizenzierte Arbeit. Und dennoch hielten die Senior-IC-Rollen auf Stretch. Der Reader ging an der Existenz vorbei zu wie lange existiert die Arbeit schon? — die Mirrors sind einzelne Squash-Snapshot-Commits (Publikations-Hygiene, nicht Historie), sodass der Build sich Monate alt liest, nicht Jahre, und der Senior-IC-Massstab hängt an nachhaltiger Time-on-Task. Die EM-Shapes hielten am stärksten; die Director-Rollen als ehrliche Stretches; die tech-native Rolle als schwächster Transfer. Dieselbe Lücke, eine Schicht tiefer. Edit mit dem grössten Hebel: Time-on-Task und Dichte signalisieren (Fensterdauer, Arbeitsdichte), nicht die Entwicklungshistorie. Landete als gesourcte Density-Edit an der Build-Cluster-Copy.

Runde 3. Ein frischer Reader liess die acht nach der Density-Edit erneut laufen. Es wirkte — dieser Reader akzeptierte die Dauer als Faktum und stellte sie nicht länger in Frage. Erneut hielten die Senior-IC-Rollen auf Stretch; die Lücke wanderte von wie lange? zu ist die Tiefe inspizierbar? Der Reader wollte nun die Rigorosität im Code gezeigt sehen statt in Prosa behauptet — Eval-Harnesses, Observability, Kosten-Telemetrie, lesbar in den Repos. Der Rest des Gradienten hielt, wobei sich die zwei EM-Shapes zu den stärksten Fits über alle drei Runden verstärkten.

Terminaler Befund. Der Bogen ist eine Lücke, die durch Schichten hinabwandert: Existenz → Dauer → inspizierbare Tiefe. Auf der dritten Schicht ist die Frage nicht mehr durch eine Edit beantwortbar, weil sie nicht mehr von der Oberfläche handelt. Der Build ist tatsächlich erst ein paar Monate alt — seit April 2026 — und persönlich skaliert; ein „2+ Jahre agentisch / ≥50 % Code“-Massstab geht auf Monate von Time-on-Task nicht auf, egal wie inspizierbar. In Runde 3 liest die Oberfläche den Kandidaten korrekt: Der verbleibende Stretch ist keine Lücke im Artefakt, sondern der beabsichtigte Trade-off eines EM-kalibrierten CVs — getunt, die Wealth-Management-EM-Shapes zu treffen, und den Reader auf IC-Fähigkeit schliessen zu lassen, ohne einen Senior-IC-Agentic-Massstab zu beanspruchen, auf den es nie kalibriert war. Dort hält ein Kalibrierungs-Instrument an. Die Übung schliesst hier.

Die Inside-Editorin. Nach jedem Cold Read prüfte die Career-Editorin ihn als Kalibrierungs-Check — die öffentliche Oberfläche gegen ihre fundierte Sicht auf das tatsächliche Ich, nach dem Cold Read, nicht daneben. Verdict in Runde 1: Der Cold Read traf den Inside Read eng, auch bei den Lücken — die Oberfläche unterrepräsentierte drei Dinge (Beleg für Working-Business-Sprache, die Dichte der aktuellen Mehrfachrollen-Last, die externe Verifizierbarkeit des Build-Clusters), und der Reader erwischte alle drei. Eine Lücke, die unter drei kontrollierten Edits zwei saubere Schichten hinabwandert und dann in Design-Absicht aufsetzt, ist ihr stärkster Beleg, dass das Instrument echte Auflösung hat.

Die Modus-Disziplin ist die tragende Naht. Beide Sichten gelten derselben Person; nützlich wird es dadurch, dass eine input-locked ist und die andere nicht. Der Cold Reader sieht die Oberfläche als Oberfläche; die Editorin sieht durch sie hindurch auf den Kandidaten, für den sie schreibt. Die Wiederholungen finden die nächste Schicht derselben Lücke und sagen dir, wann sie keine Fix-Frage mehr ist. Ihre Ein-Zeilen-Zusammenfassung: „Der Cold Reader tut das, was ich nicht kann — er sieht die Oberfläche als Oberfläche.“

Cross-Model-Replikation. Ein self-contained Prompt ist publiziert, für jedes Chat-Modell mit Web-Zugriff (Gemini, ChatGPT, Claude.ai) — gleiche Inputs, gleiche Regeln, gleiche Output-Form. Der Input-Lock lässt die öffentlichen Repos zu, auf die die Site verlinkt, passend zu Runde 2; jede andere Quelle bleibt verboten. Der Inside-Editor-Schritt ist bewusst ausgelassen — ihn ausserhalb des lokalen Rosters zu reproduzieren, würde den Vergleich zunichtemachen. Prompt unter /hiring-calibration-prompt.md; in einen frischen Browsing-Chat kopieren und denselben Blind Read fahren.

Was es ist und was nicht. Ein Kalibrierungs-Instrument für das öffentliche Material eines einzelnen Kandidaten gegen ein definiertes Publikum — kein generisches CV-Bewertungstool, kein Produkt, keine Beratung. Die Disziplin (input-locked Cold Reader gegen einen separaten fundierten Reviewer, als Kontrolle erneut gefahren nach einer benannten Edit) transferiert; das spezifische Roster nicht.

Die Lese-Oberfläche, gepaart mit der Personal-Ops-Bridge. Die Bridge nimmt Eingänge über Telegram auf und schiebt Arbeit in ein Roster auf dem Home-Host; das Dashboard ist die Inversion — eine Web-App, in die die Bridge über eine authentifizierte Ingest-API hineinschreibt und in der kuratierte Streams als zusammenklappbare Karten landen. Nächster Tenant auf der Application-Plattform nach dieser Site.

Status. In aktiver Entwicklung. Aktuell Single-User, noch nicht für Eingeladene geöffnet. Substanzielle Roadmap noch offen.

Architektur-Invarianten.

• Next.js 16 App Router. @supabase/ssr nur für den Auth-Flow; der Datenzugriff geht am Supabase-Client vorbei und läuft über pg mit einer Per-Tenant-Postgres-Rolle, die RLS nicht umgeht. auth.uid() wird über ein request.jwt.claim.sub aufgelöst, das pro Transaktion von einem withUser()-Helper gesetzt wird.
• Postgres-RLS ist der Isolationsmechanismus: Jede nutzerbezogene Tabelle trägt user_id mit einer auth.uid() = user_id-Policy, kein Service-Role-Bypass. Verallgemeinert das Single-then-Multi-User-Muster der Lernplattform auf N familiengrosse Nutzer.
• Einladungsbasiert by Design: keine Sign-up-UI, Sign-up auch auf der Auth-Substrat-Ebene deaktiviert; Nutzer über die gotrue-Admin-API provisioniert.
• Ingest-Auth bewusst einfacher als ein JWT-Austausch: Der Daemon sendet ein 32-Byte-Zufalls-Hex als Bearer-Token; der Server vergleicht dessen SHA-256 gegen den gespeicherten Hash. Tokens über die Settings rotierbar/widerrufbar, optionale Per-User-IP-Allow-Liste in der Middleware, jeder Ingest-Call in api_audit_log auditiert.

Sektionen in v1. Today (Kalender plus Open-Meteo-Wetter), Breaking (ungelesene Items, vom Klassifikator des Curator-Agenten markiert), Feed (themenfilterbar, Pinned-first, drei Sortiermodi), Watchlist (ungesehene Podcasts plus YouTube), Source Approvals (Queue mit Feed-Source-Vorschlägen), Todo (Google-Tasks-Round-trip), Health (Garmin-Tagesaggregate — Sleep, Gewichtsverlauf, Training-Load-TSB). Der eingeklappte Zustand pro Nutzer in user_settings persistiert.

Deployment. Tenant auf der Application-Plattform (siehe Keystone) — Full-Substrate (DB plus per-tenant gotrue), zugewiesener Port und UID. CI baut pro Push zwei Web-Builds (Prod/Test unterscheiden sich beim gotrue-Host, zur Build-Zeit in NEXT_PUBLIC_* inlined); ein Migrator-Image, idempotente SQL-Leiter auf beiden Environments, ein einzelnes manuelles Gate beim Prod-Migrate.

Wo es sitzt. Erste Multi-User-App auf der Plattform, verallgemeinert das RLS-Muster aus der Single-User-Shape der Lernplattform auf N familiengrosse Eingeladene. Roster gescoped und gebaut; ich war Product Owner.