ellf-cli 19.0.0__tar.gz → 19.0.3__tar.gz

{ellf_cli-19.0.0/ellf_cli.egg-info → ellf_cli-19.0.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ellf-cli
-Version: 19.0.0
+Version: 19.0.3
 Summary: Ellf Command Line Interface
 Home-page: https://prodi.gy
 Author: ExplosionAI GmbH

{ellf_cli-19.0.0 → ellf_cli-19.0.3}/README.md

@@ -1307,23 +1307,23 @@ Mint a fresh 90-day token for an existing service. Issuing a new token does not
 
 ### `ellf sessions`
 
-View, disable and activate a task's annotation sessions
+View, exclude and activate a task's annotation sessions
 
 #### `ellf sessions list`
 
-List a task's annotation sessions, with how much each annotated and whether it was disabled
+List a task's annotation sessions, with how much each annotated, how much of that the dataset still holds, and whether it was excluded
 
 | Argument | Type | Description | Default |
 | --- | --- | --- | --- |
 | `name_or_id` | `Union[str, UUID]` | Name or ID of the task |  |
 | `--project` | `str` | Name, slug, or ID of task's project or the last project if not set | `None` |
 | `--cluster` | `str` | Name, slug, or ID of the cluster to search for task name (or the last cluster if not set) | `None` |
-| `--select` | `list[str]` | Comma-separated fields to select and show in output. Available: ['id', 'annotator', 'started', 'annotations', 'status'] | `['id', 'annotator', 'started', 'annotations', 'status']` |
+| `--select` | `list[str]` | Comma-separated fields to select and show in output. Available: ['id', 'annotator', 'started', 'annotated', 'active', 'status'] | `['id', 'annotator', 'started', 'annotated', 'active', 'status']` |
 | `--json` | `bool` | Output the result as JSON | `False` |
 
-#### `ellf sessions disable`
+#### `ellf sessions exclude`
 
-Disable an annotation session: take its examples out of the task's dataset, so training and exports leave them out and their tasks are served again. They still count as the annotator's work
+Exclude an annotation session: take its examples out of the task's dataset, so training and exports leave them out and their tasks are served again. They still count as the annotator's work
 
 | Argument | Type | Description | Default |
 | --- | --- | --- | --- |
@@ -1332,7 +1332,7 @@ Disable an annotation session: take its examples out of the task's dataset, so t
 
 #### `ellf sessions activate`
 
-Activate a disabled annotation session: put its examples back into the task's dataset
+Activate an excluded annotation session: put its examples back into the task's dataset
 
 | Argument | Type | Description | Default |
 | --- | --- | --- | --- |
@@ -1383,7 +1383,7 @@ List the tasks in a project. Uses your default project unless --project is given
 | Argument | Type | Description | Default |
 | --- | --- | --- | --- |
 | `--project` | `str` | Name, slug, or ID of task's project or the last project if not set | `None` |
-| `--select` | `list[str]` | Comma-separated fields to select and show in output. Available: ['id', 'created', 'updated', 'project_id', 'cluster_id', 'name', 'recipe_name', 'recipe_title', 'project_name', 'error', 'plan', 'job_type', 'cli_command', 'created_by_user', 'state'] | `['id', 'name', 'state']` |
+| `--select` | `list[str]` | Comma-separated fields to select and show in output. Available: ['id', 'created', 'updated', 'project_id', 'cluster_id', 'name', 'recipe_name', 'recipe_title', 'project_name', 'error', 'plan', 'job_type', 'cli_command', 'last_execution_started', 'created_by_user', 'state'] | `['id', 'name', 'state']` |
 | `--json` | `bool` | Output the result as JSON | `False` |
 
 #### `ellf tasks info`
@@ -1395,7 +1395,7 @@ Print information about a task on the cluster
 | `name_or_id` | `Union[str, UUID]` | Name or ID of the task |  |
 | `--project` | `str` | Name, slug, or ID of task's project or the last project if not set | `None` |
 | `--cluster` | `str` | Name, slug, or ID of the cluster to search for task name (or the last cluster if not set) | `None` |
-| `--select` | `list[str]` | Comma-separated fields to select and show in output. Available: ['id', 'created', 'updated', 'project_id', 'cluster_id', 'name', 'recipe_name', 'recipe_title', 'project_name', 'error', 'plan', 'job_type', 'cli_command', 'created_by_user', 'last_execution_id', 'related_actions', 'url_logs', 'url'] | `None` |
+| `--select` | `list[str]` | Comma-separated fields to select and show in output. Available: ['id', 'created', 'updated', 'project_id', 'cluster_id', 'name', 'recipe_name', 'recipe_title', 'project_name', 'error', 'plan', 'job_type', 'cli_command', 'last_execution_started', 'created_by_user', 'last_execution_id', 'related_actions', 'url_logs', 'url'] | `None` |
 | `--json` | `bool` | Output the result as JSON | `False` |
 
 #### `ellf tasks logs`

{ellf_cli-19.0.0 → ellf_cli-19.0.3}/ellf_cli/commands/datasets.py

@@ -164,6 +164,9 @@ def export(
     cluster_id = auth.cluster_id
 
     dataset = resolve_dataset(name_or_id, cluster_id=cluster_id)
+    legacy = auth.broker_client.datasets.total_example_count(dataset.name).legacy
+    if legacy:
+        raise CLIError(Messages.E066.format(name=dataset.name, count=legacy))
 
     def get_examples_page(page: int):
         return auth.broker_client.datasets.read_examples(

{ellf_cli-19.0.0 → ellf_cli-19.0.3}/ellf_cli/commands/sessions.py

@@ -2,7 +2,7 @@
 
 A task's annotations live in the cluster's Prodigy database, where every
 PAM session (one sitting of one annotator) has a dataset of its own named
-``{dataset}-{task_id}-{annotator_id}-{session_id}``. Disabling a session
+``{dataset}-{task_id}-{annotator_id}-{session_id}``. Excluding a session
 takes its examples out of the task's dataset while keeping them in that
 session dataset.
 """
@@ -20,7 +20,7 @@ from ..query import resolve_task
 from ..ui import print_mutation_result, print_table_with_select
 from ._state import get_auth_state
 
-SESSION_FIELDS = ["id", "annotator", "started", "annotations", "status"]
+SESSION_FIELDS = ["id", "annotator", "started", "annotated", "active", "status"]
 
 
 def _sitting_name(
@@ -45,31 +45,34 @@ def list(
     select: builtins.list[str] = SESSION_FIELDS,
     as_json: bool = False,
 ) -> Sequence[dict[str, Any]]:
-    """List a task's annotation sessions, with how much each annotated and
-    whether it was disabled"""
+    """List a task's annotation sessions, with how much each annotated, how
+    much of that the dataset still holds, and whether it was excluded"""
     auth = get_auth_state()
     task = resolve_task(name_or_id, cluster_id=cluster_id, project_id=project_id)
     dataset = auth.client.task.dataset(task.id)
     summary = auth.broker_client.datasets.session_counts(dataset.name)
     removed = set(summary.removed or [])
     rows = []
+    counts = summary.counts or {}
     for session in auth.client.session.all(task_id=task.id):
         name = _sitting_name(dataset.name, task.id, session.annotator_id, session.id)
+        count = counts.get(name)
         rows.append(
             {
                 "id": str(session.id),
                 "annotator": session.annotator_name,
                 "started": session.created.isoformat(timespec="seconds"),
-                "annotations": (summary.counts or {}).get(name, 0),
-                "status": "disabled" if name in removed else "active",
+                "annotated": count.annotated if count else 0,
+                "active": count.active if count else 0,
+                "status": "excluded" if name in removed else "active",
             }
         )
     print_table_with_select(rows, select=select, as_json=as_json)
     return rows
 
 
-def _set_session_disabled(
-    session_id: UUID, disabled: bool, as_json: bool
+def _set_session_excluded(
+    session_id: UUID, excluded: bool, as_json: bool
 ) -> dict[str, Any]:
     auth = get_auth_state()
     session = auth.client.session.read(id=session_id)
@@ -80,11 +83,11 @@ def _set_session_disabled(
     datasets = auth.broker_client.datasets
     change = (
         datasets.remove_session(dataset.name, name)
-        if disabled
+        if excluded
         else datasets.restore_session(dataset.name, name)
     )
     result = {"session": str(session_id), "examples": change.examples}
-    message = Messages.T072 if disabled else Messages.T073
+    message = Messages.T072 if excluded else Messages.T073
     print_mutation_result(
         result, message.format(id=session_id, count=change.examples), as_json=as_json
     )
@@ -93,15 +96,15 @@ def _set_session_disabled(
 
 @cli.subcommand(
     "sessions",
-    "disable",
+    "exclude",
     session_id=Arg(help=Messages.session_id),
     as_json=Arg("--json", help=Messages.as_json),
 )
-def disable(session_id: UUID, as_json: bool = False) -> dict[str, Any]:
-    """Disable an annotation session: take its examples out of the task's
+def exclude(session_id: UUID, as_json: bool = False) -> dict[str, Any]:
+    """Exclude an annotation session: take its examples out of the task's
     dataset, so training and exports leave them out and their tasks are served
     again. They still count as the annotator's work"""
-    return _set_session_disabled(session_id, True, as_json)
+    return _set_session_excluded(session_id, True, as_json)
 
 
 @cli.subcommand(
@@ -111,6 +114,6 @@ def disable(session_id: UUID, as_json: bool = False) -> dict[str, Any]:
     as_json=Arg("--json", help=Messages.as_json),
 )
 def activate(session_id: UUID, as_json: bool = False) -> dict[str, Any]:
-    """Activate a disabled annotation session: put its examples back into the
-    task's dataset"""
-    return _set_session_disabled(session_id, False, as_json)
+    """Activate an excluded annotation session: put its examples back into
+    the task's dataset"""
+    return _set_session_excluded(session_id, False, as_json)

{ellf_cli-19.0.0 → ellf_cli-19.0.3}/ellf_cli/ellf.json

@@ -1,7 +1,7 @@
 {
   "prog": "ellf",
   "help": "Ellf Command Line Interface.",
-  "version": "19.0.0",
+  "version": "19.0.3",
   "extra_key": "_extra",
   "commands": {
     "actions": {
@@ -159,7 +159,7 @@
     "sessions": {
       "name": "sessions",
       "args": [],
-      "description": "View, disable and activate a task's annotation sessions",
+      "description": "View, exclude and activate a task's annotation sessions",
       "allow_extra": false,
       "parent": null,
       "is_placeholder": true
@@ -7459,9 +7459,9 @@
             "id": "select",
             "option": "--select",
             "short": null,
-            "orig_help": "Comma-separated fields to select and show in output. Available: ['id', 'annotator', 'started', 'annotations', 'status']",
-            "default": "['id', 'annotator', 'started', 'annotations', 'status']",
-            "help": "Comma-separated fields to select and show in output. Available: ['id', 'annotator', 'started', 'annotations', 'status'] (list[str])",
+            "orig_help": "Comma-separated fields to select and show in output. Available: ['id', 'annotator', 'started', 'annotated', 'active', 'status']",
+            "default": "['id', 'annotator', 'started', 'annotated', 'active', 'status']",
+            "help": "Comma-separated fields to select and show in output. Available: ['id', 'annotator', 'started', 'annotated', 'active', 'status'] (list[str])",
             "action": null,
             "choices": null,
             "has_converter": true,
@@ -7482,13 +7482,13 @@
             "orig_type": "bool"
           }
         ],
-        "description": "List a task's annotation sessions, with how much each annotated and\nwhether it was disabled",
+        "description": "List a task's annotation sessions, with how much each annotated, how\nmuch of that the dataset still holds, and whether it was excluded",
         "allow_extra": false,
         "parent": "sessions",
         "is_placeholder": false
       },
-      "disable": {
-        "name": "disable",
+      "exclude": {
+        "name": "exclude",
         "args": [
           {
             "id": "session_id",
@@ -7517,7 +7517,7 @@
             "orig_type": "bool"
           }
         ],
-        "description": "Disable an annotation session: take its examples out of the task's\ndataset, so training and exports leave them out and their tasks are served\nagain. They still count as the annotator's work",
+        "description": "Exclude an annotation session: take its examples out of the task's\ndataset, so training and exports leave them out and their tasks are served\nagain. They still count as the annotator's work",
         "allow_extra": false,
         "parent": "sessions",
         "is_placeholder": false
@@ -7552,7 +7552,7 @@
             "orig_type": "bool"
           }
         ],
-        "description": "Activate a disabled annotation session: put its examples back into the\ntask's dataset",
+        "description": "Activate an excluded annotation session: put its examples back into\nthe task's dataset",
         "allow_extra": false,
         "parent": "sessions",
         "is_placeholder": false
@@ -7797,9 +7797,9 @@
             "id": "select",
             "option": "--select",
             "short": null,
-            "orig_help": "Comma-separated fields to select and show in output. Available: ['id', 'created', 'updated', 'project_id', 'cluster_id', 'name', 'recipe_name', 'recipe_title', 'project_name', 'error', 'plan', 'job_type', 'cli_command', 'created_by_user', 'state']",
+            "orig_help": "Comma-separated fields to select and show in output. Available: ['id', 'created', 'updated', 'project_id', 'cluster_id', 'name', 'recipe_name', 'recipe_title', 'project_name', 'error', 'plan', 'job_type', 'cli_command', 'last_execution_started', 'created_by_user', 'state']",
             "default": "['id', 'name', 'state']",
-            "help": "Comma-separated fields to select and show in output. Available: ['id', 'created', 'updated', 'project_id', 'cluster_id', 'name', 'recipe_name', 'recipe_title', 'project_name', 'error', 'plan', 'job_type', 'cli_command', 'created_by_user', 'state'] (list[str])",
+            "help": "Comma-separated fields to select and show in output. Available: ['id', 'created', 'updated', 'project_id', 'cluster_id', 'name', 'recipe_name', 'recipe_title', 'project_name', 'error', 'plan', 'job_type', 'cli_command', 'last_execution_started', 'created_by_user', 'state'] (list[str])",
             "action": null,
             "choices": null,
             "has_converter": true,
@@ -7871,9 +7871,9 @@
             "id": "select",
             "option": "--select",
             "short": null,
-            "orig_help": "Comma-separated fields to select and show in output. Available: ['id', 'created', 'updated', 'project_id', 'cluster_id', 'name', 'recipe_name', 'recipe_title', 'project_name', 'error', 'plan', 'job_type', 'cli_command', 'created_by_user', 'last_execution_id', 'related_actions', 'url_logs', 'url']",
+            "orig_help": "Comma-separated fields to select and show in output. Available: ['id', 'created', 'updated', 'project_id', 'cluster_id', 'name', 'recipe_name', 'recipe_title', 'project_name', 'error', 'plan', 'job_type', 'cli_command', 'last_execution_started', 'created_by_user', 'last_execution_id', 'related_actions', 'url_logs', 'url']",
             "default": null,
-            "help": "Comma-separated fields to select and show in output. Available: ['id', 'created', 'updated', 'project_id', 'cluster_id', 'name', 'recipe_name', 'recipe_title', 'project_name', 'error', 'plan', 'job_type', 'cli_command', 'created_by_user', 'last_execution_id', 'related_actions', 'url_logs', 'url'] (list[str])",
+            "help": "Comma-separated fields to select and show in output. Available: ['id', 'created', 'updated', 'project_id', 'cluster_id', 'name', 'recipe_name', 'recipe_title', 'project_name', 'error', 'plan', 'job_type', 'cli_command', 'last_execution_started', 'created_by_user', 'last_execution_id', 'related_actions', 'url_logs', 'url'] (list[str])",
             "action": null,
             "choices": null,
             "has_converter": true,

{ellf_cli-19.0.0 → ellf_cli-19.0.3}/ellf_cli/ellf_skills/skills/ellf-annotate.assistant/SKILL.md

@@ -168,4 +168,4 @@ When you finish:
 |------|---------------|--------------|
 | `${CLAUDE_SKILL_DIR}/references/annotation_audit.md` | Readiness checklist: objective, schema, recipe fit, data, dataset | Before every launch |
 | `${CLAUDE_SKILL_DIR}/references/builtin_ellf_annotation_recipes.md` | Built-in Ellf task and agent recipes with supported workflows | Recipe selection |
-| `${CLAUDE_SKILL_DIR}/references/label_schemes.md` | Label scheme (`labels` asset) format, design and use by tasks and agents | Labels need definitions, or writing guidelines |
+| `${CLAUDE_SKILL_DIR}/references/label_schemes.md` | Label scheme (`labels` asset) format, design and use by tasks and agents. Built-in `ner`, `spans` and `textcat` only | Labels need definitions, or writing guidelines |

{ellf_cli-19.0.0/ellf_cli/ellf_skills/skills/ellf-annotate.coding → ellf_cli-19.0.3/ellf_cli/ellf_skills/skills/ellf-annotate.assistant}/references/annotation_audit.md

@@ -41,7 +41,9 @@ passes.
 Labels that aren't self-evident need a written definition before launch: what the
 label covers, which look-alikes not to mark, and a few boundary examples. Keep them
 in a label scheme (a `labels` asset, see `label_schemes.md`) used by the task, so
-annotators see the descriptions and LLM agents get them in every prompt. If a label
+annotators see the descriptions and LLM agents get them in every prompt. Only the
+built-in `ner`, `spans` and `textcat` recipes (and custom recipes that implement it)
+take a scheme; for any other recipe, keep the definitions in the annotation guidelines. If a label
 can't be defined without "it depends", the schema isn't ready.
 
 ### Task complexity

{ellf_cli-19.0.0 → ellf_cli-19.0.3}/ellf_cli/ellf_skills/skills/ellf-annotate.assistant/references/builtin_ellf_annotation_recipes.md

@@ -44,6 +44,11 @@ workflows.
 
 ## Label schemes
 
+Only `ner`, `spans` and `textcat` take a label scheme. No other built-in recipe accepts
+a `labels` asset, so don't suggest one for them: put the label definitions in the
+annotation instructions instead, or hand a custom recipe that takes a scheme off
+to the coding agent (`/ellf-handoff`).
+
 `ner`, `spans` and `textcat` take their labels as the **Labels** field, switched between **List** (typed labels) and **Asset** (a
 scheme): an asset of kind
 `labels` holding one JSON file with the labels in order and an optional definition

{ellf_cli-19.0.0 → ellf_cli-19.0.3}/ellf_cli/ellf_skills/skills/ellf-annotate.assistant/references/label_schemes.md

@@ -8,6 +8,15 @@ Read this when designing labels for a project, when turning an agreed label set
 into something a task can use, or when writing annotation guidelines for labels
 that already exist.
 
+**Only some recipes take a scheme.** A scheme is a recipe argument, and the only
+built-in recipes that have it are `ner`, `spans` and `textcat` (`--label-scheme`, or
+**Asset** on the **Labels** field). A custom recipe can take one too, if it implements
+it with `props.label_scheme` (hand a new one off to the coding agent with `/ellf-handoff`). No other built-in recipe accepts a
+`labels` asset, so never suggest a scheme or `--label-scheme` for one of them. For
+those, write the label definitions into the annotation guidelines (an `instructions`
+asset) instead, or build a custom recipe if the definitions need to reach annotators
+and agents label by label.
+
 ## Format
 
 The file is a JSON object that maps each label to an object. The key order is the
@@ -89,13 +98,14 @@ Show it to the user and settle the labels before publishing.
   previewed from the Assets page and from the asset picker in recipe forms.
 - **Reuse:** check for an existing `labels` asset (`ellf assets list`, or the Assets
   page) before writing a new one. Use one scheme per label set, not one per task.
-- **Tasks:** the built-in `ner`, `spans` and `textcat` recipes take either a typed list
-  of labels (`--label A,B`) or a scheme (`--label-scheme <asset>`). In the web form, the
+- **Tasks:** only the built-in `ner`, `spans` and `textcat` recipes (and custom recipes
+  that implement it) take a scheme. They accept either a typed list of labels
+  (`--label A,B`) or a scheme (`--label-scheme <asset>`). In the web form, the
   **Labels** field switches between **List** and **Asset**. Prefer a scheme whenever
   the labels need explaining, are reused across tasks, or agents will annotate.
 - **Annotators** see a label's description when they hover the label in the annotation
   app (and on choice options for text classification).
-- **Agents:** a task passes its label definitions on to every LLM agent assigned to it
+- **Agents:** a task with a scheme passes its label definitions on to every LLM agent assigned to it
   (`gemini_agent`, `hf_llm_agent`), and they're included in each prompt: description,
   `do_not_mark` and the examples that fit the task type. An agent can have its own
   scheme on top (`--labels.scheme`), whose definitions replace the task's for the

{ellf_cli-19.0.0 → ellf_cli-19.0.3}/ellf_cli/ellf_skills/skills/ellf-annotate.coding/SKILL.md

@@ -199,4 +199,4 @@ When you finish:
 | `${CLAUDE_SKILL_DIR}/references/annotation_audit.md` | Readiness checklist: objective, schema, recipe fit, data, dataset | Before every launch |
 | `${CLAUDE_SKILL_DIR}/references/builtin_ellf_annotation_recipes.md` | Built-in Ellf task and agent recipes with supported workflows | Recipe selection for cluster |
 | `${CLAUDE_SKILL_DIR}/references/builtin_prodigy_recipes.md` | Built-in standalone Prodigy recipes | Recipe selection for local |
-| `${CLAUDE_SKILL_DIR}/references/label_schemes.md` | Label scheme (`labels` asset) format, design and use by tasks and agents | Labels need definitions, building them from annotated data, or writing guidelines |
+| `${CLAUDE_SKILL_DIR}/references/label_schemes.md` | Label scheme (`labels` asset) format, design and use by tasks and agents. Built-in `ner`, `spans` and `textcat` only | Labels need definitions, building them from annotated data, or writing guidelines |

{ellf_cli-19.0.0/ellf_cli/ellf_skills/skills/ellf-annotate.assistant → ellf_cli-19.0.3/ellf_cli/ellf_skills/skills/ellf-annotate.coding}/references/annotation_audit.md

@@ -41,7 +41,9 @@ passes.
 Labels that aren't self-evident need a written definition before launch: what the
 label covers, which look-alikes not to mark, and a few boundary examples. Keep them
 in a label scheme (a `labels` asset, see `label_schemes.md`) used by the task, so
-annotators see the descriptions and LLM agents get them in every prompt. If a label
+annotators see the descriptions and LLM agents get them in every prompt. Only the
+built-in `ner`, `spans` and `textcat` recipes (and custom recipes that implement it)
+take a scheme; for any other recipe, keep the definitions in the annotation guidelines. If a label
 can't be defined without "it depends", the schema isn't ready.
 
 ### Task complexity

{ellf_cli-19.0.0 → ellf_cli-19.0.3}/ellf_cli/ellf_skills/skills/ellf-annotate.coding/references/builtin_ellf_annotation_recipes.md

@@ -44,6 +44,11 @@ workflows.
 
 ## Label schemes
 
+Only `ner`, `spans` and `textcat` take a label scheme. No other built-in recipe accepts
+a `labels` asset, so don't suggest one for them: put the label definitions in the
+annotation instructions instead, or build a custom recipe that takes a scheme
+(`/ellf-prodigy`).
+
 `ner`, `spans` and `textcat` take their labels as `--label A,B` for a typed list, or `--label-scheme <asset>` for a scheme: an asset of kind
 `labels` holding one JSON file with the labels in order and an optional definition
 for each (description, look-alikes not to mark, examples). Prefer a scheme when the

{ellf_cli-19.0.0/ellf_cli/ellf_skills/skills/ellf-project.coding → ellf_cli-19.0.3/ellf_cli/ellf_skills/skills/ellf-annotate.coding}/references/label_schemes.md

@@ -8,6 +8,15 @@ Read this when designing labels for a project, when turning an agreed label set
 into something a task can use, or when writing annotation guidelines for labels
 that already exist.
 
+**Only some recipes take a scheme.** A scheme is a recipe argument, and the only
+built-in recipes that have it are `ner`, `spans` and `textcat` (`--label-scheme`, or
+**Asset** on the **Labels** field). A custom recipe can take one too, if it implements
+it with `props.label_scheme` (see `/ellf-prodigy`). No other built-in recipe accepts a
+`labels` asset, so never suggest a scheme or `--label-scheme` for one of them. For
+those, write the label definitions into the annotation guidelines (an `instructions`
+asset) instead, or build a custom recipe if the definitions need to reach annotators
+and agents label by label.
+
 ## Format
 
 The file is a JSON object that maps each label to an object. The key order is the
@@ -122,13 +131,14 @@ Show the draft to the user, settle it, then publish it and use it in the tasks.
   previewed from the Assets page and from the asset picker in recipe forms.
 - **Reuse:** check for an existing `labels` asset (`ellf assets list`, or the Assets
   page) before writing a new one. Use one scheme per label set, not one per task.
-- **Tasks:** the built-in `ner`, `spans` and `textcat` recipes take either a typed list
-  of labels (`--label A,B`) or a scheme (`--label-scheme <asset>`). In the web form, the
+- **Tasks:** only the built-in `ner`, `spans` and `textcat` recipes (and custom recipes
+  that implement it) take a scheme. They accept either a typed list of labels
+  (`--label A,B`) or a scheme (`--label-scheme <asset>`). In the web form, the
   **Labels** field switches between **List** and **Asset**. Prefer a scheme whenever
   the labels need explaining, are reused across tasks, or agents will annotate.
 - **Annotators** see a label's description when they hover the label in the annotation
   app (and on choice options for text classification).
-- **Agents:** a task passes its label definitions on to every LLM agent assigned to it
+- **Agents:** a task with a scheme passes its label definitions on to every LLM agent assigned to it
   (`gemini_agent`, `hf_llm_agent`), and they're included in each prompt: description,
   `do_not_mark` and the examples that fit the task type. An agent can have its own
   scheme on top (`--labels.scheme`), whose definitions replace the task's for the

{ellf_cli-19.0.0 → ellf_cli-19.0.3}/ellf_cli/ellf_skills/skills/ellf-ops.coding/references/data_infra_cli.md

@@ -131,7 +131,8 @@ This is the preferred way to upload local files to the cluster — it copies the
 
 Asset kinds that hold a single document: `instructions` (one Markdown file of
 annotation guidelines) and `labels` (one JSON label scheme, the labels of a task with
-their definitions). A label scheme is checked when a task or agent loads it, so
+their definitions; only the built-in `ner`, `spans` and `textcat` recipes, and custom
+recipes that implement it, take one). A label scheme is checked when a task or agent loads it, so
 validate the JSON locally before publishing:
 
 ```bash

{ellf_cli-19.0.0 → ellf_cli-19.0.3}/ellf_cli/ellf_skills/skills/ellf-project.assistant/SKILL.md

@@ -373,10 +373,12 @@ especially the annotation readiness checklist at the end of that section.
 - Review the user's proposed labels (or propose your own) against the factoring
   principle and schema design principles from the strategy reference. Challenge
   labels that mix business logic with language understanding.
-- Once the labels are settled, write them down as a label scheme: a `labels` JSON
+- Once the labels are settled, and the task will use the built-in `ner`, `spans` or
+  `textcat` recipe (or a custom recipe that takes a scheme), write them down as a label scheme: a `labels` JSON
   file with a description, `do_not_mark` look-alikes and a few boundary examples per
   label (format and design advice in `${CLAUDE_SKILL_DIR}/references/label_schemes.md`).
-  Check for an existing `labels` asset first. The scheme is a plan deliverable: tasks
+  Check for an existing `labels` asset first. No other built-in recipe takes a scheme:
+  for those, the definitions go into the annotation guidelines instead. The scheme is a plan deliverable: tasks
   take it as their labels, annotators see the descriptions, and the LLM agents get
   the definitions in every prompt. The user uploads it on the cluster's Assets page as kind `labels`, or
   hand publishing off with `/ellf-handoff`.

{ellf_cli-19.0.0/ellf_cli/ellf_skills/skills/ellf-project.coding → ellf_cli-19.0.3/ellf_cli/ellf_skills/skills/ellf-project.assistant}/references/explosion_strategy.md

@@ -297,9 +297,10 @@ Use this to sanity-check an annotation plan before committing to it:
 - Is training happening early, with diagnostics (train-curve) to validate
   whether more data of the same kind will help?
 - Has a pilot project been conducted and edge cases documented before scaling?
-- Are the labels written down as a label scheme (a `labels` asset with a
-  description, look-alikes not to mark and boundary examples per label), so
-  tasks, annotators and agents share one definition of each label?
+- Are the labels written down with a description, look-alikes not to mark and
+  boundary examples per label, so annotators and agents share one definition of
+  each label? As a label scheme (a `labels` asset) for `ner`, `spans` and
+  `textcat` tasks, which take one, and in the annotation guidelines otherwise.
 
 ---
 

{ellf_cli-19.0.0 → ellf_cli-19.0.3}/ellf_cli/ellf_skills/skills/ellf-project.assistant/references/label_schemes.md

@@ -8,6 +8,15 @@ Read this when designing labels for a project, when turning an agreed label set
 into something a task can use, or when writing annotation guidelines for labels
 that already exist.
 
+**Only some recipes take a scheme.** A scheme is a recipe argument, and the only
+built-in recipes that have it are `ner`, `spans` and `textcat` (`--label-scheme`, or
+**Asset** on the **Labels** field). A custom recipe can take one too, if it implements
+it with `props.label_scheme` (hand a new one off to the coding agent with `/ellf-handoff`). No other built-in recipe accepts a
+`labels` asset, so never suggest a scheme or `--label-scheme` for one of them. For
+those, write the label definitions into the annotation guidelines (an `instructions`
+asset) instead, or build a custom recipe if the definitions need to reach annotators
+and agents label by label.
+
 ## Format
 
 The file is a JSON object that maps each label to an object. The key order is the
@@ -89,13 +98,14 @@ Show it to the user and settle the labels before publishing.
   previewed from the Assets page and from the asset picker in recipe forms.
 - **Reuse:** check for an existing `labels` asset (`ellf assets list`, or the Assets
   page) before writing a new one. Use one scheme per label set, not one per task.
-- **Tasks:** the built-in `ner`, `spans` and `textcat` recipes take either a typed list
-  of labels (`--label A,B`) or a scheme (`--label-scheme <asset>`). In the web form, the
+- **Tasks:** only the built-in `ner`, `spans` and `textcat` recipes (and custom recipes
+  that implement it) take a scheme. They accept either a typed list of labels
+  (`--label A,B`) or a scheme (`--label-scheme <asset>`). In the web form, the
   **Labels** field switches between **List** and **Asset**. Prefer a scheme whenever
   the labels need explaining, are reused across tasks, or agents will annotate.
 - **Annotators** see a label's description when they hover the label in the annotation
   app (and on choice options for text classification).
-- **Agents:** a task passes its label definitions on to every LLM agent assigned to it
+- **Agents:** a task with a scheme passes its label definitions on to every LLM agent assigned to it
   (`gemini_agent`, `hf_llm_agent`), and they're included in each prompt: description,
   `do_not_mark` and the examples that fit the task type. An agent can have its own
   scheme on top (`--labels.scheme`), whose definitions replace the task's for the

{ellf_cli-19.0.0 → ellf_cli-19.0.3}/ellf_cli/ellf_skills/skills/ellf-project.assistant/references/prodigy_llm_bot.md

@@ -74,12 +74,14 @@ The LLM agents include the task's annotation instructions in their prompts by de
 so plan the guidelines as a Markdown `instructions` asset on the task: the same
 document serves annotators and agents, and an agent can add its own on top.
 
-They also annotate with the task's labels and use the task's label definitions. Plan
-the labels as a label scheme (a `labels` asset, see `label_schemes.md`) used by the
-task: every prompt then includes each label's description, what not to mark and the
+They also annotate with the task's labels and use the task's label definitions. If the
+task runs the built-in `ner`, `spans` or `textcat` recipe (the only built-ins that take
+one), plan the labels as a label scheme (a `labels` asset, see `label_schemes.md`) used
+by the task: every prompt then includes each label's description, what not to mark and the
 examples that fit the task type. An agent can add its own scheme on top, whose
 definitions replace the task's for the labels it defines, e.g. to correct a label the
 model keeps confusing without changing what annotators see. `hf_model_agent` doesn't
-use label definitions.
+use label definitions. Tasks on any other recipe can't take a scheme: put the label
+definitions in the instructions instead.
 
 The plan implications above apply to all of them.

{ellf_cli-19.0.0 → ellf_cli-19.0.3}/ellf_cli/ellf_skills/skills/ellf-project.coding/SKILL.md

@@ -388,10 +388,12 @@ especially the annotation readiness checklist at the end of that section.
 - Review the user's proposed labels (or propose your own) against the factoring
   principle and schema design principles from the strategy reference. Challenge
   labels that mix business logic with language understanding.
-- Once the labels are settled, write them down as a label scheme: a `labels` JSON
+- Once the labels are settled, and the task will use the built-in `ner`, `spans` or
+  `textcat` recipe (or a custom recipe that takes a scheme), write them down as a label scheme: a `labels` JSON
   file with a description, `do_not_mark` look-alikes and a few boundary examples per
   label (format and design advice in `${CLAUDE_SKILL_DIR}/references/label_schemes.md`).
-  Check for an existing `labels` asset first. The scheme is a plan deliverable: tasks
+  Check for an existing `labels` asset first. No other built-in recipe takes a scheme:
+  for those, the definitions go into the annotation guidelines instead. The scheme is a plan deliverable: tasks
   take it as their labels, annotators see the descriptions, and the LLM agents get
   the definitions in every prompt. Publish it with `ellf publish data ... --kind labels` once the user agrees.
 - Recommend the agile annotation workflow: pilot first, refine schema, train

{ellf_cli-19.0.0/ellf_cli/ellf_skills/skills/ellf-project.assistant → ellf_cli-19.0.3/ellf_cli/ellf_skills/skills/ellf-project.coding}/references/explosion_strategy.md

@@ -297,9 +297,10 @@ Use this to sanity-check an annotation plan before committing to it:
 - Is training happening early, with diagnostics (train-curve) to validate
   whether more data of the same kind will help?
 - Has a pilot project been conducted and edge cases documented before scaling?
-- Are the labels written down as a label scheme (a `labels` asset with a
-  description, look-alikes not to mark and boundary examples per label), so
-  tasks, annotators and agents share one definition of each label?
+- Are the labels written down with a description, look-alikes not to mark and
+  boundary examples per label, so annotators and agents share one definition of
+  each label? As a label scheme (a `labels` asset) for `ner`, `spans` and
+  `textcat` tasks, which take one, and in the annotation guidelines otherwise.
 
 ---
 

{ellf_cli-19.0.0/ellf_cli/ellf_skills/skills/ellf-annotate.coding → ellf_cli-19.0.3/ellf_cli/ellf_skills/skills/ellf-project.coding}/references/label_schemes.md

@@ -8,6 +8,15 @@ Read this when designing labels for a project, when turning an agreed label set
 into something a task can use, or when writing annotation guidelines for labels
 that already exist.
 
+**Only some recipes take a scheme.** A scheme is a recipe argument, and the only
+built-in recipes that have it are `ner`, `spans` and `textcat` (`--label-scheme`, or
+**Asset** on the **Labels** field). A custom recipe can take one too, if it implements
+it with `props.label_scheme` (see `/ellf-prodigy`). No other built-in recipe accepts a
+`labels` asset, so never suggest a scheme or `--label-scheme` for one of them. For
+those, write the label definitions into the annotation guidelines (an `instructions`
+asset) instead, or build a custom recipe if the definitions need to reach annotators
+and agents label by label.
+
 ## Format
 
 The file is a JSON object that maps each label to an object. The key order is the
@@ -122,13 +131,14 @@ Show the draft to the user, settle it, then publish it and use it in the tasks.
   previewed from the Assets page and from the asset picker in recipe forms.
 - **Reuse:** check for an existing `labels` asset (`ellf assets list`, or the Assets
   page) before writing a new one. Use one scheme per label set, not one per task.
-- **Tasks:** the built-in `ner`, `spans` and `textcat` recipes take either a typed list
-  of labels (`--label A,B`) or a scheme (`--label-scheme <asset>`). In the web form, the
+- **Tasks:** only the built-in `ner`, `spans` and `textcat` recipes (and custom recipes
+  that implement it) take a scheme. They accept either a typed list of labels
+  (`--label A,B`) or a scheme (`--label-scheme <asset>`). In the web form, the
   **Labels** field switches between **List** and **Asset**. Prefer a scheme whenever
   the labels need explaining, are reused across tasks, or agents will annotate.
 - **Annotators** see a label's description when they hover the label in the annotation
   app (and on choice options for text classification).
-- **Agents:** a task passes its label definitions on to every LLM agent assigned to it
+- **Agents:** a task with a scheme passes its label definitions on to every LLM agent assigned to it
   (`gemini_agent`, `hf_llm_agent`), and they're included in each prompt: description,
   `do_not_mark` and the examples that fit the task type. An agent can have its own
   scheme on top (`--labels.scheme`), whose definitions replace the task's for the

{ellf_cli-19.0.0 → ellf_cli-19.0.3}/ellf_cli/ellf_skills/skills/ellf-project.coding/references/prodigy_llm_bot.md

@@ -74,12 +74,14 @@ The LLM agents include the task's annotation instructions in their prompts by de
 so plan the guidelines as a Markdown `instructions` asset on the task: the same
 document serves annotators and agents, and an agent can add its own on top.
 
-They also annotate with the task's labels and use the task's label definitions. Plan
-the labels as a label scheme (a `labels` asset, see `label_schemes.md`) used by the
-task: every prompt then includes each label's description, what not to mark and the
+They also annotate with the task's labels and use the task's label definitions. If the
+task runs the built-in `ner`, `spans` or `textcat` recipe (the only built-ins that take
+one), plan the labels as a label scheme (a `labels` asset, see `label_schemes.md`) used
+by the task: every prompt then includes each label's description, what not to mark and the
 examples that fit the task type. An agent can add its own scheme on top, whose
 definitions replace the task's for the labels it defines, e.g. to correct a label the
 model keeps confusing without changing what annotators see. `hf_model_agent` doesn't
-use label definitions.
+use label definitions. Tasks on any other recipe can't take a scheme: put the label
+definitions in the instructions instead.
 
 The plan implications above apply to all of them.