Added in 0.3. The matching producer capability is
task.run.task names the task the run attempted. A learner compares runs on the same task, and pools runs on similar tasks, so the task needs a stable id, a type and a few features, all written by the tool that knows them.
string
Top-level task type.Recommended values (open set):
bug_fix, feature, refactor, tests, docs, research, infra, data.At most 100 characters.string
User subcategory; a slash-separated path is allowed, e.g.
payments/webhooks.At most 500 characters.string
Repository name or opaque id.
loopmath share replaces it with a salted hash.At most 500 characters.string
Organization id. Defaults to the store’s
org config.At most 200 characters.The task chain, root first: org, type, repo, subtype, extra user levels. Derived from the fields above when absent.
map of boolean | number | string
Task features, key to boolean, number or string. Recommended keys: size (xs, s, m, l, xl), lang (primary language, lowercase), has_tests, spec_clarity (clear, partial, vague), needs_design, touches (1, 2-3, 4+). Filled by the orchestrator.
string
Commit the run started from. Pair members must match (E194).At most 200 characters.
object
object
Groups
A task belongs to a chain of groups, root first. A learner can pool evidence along the chain, so a new repository starts from what is known about its organization and task type.string
required
Grouping level, root first: org, type, repo, subtype, then extra user levels.Recommended values (open set):
org, type, repo, subtype.At most 100 characters.string
required
The group’s key at that level.At most 500 characters.
- When
groupsis absent, the chain isorg,type,repo,subtype, taken from the task’s fields, with absent fields skipped. - A producer MAY add levels of its own after
subtype.
Features
features maps a key to a boolean, number or string. The keys are open; these are recommended so that runs from different tools line up:
labeled_by says who assigned type, subtype and features, and its tier says how far to trust them, for example heuristic for a model labeler.
Requirements
task.idis stable: every run on the same task carries the same id, so runs can be compared.- Runs in one slate MUST carry the same
task.id, and the samebase_commitwhen present (E194). titleis a short label. Undermetadata_onlyit MUST NOT contain the task’s prompt or issue text (Privacy).repoMAY be an opaque id instead of a name.source.kindsays where the task came from:livefor a user’s task as it happens,backlogfor a planned task list,benchmarkfor a benchmark item,historyfor a logged past session.