01 · A
Problem
Karriereabläufe verbinden nicht vertrauenswürdige Webseiten, persönliche Dokumente, Modellausgaben und lange Tasks. Eine reine Chat-Architektur würde Fehler, Herkunft und folgenreiche Schreibvorgänge verdecken.
Alle Projekte09 / 09
Verlässlicher Workflow vor autonomem Agenten
AI-Karriere-Workflow-Plattform
Ein typisiertes Monorepo für strukturierte Stellendaten, Lebenslauf-Ingestion und beobachtbare Hintergrundarbeit mit klaren Sicherheits- und Berechtigungsgrenzen.
- Zeitraum
- 2026 — present
- Schwerpunkt
- Full-stack AI · Async Systems · Security Engineering
- Kerntechnologien
- Next.js · tRPC · Zod · Prisma
Kurzfassung
- Problem
- Karriereabläufe verbinden nicht vertrauenswürdige Webseiten, persönliche Dokumente, Modellausgaben und lange Tasks. Eine reine Chat-Architektur würde Fehler, Herkunft und folgenreiche Schreibvorgänge verdecken.
- Mein Beitrag
- Stellenimport, editierbare Datensätze, Lebenslauf-Upload und asynchrone Textextraktion mit persistentem Status umgesetzt.
- Ergebnis / Grenze
- Interview-, Wissensscan- und Match-Report-Prozessoren sowie vollständiges Tool Calling und RAG bleiben explizit außerhalb des implementierten Umfangs.
01 · B
Kontext
Die aktuelle Plattform teilt ein TypeScript-Monorepo in Next.js-Webanwendung, tRPC/Zod-Verträge, Prisma-Persistenz, BullMQ/Redis-Worker und isolierten Crawler.
Ablaufillustration
Beobachtbare Arbeit vor autonomem Verhalten
Mit dieser Ablaufillustration mache ich Taskzustand, URL-Prüfungen, Lebenslaufversionen und das Review-vor-Commit-Gate an einem Ort nachvollziehbar.
Warum es wichtig ist
Karrieredaten sind persönlich und Statusänderungen folgenreich. Typisierte Verträge, dauerhafter Taskstatus und explizite Autorisierung machen Fehler diagnostizierbar und begrenzen den Assistenten auf die Nutzerabsicht.
Technische Details öffnenDie eigentliche Schwierigkeit · Systempfad · Zentrale Abwägungen
Die eigentliche Schwierigkeit
- 01
URL-Importe müssen unsichere Protokolle, interne Ziele, Redirects und übergroße Antworten ablehnen.
- 02
Modellgenerierte Stellendaten müssen vor Persistenz ein Schema erfüllen.
- 03
Lange Aufgaben brauchen dauerhaften Zustand und klare Fehlerberichte.
- 04
Entwicklungsidentität und SQLite sind keine Produktionsauthentifizierung oder -speicherung.
Grenze für nicht vertrauenswürdige URLs
Eine Stellen-URL ist zu validierende Eingabe, keine beliebige Abrufberechtigung
Jeder Redirect und jedes aufgelöste Ziel muss Netzwerk- und Ressourcengrenzen erfüllen, bevor Inhalte zu einem strukturierten Datensatz werden.
01Eingabe
Eingereichte URL
Seite und Redirects als untrusted behandeln
02Netzwerk-Gate
Schema + DNS
Unsichere Protokolle und interne Ziele ablehnen
03Ressourcen-Gate
Redirect + Limits
Hops, Timeout und Größe erneut prüfen
04Schema-Gate
Strukturierte Extraktion
Provider-Ausgabe muss Zod erfüllen
05Commit-Gate
Prüfen + speichern
Bestätigte Daten werden Geschäftszustand
Mein Ansatz
Systempfad
Erfassen
Stellenseiten und Lebensläufe über begrenzte Schnittstellen importieren
Validieren
tRPC/Zod-Verträge vor Übernahme in den Geschäftszustand anwenden
Verarbeiten
Crawler und BullMQ-Worker mit persistentem TaskRun-Status ausführen
Prüfen
Editierbare Datensätze, Bewerbungsstatus und Fehler sichtbar machen
Dauerhafter Task-Lebenszyklus
Die Queue startet Arbeit; TaskRun hält ihren Zustand fest
Persistierter Status lässt die Webanwendung Warten, Fortschritt und Fehler erklären, auch wenn der Worker in einem anderen Prozess läuft.
01dauerhaft
Queued
Taskdatensatz existiert vor Arbeitsbeginn
02beobachtbar
Running
Worker übernimmt und meldet Fortschritt
03terminal
Completed
Validiertes Ergebnis wird angehängt
04diagnostizierbar
Failed
Fehlergrund bleibt abfragbar
05explizit
Retry / Review
Kontrollierte Entscheidung startet neuen Versuch
Zentrale Abwägungen
Taskzustand persistieren
Queue-Nachrichten starten Arbeit; TaskRun bleibt der abfragbare Statusdatensatz.
URL-Abruf isolieren
Crawler-Kontrollen halten untrusted Fetching aus dem Hauptprozess und prüfen Grenzen.
Verträge vor Intelligenz
Provider-Ausgaben werden erst nach Schemavalidierung zu Anwendungsdaten.
04 · A
Mein Beitrag
- Stellenimport, editierbare Datensätze, Lebenslauf-Upload und asynchrone Textextraktion mit persistentem Status umgesetzt.
- SSRF-, DNS/Redirect-, Timeout- und Größenkontrollen sowie Schemavalidierung ergänzt.
- Eine prozessübergreifende Queue-/Datenbankabweichung diagnostiziert und kontrollierte Integrationsverträge definiert.
04 · B
Umgesetzte Ergebnisse
- Quellcodebelegte Stellen-, Bewerbungs-, Lebenslauf- und Taskdatenflüsse sowie funktionierende Crawler-/Lebenslaufprozessoren umgesetzt.
- Interview-, Wissensscan- und Match-Report-Prozessoren sowie vollständiges Tool Calling und RAG bleiben explizit außerhalb des implementierten Umfangs.
Erkenntnisse
01Agentenprodukte beginnen mit prüfbarem Zustand, begrenzter Autorität und deterministischen Schreibvorgängen—nicht mit mehr Tools.
02Asynchrone Architektur lohnt sich nur bei sichtbaren Zuständen, Wiederholungen und Fehlern.
Was ich öffentlich teilen kann
Ich entwickle diese Plattform rund um Monorepo-Grenzen, Datenflüsse, strukturierte Stellenextraktion, kontrollierten URL-Abruf und asynchrone Lebenslaufverarbeitung. Sie ist ein Prototyp: Identität und SQLite-Persistenz sind entwicklungsorientiert, mehrere Agent/RAG-Prozessoren sind noch in Arbeit.
Öffentliche Quellen