career-ops-hq/career-ops

A code audit of this area found something that could be simpler to maintain. What: duplicated logic. The same 7-line parseDate(), which validates a YYYY-MM-DD string and returns midnight UTC, is copied in three scripts. A fourth copy lives inside a test ("replicated for testing"), so that test checks its own copy and not the function the script runs. Where (main at 24745c5): rejection-latency.mjs line 133: parseDate check-table-freshness.mjs line 108: parseDate detect-reposts.mjs line 121: parseDate tests/detect-reposts.test.mjs line 67: the replica in the test What would help: Move parseDate() to one small new module under lib/ and import it from the three scripts. All three already import from ./lib/ Import that same function in tests/detect-reposts.test.mjs and delete the replica, so the test covers the real one Put it in its own file, not in lib/local-today.mjs: that module is about "what day is it here" Out of scope: followup-cadence.mjs and funnel-velocity.mjs have their own

A code audit of this area found something that could be simpler to maintain. What: duplicated logic. Two CLIs each carry a private loadFollowups() that reads data/follow-ups.md and returns its table rows. The two are the same loop, and a tested parser for that file already exists. Where (main at 24745c5): contact-extract.mjs line 206: loadFollowups reply-watch.mjs line 122: loadFollowups followup-cadence.mjs line 463: parseFollowups, the exported parser What would help: Have both CLIs import parseFollowups() from followup-cadence.mjs and keep only "if the file exists, read it and parse it". company-history.mjs already does this at line 290 One behavior change to cover with a test: parseFollowups() also reads the legacy bullet format that the two copies skip, so those rows start reaching the reply matcher. The matcher reads email domains from a row's notes, so a legacy bullet with an email in it can now produce a match #4645 is open on reply-watch.mjs, so a rebase may be needed. Ple

A code audit of this area found something that could be simpler to maintain. What: missing documentation. path-resolver.mjs decides where the data root and the tracker file live, and most scripts import it, but no document names it. The docs explain the environment variables and their precedence, not which module a new script should use. Where (main at 24745c5): path-resolver.mjs line 14: getCareerOpsRoot path-resolver.mjs line 59: resolveTrackerPath path-resolver.mjs line 93: a comment that says "see the re-export above" What would help: Add a short note to AGENTS.md (next to the CAREER_OPS_TRACKER paragraph) or to docs/SCRIPTS.md: a new script resolves the data root and the tracker path through path-resolver.mjs, not through __dirname Fix the comment at line 93: there is no re-export in this file. The re-export it means is in tracker-utils.mjs Out of scope here: AGENTS.md and DATA_CONTRACT.md say a relative CAREER_OPS_TRACKER is resolved from the repository root, while the code r

Follow-up to #3734, which adds scan-dayforce.mjs, a browser-based scanner for Dayforce career sites. providers/ADDING_A_PROVIDER.md accepts browser scanners under three conditions. The third, "No bypass", says that if a source puts an interactive challenge in front of its public listings, the scanner reports that as a named error and stops; it does not work around it. Today, when a Dayforce board answers with a 403 or a 429, the scanner discards the browser context, retries once with a fresh one, and then fails with a generic search fetch failed: HTTP 403. Someone running it cannot tell an interactive challenge from any other failure. What to do: After page.goto() on the board URL, detect when the page is an interactive challenge instead of the board. In that case, throw a named error (for example DayforceChallengeError) whose message says the board is behind an interactive challenge and was skipped, and do not retry. Add a test with a stubbed challenge response. The scanner must

#2690 lets the English evaluation use the archetypes a user defines in modes/_profile.md: a role that matches none of them is reported as "Not a target" with North Star 1, and without a profile the base archetype table still applies. The translated modes under modes/<lang>/ still describe only the base table, so someone evaluating in another language does not get the same behaviour. This came up on #2690 (CodeRabbit thread "Propagate the target-aware archetype rule to localized evaluations") and was left for a follow-up so the English change could land. What to do, per language: Mirror the rule from modes/_shared.md in that language's shared file: use the _profile.md archetypes when they exist, otherwise the base table. Mirror the "Not a target" case (North Star 1) in that language's evaluation mode. One language per PR is fine, and easier to review.