lemming-cli 0.3.0__tar.gz → 0.3.2__tar.gz

{lemming_cli-0.3.0 → lemming_cli-0.3.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: lemming-cli
-Version: 0.3.0
+Version: 0.3.2
 Summary: An autonomous, iterative task runner for AI coding agents.
 Project-URL: Homepage, https://github.com/owahltinez/lemming
 Project-URL: Repository, https://github.com/owahltinez/lemming

{lemming_cli-0.3.0 → lemming_cli-0.3.2}/docs/HOOKS.md

@@ -155,11 +155,17 @@ Your hook template can use the following placeholders:
 
 - `{{roadmap}}`: A structured summary of the long-term goal and all tasks.
 - `{{finished_task}}`: Details about the task that just finished (ID,
-  description, progress, and the last 100 lines of its execution log).
+  description, recent progress, and a recent execution-log excerpt capped at
+  16 KiB).
 - `{{finished_task_id}}`: The ID of the task that just finished.
 - `{{tasks_file_name}}`: The filename of the tasks YAML file.
 - `{{tasks_file_path}}`: The full path to the tasks YAML file.
 
+Roadmap context is size-bounded and prioritizes current and actionable tasks
+over older completed history. Readability, testing, and UX hooks receive a
+smaller roadmap summary because their primary context is the finished task and
+the workspace.
+
 ## Developer Ergonomics
 
 ### Listing Hooks

{lemming_cli-0.3.0 → lemming_cli-0.3.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "lemming-cli"
-version = "0.3.0"
+version = "0.3.2"
 description = "An autonomous, iterative task runner for AI coding agents."
 readme = "README.md"
 authors = [

{lemming_cli-0.3.0 → lemming_cli-0.3.2}/src/lemming/api/tasks_test.py

@@ -30,6 +30,19 @@ def test_add_task(client, test_tasks):
     assert any(t.description == "New task from test" for t in roadmap.tasks)
 
 
+def test_add_task_rejects_oversized_description(client, test_tasks):
+    response = client.post(
+        "/api/tasks",
+        json={
+            "description": "x" * (tasks.MAX_TASK_DESCRIPTION_CHARS + 1),
+        },
+    )
+
+    assert response.status_code == 400
+    assert "2,001 characters (limit 2,000)" in response.json()["detail"]
+    assert len(tasks.load_tasks(test_tasks).tasks) == 3
+
+
 def test_add_task_with_runner(client, test_tasks):
     response = client.post(
         "/api/tasks", json={"description": "Runner task", "runner": "claude"}

{lemming_cli-0.3.0 → lemming_cli-0.3.2}/src/lemming/cli/progress_test.py

@@ -38,3 +38,23 @@ def test_progress(setup_env):
 
     data = tasks.load_tasks(tasks_file)
     assert "Observed behavior X" in data.tasks[0].progress
+
+
+def test_progress_reports_actionable_size_error(setup_env):
+    runner, base_args, tasks_file = setup_env
+
+    result = runner.invoke(
+        cli.cli,
+        base_args
+        + [
+            "progress",
+            "12345678",
+            "x" * (tasks.MAX_PROGRESS_ENTRY_CHARS + 1),
+        ],
+    )
+
+    assert result.exit_code == 1
+    assert "281 characters (limit 280)" in result.output
+    assert "Write detailed evidence or verbose command output" in result.output
+    assert str(tasks_file.parent) not in result.output
+    assert tasks.load_tasks(tasks_file).tasks[0].progress == []

{lemming_cli-0.3.0 → lemming_cli-0.3.2}/src/lemming/cli/tasks.py

@@ -645,11 +645,11 @@ def fail(ctx: click.Context, task_id: str):
         ctx.exit(1)
 
 
-@cli.command(short_help="<taskid> Stop an in-progress task")
+@cli.command(short_help="<taskid> Cancel a pending or active task")
 @click.argument("task_id")
 @click.pass_context
 def cancel(ctx: click.Context, task_id: str):
-    """Kills the runner and cancels an in-progress task."""
+    """Cancels a task, stopping its runner if it is active."""
     tasks_file = ctx.obj["TASKS_FILE"]
     if tasks.cancel_task(tasks_file, task_id):
         click.echo(f"Task {task_id} cancelled.")

{lemming_cli-0.3.0 → lemming_cli-0.3.2}/src/lemming/cli/tasks_test.py

@@ -51,6 +51,18 @@ class TestCLITasks(unittest.TestCase):
         task_descs = [t.description for t in data.tasks]
         self.assertIn("New Task", task_descs)
 
+    def test_add_task_reports_actionable_size_error(self):
+        result = self.cli_runner.invoke(
+            cli.cli,
+            self.base_args
+            + ["add", "x" * (tasks.MAX_TASK_DESCRIPTION_CHARS + 1)],
+        )
+
+        self.assertEqual(result.exit_code, 1)
+        self.assertIn("2,001 characters (limit 2,000)", result.output)
+        self.assertIn("Keep the brief task-specific", result.output)
+        self.assertEqual(len(tasks.load_tasks(self.test_tasks_file).tasks), 1)
+
     def test_edit_task_description(self):
         result = self.cli_runner.invoke(
             cli.cli,

{lemming_cli-0.3.0 → lemming_cli-0.3.2}/src/lemming/models.py

@@ -60,6 +60,8 @@ class Task(pydantic.BaseModel):
     created_at: float = pydantic.Field(default_factory=time.time)
     run_time: float = 0.0
     execution_times: dict[str, float] | None = None
+    active_execution_component: str | None = None
+    active_execution_started_at: float | None = None
     pid: int | None = None
     last_heartbeat: float | None = None
     has_runner_log: bool = False

{lemming_cli-0.3.0 → lemming_cli-0.3.2}/src/lemming/models_test.py

@@ -19,6 +19,8 @@ def test_task_model_defaults():
     assert task.progress == []
     assert task.run_time == 0.0
     assert task.execution_times is None
+    assert task.active_execution_component is None
+    assert task.active_execution_started_at is None
     assert task.superseded_at is None
     assert task.superseded_reason is None
     assert task.created_at > 0

{lemming_cli-0.3.0 → lemming_cli-0.3.2}/src/lemming/orchestrator.py

@@ -357,8 +357,14 @@ def _handle_runner_exit(
                 click.echo(stderr, err=True)
 
         if returncode == -15:
+            if post_task.status == tasks.TaskStatus.CANCELLED:
+                if verbose:
+                    click.echo("Task was cancelled. Continuing orchestrator.")
+                return False
             if verbose:
-                click.echo("Task was cancelled. Stopping orchestrator loop.")
+                click.echo(
+                    "Runner exited after SIGTERM. Stopping orchestrator loop."
+                )
             return True
 
         if runner_failed and not post_task.requested_status:

{lemming_cli-0.3.0 → lemming_cli-0.3.2}/src/lemming/orchestrator_test.py

@@ -483,7 +483,9 @@ def test_handle_runner_exit_completes(mock_sleep, mock_run_hooks, setup_env):
 
 
 @mock.patch("lemming.orchestrator.run_hooks")
-def test_handle_runner_exit_cancelled(mock_run_hooks, setup_env):
+def test_handle_runner_exit_stops_on_unexpected_sigterm(
+    mock_run_hooks, setup_env
+):
     test_tasks_file, initial_data = setup_env
     data = tasks.load_tasks(test_tasks_file)
     task = data.tasks[0]
@@ -507,7 +509,38 @@ def test_handle_runner_exit_cancelled(mock_run_hooks, setup_env):
         working_dir=None,
         time_limit=1,
     )
-    assert should_abort, "Cancellation (-15) should abort the loop"
+    assert should_abort
+
+
+@mock.patch("lemming.orchestrator.run_hooks")
+def test_handle_runner_exit_continues_after_cancellation(
+    mock_run_hooks, setup_env
+):
+    test_tasks_file, initial_data = setup_env
+    data = tasks.load_tasks(test_tasks_file)
+    task = data.tasks[0]
+    task.status = tasks.TaskStatus.CANCELLED
+    tasks.save_tasks(test_tasks_file, data)
+
+    should_abort = _handle_runner_exit(
+        test_tasks_file,
+        task.id,
+        returncode=-15,
+        stdout="",
+        stderr="",
+        retries=3,
+        retry_delay=5,
+        runner_name="agy",
+        yolo=True,
+        runner_args=(),
+        no_defaults=False,
+        verbose=False,
+        active_hooks=[],
+        working_dir=None,
+        time_limit=1,
+    )
+
+    assert not should_abort
 
 
 @mock.patch("lemming.orchestrator.time.sleep")

{lemming_cli-0.3.0 → lemming_cli-0.3.2}/src/lemming/prompts/hooks/90-roadmap.md

@@ -49,16 +49,21 @@ the plan up-to-date with minimal friction.
     forgotten teardowns, missing tests reported by the testing hook, or
     formatting issues reported by the readability hook), add new tasks to
     address them.
-7.  **No Code Changes**: Your only persistent changes may be to the roadmap via
+7.  **Task-Specific Briefs**: Keep new or rewritten task descriptions concise,
+    self-contained, and no more than {{max_task_description_chars}} characters.
+    Include the concrete files, symbols, motivation, and acceptance criteria the
+    task needs, but do not repeat project-wide rules already present in the
+    long-term goal.
+8.  **No Code Changes**: Your only persistent changes may be to the roadmap via
     the `lemming` CLI. Do NOT edit source or configuration files. Reading the
-    workspace and running existing build, test, and entry-point commands for the
-    queue-drain audit is explicitly allowed.
-8.  **Fast Exit**: If the roadmap is accurate and well-structured, AND there are
-    no failed tasks that have reached their maximum attempts, you may exit
-    immediately without running any commands. The queue-drain audit in directive
-    4 must finish before this clause applies. If a task is marked as FAILED and
-    has reached its maximum attempts, a Fast Exit will result in the entire
-    project ABORTING. In that case, you MUST repair it.
+    workspace and running existing build, test, and entry-point commands for
+    the queue-drain audit is explicitly allowed.
+9.  **Fast Exit**: If the roadmap is accurate and well-structured, AND there
+    are no failed tasks that have reached their maximum attempts, you may exit
+    immediately without running any commands. The queue-drain audit in
+    directive 4 must finish before this clause applies. If a task is marked as
+    FAILED and has reached its maximum attempts, a Fast Exit will result in the
+    entire project ABORTING. In that case, you MUST repair it.
 
 ## Commands
 

{lemming_cli-0.3.0 → lemming_cli-0.3.2}/src/lemming/prompts/taskrunner.md

@@ -36,33 +36,33 @@ Your CURRENT, EXCLUSIVE task is: **{{description}}**
      a fresh, empty conversation history. Their only context is the global
      roadmap, previously recorded progress from completed tasks, and the state
      of the file system.
-   - **Self-Contained Descriptions:** Because of this isolation, you MUST write
-     extremely thorough, self-contained descriptions for any new tasks you
-     schedule. Reference specific task IDs, file paths, and exact symbols so the
-     new task knows exactly what to do.
-   - **Complex Handoffs:** If you need to pass extensive context (like detailed
-     architectural plans, specific error traces, or large code snippets) to a
-     downstream task, do not rely on the brief progress messages alone. Instead,
-     create a dedicated file in the workspace to hold this context, and
-     explicitly mention its path in the new task's description. Use this
-     technique judiciously to avoid creating a mess of orphaned files in the
-     project.
+   - **Task-Specific Descriptions:** New task descriptions must be concise,
+     self-contained, and no more than {{max_task_description_chars}} characters.
+     Include the file paths, symbols, motivation, and acceptance criteria that
+     task needs, but do not restate project-wide rules already present in the
+     long-term goal.
+   - **Detailed Evidence:** Keep verbose gate output, transcripts, error traces,
+     and other ephemeral evidence in `{{tasks_dir}}`, which is Lemming's
+     per-project scratch directory outside the workspace. Reference the file
+     from a task description or progress entry when another attempt needs it.
+     Put conclusions that must outlive the task in the commit message or a
+     decision document in the repository.
 
-4. **Progress:** Your first action should be to record a brief progress entry
-   describing how you intend to approach this task — e.g. which files you will
-   modify, what strategy you will use. This lets the operator verify your
-   direction early. Then continue recording progress as you work: each time you
-   complete a meaningful step, discover something relevant, or hit a problem,
-   record it immediately. If your process is killed, recorded progress carries
-   over to the next attempt. At least one progress entry is required before
+4. **Progress:** Your first action should be to record a one-line progress entry
+   describing your approach. Continue recording concise findings as you work,
+   but keep each entry to one line and no more than
+   {{max_progress_entry_chars}} characters. Do not paste command output or
+   detailed evidence into progress; write it under `{{tasks_dir}}` and reference
+   the file instead. If your process is killed, recorded progress carries over
+   to the next attempt. At least one progress entry is required before
    completing or failing a task:
    `lemming --tasks-file {{tasks_file_path}} progress {{task_id}} '<what you did or found>'`
 5. **Success:** When you have completely finished and verified the task, and
-   recorded ALL relevant progress (at least one is required), run:
+   recorded relevant progress (at least one entry is required), run:
    `lemming --tasks-file {{tasks_file_path}} complete {{task_id}}`
 6. **Failure/Blocker:** If you hit a technical roadblock, cannot fix a bug, or
-   are unable to complete the task, after recording ALL relevant progress (at
-   least one is required), run:
+   are unable to complete the task, after recording relevant progress (at least
+   one entry is required), run:
    `lemming --tasks-file {{tasks_file_path}} fail {{task_id}}`
 
 7. Stop and exit after running either the complete or fail command.