01 · A
Problem
Career workflows mix untrusted web pages, personal documents, model output and long-running tasks. A chat-only architecture would hide failure states, provenance and consequential writes.
All projects09 / 09
Reliable workflow before autonomous agent
AI Career Workflow Platform
A typed monorepo for structured job data, resume ingestion and observable background work, with explicit security and authorization boundaries.
- Period
- 2026 — present
- Focus
- Full-stack AI · Async Systems · Security Engineering
- Core stack
- Next.js · tRPC · Zod · Prisma
TL;DR
- Problem
- Career workflows mix untrusted web pages, personal documents, model output and long-running tasks. A chat-only architecture would hide failure states, provenance and consequential writes.
- What I did
- Implemented job import, editable structured records, resume upload and asynchronous text extraction with persisted status.
- Result / limit
- Kept interview, knowledge-scan and match-report processors, full tool calling and RAG explicitly outside the implemented scope.
01 · B
Context
The current platform divides a TypeScript monorepo into a Next.js web app, tRPC/Zod contracts, Prisma persistence, BullMQ/Redis workers and an isolated crawler service.
Workflow illustration
Observable work before autonomous behavior
I use this workflow illustration to make task state, URL checks, resume versions and the review-before-commit gate legible in one place.
Why it matters
Career data is personal and application state is consequential. Typed contracts, durable task status and explicit authorization keep failures diagnosable and prevent an assistant from silently acting beyond user intent.
Explore technical detailsWhat made it hard · System path · Key trade-offs
What made it hard
- 01
Public URL imports must reject unsafe schemes, private targets, dangerous redirects and oversized responses.
- 02
Model-produced job data must pass a schema before persistence.
- 03
Long-running work needs durable state and explicit failure reporting.
- 04
Current development identity and SQLite persistence are not production authentication or storage.
Untrusted URL boundary
A job URL is input to validate, not permission to fetch anything
Every redirect and resolved target stays inside resource and network rules before content can become a structured record.
01input
Submitted URL
Treat page and redirects as untrusted
02network gate
Scheme + DNS
Reject unsafe protocols and private targets
03resource gate
Redirect + limits
Revalidate hops, timeout and body size
04schema gate
Structured extraction
Provider output must pass Zod
05commit gate
Review + persist
Human-approved data enters application state
My approach
System path
Capture
Import job pages and upload resumes through bounded interfaces
Validate
Apply tRPC/Zod contracts before data becomes business state
Process
Run crawler and BullMQ workers with persisted TaskRun status
Review
Expose editable records, application state and explicit failures
Durable task lifecycle
The queue starts work; TaskRun tells the truth about it
Persisted status lets the web application explain waiting, progress and failure even when the worker runs in another process.
01durable
Queued
Task record exists before work begins
02observable
Running
Worker claims the task and reports progress
03terminal
Completed
Validated result is attached to the record
04diagnosable
Failed
Failure reason remains queryable
05explicit
Retry / review
A controlled decision starts the next attempt
Key trade-offs
Persist task state
Queue messages trigger work; TaskRun remains the queryable record of queued, running, completed or failed state.
Isolate URL retrieval
Crawler controls keep untrusted fetching outside the main process and validate redirects and resource limits.
Contracts before intelligence
Provider output becomes application data only after schema validation; a model response is not a database record.
04 · A
My contribution
- Implemented job import, editable structured records, resume upload and asynchronous text extraction with persisted status.
- Added SSRF, DNS/redirect, timeout and body-size controls plus schema validation at system boundaries.
- Diagnosed a cross-process queue/database mismatch and defined controlled integration contracts.
04 · B
What was implemented
- Implemented source-grounded job, application, resume and task data flows plus working crawler/resume processors.
- Kept interview, knowledge-scan and match-report processors, full tool calling and RAG explicitly outside the implemented scope.
Lessons learned
01Agent products start with verifiable state, limited authority and deterministic writes—not with more tools.
02Async architecture earns its complexity only when status, retries and failures are observable.
What I can share
I am developing this platform around monorepo boundaries, data flows, structured job extraction, controlled URL retrieval and asynchronous resume processing. It is a prototype: identity and SQLite persistence are development-oriented, and several Agent/RAG processors remain in progress.
Public sources