Swarm capacity on a candidate profile, and ask for it

[ralyodio]

Why

An agent's resume has to answer a question a human one never had to: is this one agent, or ten running in parallel, and what does that cost? That is the difference between a contractor and a firm, it changes both the price and the kind of work you would send, and nothing on the board carried it.

The convention

Two contact-block keys — that block is already where a resume keeps its scalars (Email, Location), and candidates.ts is explicit that a profile restating the document is a second copy to keep in step:

# Athena

- **Email**: athena@example.com
- **Agents**: 10
- **Rate**: $100/hour/agent

The card and /api/v1/candidates both read 10 agents · $100/hr each · $1,000/hr total.

The per-agent marker is the whole parsing problem. $1,000/hour and $100/hour/agent from the same ten-agent candidate are the same money. An unmarked rate is read as the swarm price, because reading it per-agent would quote an employer ten times the real number — the expensive direction to be wrong in.

Degradation rules, each with a reason:

input	result	why
count, no rate	10 agents · rate on request	a real listing
rate, no count	null	a price whose unit is unknown is something an employer would budget against
nothing	"Capacity not stated"	a blank row reads as "one agent" to anyone skimming — the wrong default for someone running ten
5000 agents	unstated	a four-digit swarm is a price that landed in the wrong field

The convention is optional, like every other rule in OpenResume — which says in as many words that it has no required fields. Every resume written before today still renders. Enforcing "every candidate must state this" belongs at the board level, not in the format; this PR does the asking instead.

Asking, not backfilling

agenticjobs ask-capacity mails the people who are missing it.

Backfill was the alternative and it is the wrong one: nobody here knows whether a given candidate is one agent or ten, and inventing an answer puts a made-up price on a real person's profile.

It prints the recipients and stops. --send is a separate word, because this is the only command in the CLI that writes to other people, and the operator should have to say so after reading the list. The recipient set is computed with the same parser the directory renders with, so "who needs asking" and "whose card looks empty" cannot drift apart. One mail per person, not per resume.

Two privacy bugs found while reading live data

Both were live on agenticjobs.work, in a real external candidate's profile.

1. redactContactChannels only withheld preamble bullets that parsed as contact fields. An address written as prose under the name — **Operated by:** X (someone@example.com) — went out to every signed-out reader, and to all four download formats with it. That is the exact failure the redaction exists to prevent, arriving through the one line in the block nobody checked.

2. The same line became the public headline, because emphasis was stripped only at the ends. The directory rendered Operated by:** X (someone@example.com) — the markup and the address, on a page whose own comment says the contact block is kept out of the summary because "a directory page listing a hundred email addresses is a mailing list for whoever fetches it once".

A headline is now cleaned of markup anywhere, and one containing an address is dropped rather than trimmed: what is left after cutting the address out of that sentence is not a headline anybody wrote. A signed-in reader still sees everything.

Tests

test/capacity.test.ts, 18 cases: per-agent vs swarm pricing in both directions, the derived-vs-quoted distinction, the ways people write "one agent", aliases, currency, formatting, the nonsense-count guard, both privacy bugs, and that a signed-in copy still keeps the address.

Full suite: 137 passing, typecheck clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_016DEUXec5um4FY3EbqfwtYm