add basic web app workflow

[cazlo]

end state is some typical REST based async task workflow thing. something like this:

View resume generation Job List

 flowchart LR

       human --> browser --> reactSite
       reactSite --> backendAPI --> database

so human interacts with site to see database of job descriptions already processed and associated generated tailored resume

Generate resume from job description

human can add a new job description which will kick off some async task processing workflow to hit up the LLM and eventually generate a resume. react site polls the backendAPI (which looks for Job state in DB) until the job reaches a terminal state (e.g. cancelled, error, complete, timed out, etc.)

human should input at least the URL, but probably also some metadata like company and/or description text so we dont have to scrape as much with brittle tools like regex and dom class descriptors. something like this:

 flowchart LR

       human --> browser --> reactSite
       reactSite --> backendAPI --> database
       backendAPI --> queue --> queueWorker --> OpenAPI --> database

View resume generation Job details

here human can see metadata associated with the job such as start/end date, openapi cost, job status, etc.

human can also see generated resume and a list of generated application form input to make the application process quicker than before, but still have a human in the loop reviewing the content before submission.

runnability

the whole thing should be runnable locally using docker compose and/or local k8s like minikube

will probably use celery, rabbitmq, and postgres to bootstrap most of the async queue processing stuff

[cazlo]

might want to pivot current app generation state to https://github.com/fastapi/full-stack-fastapi-template

[cazlo]

might want to pivot current app generation state to https://github.com/fastapi/full-stack-fastapi-template

too many big deviations from current setup (e.g. using some new rust poetry/pip replacement). want to look at this, but will do it after initial logic is laid out and tested

[cazlo]

miss from original requirements:

will need to have some workflow where user enters their resume (in a normalized way we can reliably throw into LLM prompt templates and whatnot)

ideally they dont have to do this every time they enter a new job description for which to generate a tailored resume

thinking best course of action is something like POST /resume which has all the normalized fields and pydantic validations and whatnot. this would create a row in like resume_version table or similar. then job has a FK back to this table to allow job generation to be for a specific resume version.

so a resume_version could have many associated jobs and a job only has 1 associated resume_version

resume_version would not have the LLM generated resumes in it to provide clear distinction between the 2 concepts and avoid confusion in the domain model.