chore(input): relocate collaborator q&a
This commit is contained in:
@@ -1,46 +0,0 @@
|
|||||||
# Input Pipeline Clarifications
|
|
||||||
|
|
||||||
Please add answers inline after each question.
|
|
||||||
|
|
||||||
1. **Codex execution:** Should the input-side container actually run the `codex` CLI to generate the customized resume, or simply assemble the combined prompt file for manual execution? If automated, what exact command, flags, and expected output path should it use?
|
|
||||||
|
|
||||||
Yes please invoke the codex cli .
|
|
||||||
|
|
||||||
I want it to run non interactively and in an automated fashion. I am open to you building a cli / process todo that . I am sure we will need to iterate a bit.
|
|
||||||
|
|
||||||
It should output the returned markdown file to ForCustomizing/outbox/YYYY/MM/DD/HHMM (using local system time) and move the .md file from ForCustomizing/inbox to ForCustomizing/processed/YYYY/MMD/DD/HHMM (if succesful)
|
|
||||||
|
|
||||||
On failure it should put the .md file into failed
|
|
||||||
|
|
||||||
|
|
||||||
2. **Resume selection:** How should the watcher choose the base resume when multiple Markdown files live in `input/resume/`? Will there always be exactly one current resume, or should job-description filenames reference a specific variant?
|
|
||||||
|
|
||||||
Only one .md file should exist. Any other condition is a fatal error and the input stack should halt and inform the user of multiple input resumes.
|
|
||||||
Same for if multiple .md files ever exist in ForCustomizing/inbox .
|
|
||||||
|
|
||||||
|
|
||||||
3. **Post-processing job descriptions:** After a job description is handled, where should its source Markdown move? Should successes land in `input/ForCustomizing/processed/` and failures in `input/ForCustomizing/failed/`, mirroring the output pipeline?
|
|
||||||
|
|
||||||
Yes exactly
|
|
||||||
|
|
||||||
4. **Parallel jobs:** Do you want the watcher to enforce “exactly one job file at a time” in `input/ForCustomizing/inbox`, or process multiple sequentially if several appear?
|
|
||||||
|
|
||||||
Only one file and one job at a time. Anything else is a fatal error and should halt the line.
|
|
||||||
|
|
||||||
|
|
||||||
5. **Customized resume location:** Where should the generated Codex output (or combined prompt) be saved for human review—timestamped folders under `input/ForCustomizing/outbox/`, a flat directory, or another structure?
|
|
||||||
|
|
||||||
|
|
||||||
See my answer to question 1.
|
|
||||||
|
|
||||||
To recap outbox/YYYY/MM/DD/HHMM (using local system time)
|
|
||||||
|
|
||||||
6. **Container environment:** Is there a preferred base image or existing Codex CLI installation to assume for the input container? When mounting `~/.codex`, should it be attached to `/root/.codex` or a different path the CLI expects?
|
|
||||||
|
|
||||||
Great question.
|
|
||||||
|
|
||||||
I guess a generic debian image that can npm install codex however the official codex docs say to install it? It will need to be able to update the cli as well, as the cli is frequently updated. I'm fine with this being a "fat" container.
|
|
||||||
|
|
||||||
I do not want any root user anywhere. Look at the output stack for how it has a little bash wrapper script to handle uid/gid mapping?
|
|
||||||
|
|
||||||
I guess create a dedicated non root user in the container to run the watcher and invoke codex? Open to suggestions here?
|
|
||||||
Reference in New Issue
Block a user