How is the initial decision to discard or do a Full Evaluation on a Job Req supposed to happen

[Kevin-Boyle]

I found the out-of-the-box functionality for making decisions about which roles to do full evaluations of very confusing. This may also be my lack of understanding of how this project is supposed to work, but every time I ask Claude to explain it to me, it tells me to manually run a command to fetch new roles, then run another command to do a quick triage on them, then open a file and edit it... None of that was user friendly, and I had to create a new interface and flow for this to work for me. I'm curious how others have solved this and if any of this would be helpful to send upstream with a PR.

First, I scheduled some automations to automatically fetch new roles each morning and run an initial triage/scoring on the titles/locations. I understand this is optional and shouldn't be mandated in the project.

Second, I created an Inbox view of all of the roles that meet my minimum score criteria that hangs off the Dashboard. Press "i" from the dashboard to view the list of new roles that meet the minimum score criteria and decide if you want to discard the role or do a full evaluation. And then I press 'tab' to go back to the dashboard view. It's not the most elegant solution, but it's a lot more ergonomic for me than going to multiple locations to work on the same pipeline of opportunities at different stages.

[S3yon]

The intended flow is scan, then a cheap first pass, then /career-ops pipeline. It is spread across a few places, but most of what you built already exists upstream. As of main on 2026-10-18:

1. Scheduled scans. AUTOMATION.md covers cron, launchd and Task Scheduler for node scan.mjs, which costs zero tokens. The web UI also has a Scheduled scans page with several cadences, run by one 15-minute worker (sh web/scripts/install-scan-schedule.sh). New postings land under ## Pending in data/pipeline.md.

2. The first pass. Three options, cheapest first:

• The title + location triage prompt in AUTOMATION.md section 2. It writes a shortlist file. This is the "open a file and edit it" step your agent kept describing.
• node rank-pipeline.mjs (docs) adds a rank: X/5 score and a reason to each pending row. It only annotates. It never filters.
• /career-ops pipeline runs its own pre-screen on the standard and premium spend tiers. Obvious mismatches are skipped and logged to data/discard.log with a reason, and the rest get the full A-F evaluation (modes/pipeline.md).

3. The inbox. Run npm run ui and open http://127.0.0.1:3000/pipeline. Inbox is the default tab. You can filter by posted date, ATS source, seniority, location and keyword. Skip marks the row done in pipeline.md and can be undone, Save adds the role to a shortlist, and "Score shortlist" starts a full evaluation for each saved role. That is your discard or evaluate screen, in the browser instead of the TUI. The Go dashboard only reads applications.md, so upstream has no inbox there.

What the web inbox doesn't have is your minimum score cutoff. It sorts by freshness only, and nothing in the web UI reads the rank-pipeline scores. The comment on that sort calls it the single place a smarter ranker would plug in.

On sending it upstream: CONTRIBUTING.md asks for an issue before any new feature or mode. The smallest piece that fills a real gap is a minimum score filter in the web inbox, using the rank-pipeline scores. A second inbox in the TUI would be a parallel surface for the same flow, so expect the parallel-feature questions. Mention your TUI version in the issue and the maintainers can say if they want it there too.

[Kevin-Boyle]

Ahhh.. Thank you. Since the web UI was marked as Alpha, I didn't think I should use it. I guess that's the interface I should be looking towards rather than the TUI.