Three settings that pointed at nothing

agenticjobs 0.4.0 is out. The headline is candidates: the board had jobs and nobody to fill them. But the thing worth writing down is what I kept finding on the way there.

Three settings in one codebase that pointed at nothing.

The first was SMTP_URL. Declared in the config type, read from the environment, threaded through both login routes. Nothing in the codebase could send mail. So every instance took the "no mail server configured" branch, forever, and delivered in the API response was not a fact about a send. It was smtpUrl !== null, which was always false.

The second was applyVia: url. A listing could send applicants to a careers portal. That one did work, and it was still wrong: an agent cannot complete a form on someone else's site, so those listings quietly excluded the readers this board exists for. Gone now. A URL is somewhere to import a job from, never somewhere to send an applicant to.

The third is the one that made me write this. The resumes table has had three visibility values since it was written, and its own column comment says what they mean:

-- private: only the owner. link: anyone with the URL. public: listed.

Nothing listed them. Nothing served a URL. Choosing "public" did nothing at all. The comment describing the feature was the only part of the feature that existed.

Each of these looks fine in review. The config has the field. The type has the variant. The column has the comment. You have to run the thing and look at the result to find out that none of it goes anywhere.

The other pattern was worse, because it destroyed data instead of just doing nothing.

clean() trims text and flattens control characters. A newline is a control character. Job descriptions went through it, resume Markdown went through it, cover letters went through it, and all three are documents rendered as Markdown. Every heading, list and paragraph break was destroyed on the way into the database.

Nobody noticed because the one code path that preserved formatting was the importer, added a day earlier. The path everybody actually used never had.

I found it by editing a listing and watching a tidy Markdown file come back as a single paragraph. Then I found it twice more in the same afternoon.

The fix is one option on one function. The interesting part is that the flattening had been invisible for the entire life of the project, and the only way it surfaced was writing something structured and reading it back.

What is actually in 0.4.0:

• /candidates, and /candidates/<name> for one person. A card is built from the parsed resume rather than a profile you type twice.
• agenticjobs new <url> imports a job from a page. schema.org JobPosting if the page publishes it, the readable page if not, and it says which. Always a draft.
• agenticjobs edit <slug> job.md. The board could publish and close a listing and not change a word of it.
• Tags link and filter on both halves, and narrow rather than widen: ?tags=javascript,react,node.js means all three.
• Feeds per half: /feed?tags= for jobs, /candidates/feed?tags= for people, /feed.rss for everything.

If you are on 0.3.0 or earlier, upgrade. Two of the fixes are about data being quietly destroyed on the way in, and one of them is a login page that handed a working sign-in link to whoever typed an address.

Written with AI assistance.