Dashboard
Curator's dashboard is a dataset analytics view for finished task collections.
Run /curator:dashboard after collection and creation, when you want to see what
the dataset contains before handing it to Tracer.
A demo dashboard is available here.
Deployment mode
Both modes read the same files, so the numbers never depend on which one you pick.
- Local (default): run
/curator:dashboard. The board is built and served on this machine, so problem statements, repository names, patches and tags stay here. - Cloud: run
/curator:dashboard publish to Cloudflare. WithCLOUDFLARE_API_TOKENandCLOUDFLARE_ACCOUNT_IDset, the board is deployed to the Pages projectlegoflow-curator; without them, a temporary*.trycloudflare.comtunnel is opened instead. Take the URL from the command output rather than guessing it, because a*.pages.devname that is already taken gets a suffix.
Where it reads from
There is nothing to configure. The board always reads two fixed locations:
| Path | What it holds |
|---|---|
artifacts/collected_prs/ | PR ID lists from collection, one file per language. The PR to task funnel is computed from these. |
artifacts/swe_tasks/ | Task batches, one per immediate subdirectory. |
By default those are the tasks Curator collected and generated on this machine. To add a third-party dataset:
- Download it and convert it into the Harbor task layout: one directory per
task, each with
task.tomlandinstruction.md, matching what an existingartifacts/swe_tasks/<batch>/looks like. - Put that directory under
artifacts/swe_tasks/. Its name becomes the batch name. Imported batches stay out of the PR to task funnel, which only describes tasks the collector sourced. - Tag it, following
Task Tagging, because
difficulty and the four semantic tags are read from each task's own
task.toml. An untagged batch still appears, but its difficulty and tag panels stay empty.
Import External Data
The board only reads artifacts/. Symlink an outside dataset into
artifacts/swe_tasks/, and the link name becomes the batch name.
Scanning is not free, since every task's task.toml is read on each render. A
pool of tens of thousands of tasks takes minutes to draw, so link the large ones
in only when you intend to look at them.
What it monitors
| Monitor | What it tells you |
|---|---|
| Dataset size | How many verified tasks each batch holds. |
| Language coverage | Whether the dataset is balanced across Python, JavaScript, TypeScript, Go, C, C++, Java, Rust, and the other supported languages. |
| Difficulty mix | Easy/medium/hard buckets and numeric difficulty scores. |
| Semantic tags | The four-tag schema [language, area, topic, bug_class], useful for filtering and balancing. |
| Dataset comparison | How Curator-generated tasks compare with other SWE datasets under the same rubric. |
| Task drilldown | Per-task metadata, repository identity, problem statement, patch and test signals, difficulty, and tags. |
This is not a live generation monitor. While Curator is still creating tasks,
watch the logs, verifiable_tasks.txt and artifacts/index.yaml instead.
When to Use It
Use /curator:dashboard when you want to answer questions like:
- Did Curator produce enough verified tasks?
- Which languages or task areas are underrepresented?
- Are there too many easy or too many hard tasks?
- Which bug classes dominate the current dataset?
- Is the dataset ready for Tracer rollout?
For the scoring rubric and tag schema, see Quality Rubrics and Task Tagging.