0.5.0: one query, every representation

A filter written once now works whichever way you read the board.

/?workplace=remote&tags=javascript
/api/v1/jobs?workplace=remote&tags=javascript
/jobs.md?workplace=remote&tags=javascript
/jobs.json?workplace=remote&tags=javascript
/feed?workplace=remote&tags=javascript
/jobs.rss?workplace=remote&tags=javascript
/feed.rss?workplace=remote&tags=javascript

search_jobs over MCP already took the whole filter set, and now accepts tags alongside tag so it spells the filter the way everything else does.

Two feeds were ignoring you

/jobs.rss and /feed.rss built their query from an empty parameter list, so whatever a reader put in the address was discarded and the feed answered with the whole board. A feed that looks filtered and is not is worse than one that refuses, because nothing tells the reader.

Asking each surface for workplace=onsite on a board whose only job is remote, before the fix: /api/v1/jobs 0, /jobs.json 0, /feed 0, /jobs.rss 1, /feed.rss 3.

Markdown

/jobs.md and /candidates.md, taking the same query. A model handed HTML has to pull a page apart to find the job; handed Markdown it has the document. Each listing carries its apply-schema URL, so an agent reading the Markdown does not have to guess how to apply. Both are linked from the page head and named in llms.txt.

What a filtered everything-feed contains

/feed.rss is still the whole site and is filterable now. Tags are the only filter that means the same thing on both halves of the board, so a job-shaped filter (workplace, employment type, seniority, agent policy, a salary floor, an employer, free text) drops the people: a person cannot answer "is this remote", and answering a narrow question with the whole roster is the same failure as ignoring the filter. Employers drop out of any filtered feed for the same reason.

121 tests against a real Postgres.