Hunr

Where each invited candidate is: invited, accepted (begun), submitted, scored, decided, expired, revoked (withdrawn) or bounced, with a count per status. Pass a challenge id for one challenge's candidates, or leave it out for the organisation's. It says where each candidate is, not their score.

candidates_list

The challenge and the agent's latest steps on it, for Hunr's card to show while the agent works. Only the card calls it.

challenge_progress

Use this to find where a page states a number or a rule before fetching that section: lines of a document's live page matching a pattern (a case-insensitive regular expression, or the literal text), each with its section id and the lines around it.

doc_grep

Generate the judge's held-back cases: describe each dataset and Hunr writes the rows, the same rows for the same spec and seed. Generated data serves the judge only: the records our side holds and serves through the fitted declaration, and the inputs we send the submission, when the judge's source is generated. It is never a candidate-facing kit: nothing generated ships to the candidate, and the brief describes none of it. Plan the data first from the judge's schema, then generate it in one call: every dataset the cases need (the entities before what refers to them), each with its fields and counts, in datasets, generated in order so a later one refs and looks up an earlier one. The records are clean, realistic and consistent, with nothing planted in them: each case category's inputs are clean records changed by that category's one operator. Use it for every piece of structured data the judge needs (records, traffic, events, logs as rows) instead of typing rows yourself; write only prose by hand. Each field sets one generator (seq, id, ref, int, float, enum, bool, time, fake, template, calc, text, after, lookup). An amount a reader can work out from a rate and a quantity on the record is calc over them, never drawn on its own, and numbers are numbers (10, never "10"): both are refused. Status words are shared across categories: no value of a served column found only on one category's rows. A ref draws from a dataset generated before, so generate the entities (players, accounts, builds) first, then what refers to them. Rows hang together by construction, never by generating again: what is fixed per entity (a build's branch, commit and start) goes on the entity's dataset and comes over with lookup; a time that follows another, in the row or in another dataset through a lookup (finished, received, completed after the scheduled pickup), is after it; a count within an entity (attempt, line number) is seq with per; a key that belongs to a parent is looked up, never drawn beside it (draw the user, look up its org; with no users dataset, the org is fixed_by the user); values that go together are enum by with choices (a status and its codes, a carrier and its services); a self-reference differs_from its pair (from and to accounts, a supplier and its customer); a status with a lifecycle is enum progress by its entity in time, a counter that only grows is int or float cumulative by its entity, and an entity's events follow its start with after over the looked-up start. Prose is yours to write, never faked: a text bank of eight or more templates in this system's words, with slots you write and the row's {fields}, never an enum of a few phrases the file repeats; the summary warns on prose that repeats or names a real firm. A digest is fake sha256. Firms' names are made up (fake company, carrier, law_firm…), never real firms. Real data recurs: users act many times, accounts pay many invoices, so an id that names such a thing takes a pool (or a ref to a dataset of them), and only the row's own key is new on every row. The answer has a summary of each column (check the skew is what you meant, and fix any column with a warning, a column that states a case's answer among them) and sample rows. No served field states the answer: no is_duplicate, prior_write or should_refuse, no true-or-false field true exactly on one category's rows, and nothing served that holds a value only on one category's rows; a case is found by reading the values a real record holds. Helper columns (an operator's part a template joins, a pick, a lookup of the category) take hidden: true: kept for gold and checks, never served through any capability or request; category, gold and gold_ fields are always hidden. A field only some rows hold (a completed_at when the status is complete, a refund_id when refunded) takes only_when, so it is null on the rest. With a generated source, the held-back cases are the last dataset, named cases, one jsonl row per case, 24 to 30 rows and at least 2 per category: id; category (enum by a seq n, its choices giving each row number its category's id: the only field ever set row by row, every record value being drawn, with a category's operator as a field only_when on its category); requests, a template writing the fixed request as a JSON list ([{"port":8080,"method":"POST","path":"/audit","body":{"invoice_id":"{invoice_id}"}}], or for a command its input, [{"body":{"brand_id":"{brand_id}","month":"{month}"}}]); a case that is a slice of records (an analysis over a brand's month) owns its slice key, and the records datasets generated after cases ref it and change only the first few rows of its slice; one gold_<category> template per category with only_when on category, writing {"writes":[{"capability":"…","fields":{…}}],"ending":"answer|handover|refuse"}, its fields ids, amounts and codes, never prose; and gold, a template naming every gold_ field, so each row carries its own category's gold. Name the datasets in the judge part's source and its capabilities. Generating a name again stores a new version that the draft uses; the earlier one is kept. Generate a dataset again only to fix what its summary or a query shows is wrong. One entry of datasets: {name: "spends", format: "jsonl", rows: 400, order: "at", fields: [{name: "player_id", ref: {dataset: "players", field: "player_id", zipf: 1.3}}, {name: "amount", int: {min: 1, max: 500, dist: "lognormal", median: 40, spread: 1}}, {name: "at", time: {from: "2026-03-14", to: "2026-03-16", pattern: "daily"}}, {name: "key", id: {prefix: "k-", length: 8}}]}. Rows that hang together, in an entry after a builds dataset: fields: [{name: "build_id", ref: {dataset: "builds", field: "build_id"}}, {name: "branch", lookup: {ref: "build_id", field: "branch"}}, {name: "started_at", lookup: {ref: "build_id", field: "started_at"}}, {name: "finished_at", after: {field: "started_at", min_seconds: 60, max_seconds: 1800}}, {name: "received_at", after: {field: "finished_at", min_seconds: 0, max_seconds: 30}}, {name: "attempt", seq: {per: "build_id"}}].

data_generate

Email people a link to take a published challenge. Use it only for people the user named, with their addresses exactly as the user gave them. Each gets an email from Hunr now and a reminder after three days if they have not begun. Re-inviting someone works: if their invite to this challenge is still open and not begun, it is sent again with the new days to begin (resent); if it closed (expired, revoked, bounced, handed in, scored or decided) they get a new invite with its own attempt (invited). A bad address, a repeat, or someone taking the challenge right now is skipped and named in the answer. Each candidate who accepts uses one of the organisation's free screens; the answer says how many are left. Refused while the challenge is a draft. In Hunr's demo organisation the invites are made and listed but nobody is emailed, and the answer's `note` says so.

candidates_invite

The organisation's challenges, most recently worked on first: each one's id, title, format, whether it is a draft, published, closed or archived, and which parts a draft still lacks. Archived challenges are left out unless include_archived is true. Use it to find a challenge the user names by title, before reading, publishing or inviting to it.

challenges_list

The Hunr organisations the signed-in user belongs to, each with its slug and the user's role. A challenge belongs to one organisation, named by its slug.

orgs_list

Use this when the challenge needs a page the corpus lacks, so it can be cited: an engineering blog post, a postmortem, a standard or a vendor's docs page you know or found that answers what search could not. Name the page's url and say in `why` what it holds, in the words search would use. Hunr reads it now (up to 25 seconds): `passed` means it is searchable for this organisation as of this call and the answer lists its sections to `fetch`; `held` means a person at Hunr decides; `refused` says why; `pending` means it is still being read. A host without a url only joins the review queue.

source_propose

Publish a finished challenge so candidates can be invited to it. Use it only when the user asks to publish this challenge. Publishing freezes it: every part is fixed at its current version and none can be changed afterwards, but the time box (challenge_update). Refused, with the parts named, while any required part is missing; refused as well if it is already published.

challenge_publish

Count what is in the challenge's datasets with read-only SQL (SQLite) instead of working it out yourself: each dataset is a table of its name with _row, its row number from 1. Use it for the judge's numbers: how many cases fall in each category, what a correct outcome comes to, how many calls a minimal handling of a case takes. Ask everything you need at once: up to ten named queries a call, each answered or refused on its own, at most 200 rows each.

data_query