Merge branch 'main' into dependabot/npm_and_yarn/ws-8.21.0

Author: dadmobile

.agents/skills/transformerlab-cli/SKILL.md

@@ -762,7 +762,7 @@ Also note that secrets passed inside `--config` (e.g. `api_token`, `azure_client
 9. **`job task-logs --follow`** streams continuously and blocks until the job finishes — use when the user wants real-time monitoring
 10. **Never use the deprecated `lab job logs`** — see the "Job logs: three real commands" section below.
 11. **Before queuing a task, CONFIRM the experiment with the user.** Run `lab config` to read the current default and `lab --format json experiment list` to verify it exists, then ask: "I'm about to queue this under experiment `<name>` (your current default). OK, or pick another?" Show 2–3 alternatives from `experiment list` if the current one looks stale or missing. Skip the confirmation only when the user has already named the experiment in this turn.
-12. **After queuing a task, ASK the user if they'd like you to watch the logs.** Don't start streaming or polling automatically — jobs can take minutes to hours, and `--follow` blocks. Report the Job ID and ask: "Want me to watch the logs and report back?"
+12. **After queuing a task, ASK the user if they'd like you to watch the logs.** Don't start streaming or polling automatically — jobs can take minutes to hours, and `--follow` blocks. Report the Job ID and ask: "Want me to watch the logs and report back?" If they say yes and your harness can self-schedule (e.g. Claude Code's `ScheduleWakeup`), watch by checking once per turn and scheduling the next check — not a blocking `--follow` or a `while`/`sleep`/background poll loop, which can strand the session with a finished job (see workflows.md "Polling Pattern for Agents").
 13. **Never create API keys programmatically** — if auth fails, ask the user to provide an API key from the web UI
 14. **Always pass `--description/-m` when queuing a task. Generate it yourself — never ask the user.** See "Always write a run description" below.
 

.agents/skills/transformerlab-cli/references/autoresearch.md

@@ -250,6 +250,7 @@ The agent loops autonomously. Never ask "should I continue?" — keep going unti
 6. **Advance.** What this means depends on parallelism:
    - **N = 1 (sequential):** wait for the just-queued job to finish, then go to step 7. Poll with `lab --format json job list --running`.
    - **N ≥ 2 (parallel / fire-and-advance):** **do not wait.** Return to step 0 and pick the next idea immediately, until `RUNNING >= N`. Only block when the queue is full. This is what enables grid-style search; waiting after every queue collapses parallelism back to 1.
+   - **How to "wait" / "block" without stranding the session:** don't hold the turn open with a `while`/`sleep` or `run_in_background` poll loop — on remote providers the harness can't track the job, so a loop that ends before the job finishes leaves the session idle until a manual nudge. If your harness can self-schedule (e.g. Claude Code's `ScheduleWakeup`), do **one** `lab job list --running` / `job info` check, then schedule the next check and end the turn, repeating until a job is terminal. The bare poll loop is the fallback for scripts/cron and agents without self-scheduling.
 7. **Score → keep or discard** any *completed* jobs whose results haven't been processed yet. In parallel mode, this means scanning recently-finished jobs at the start of each cycle, not just the one you queued last.
    ```bash
    # Find COMPLETE jobs we haven't acted on yet (no discard flag set, not the current best).

.agents/skills/transformerlab-cli/references/workflows.md

@@ -188,6 +188,13 @@ lab --format json job info JOB_ID
 
 ### Polling Pattern for Agents
 
+> **Interactive agents: prefer your harness's scheduler over this loop.** The `while`/`sleep`
+> loop below blocks a whole turn, and run in the background it can be orphaned by a user
+> message — either way it can leave the session idle with a finished job unnoticed. If your
+> harness can self-schedule a wake (e.g. Claude Code's `ScheduleWakeup`), do **one** `lab job
+> info` check per turn, then schedule the next check and end the turn, repeating until terminal.
+> The blocking loop below is the fallback for scripts, cron, and agents without self-scheduling.
+
 When monitoring a job programmatically, use this pattern:
 
 ```bash

.agents/skills/transformerlab-cli/templates/queue-and-monitor.sh

@@ -2,6 +2,10 @@
 # Template: Queue a task and monitor until completion
 # Queues a task non-interactively, polls for job completion, and downloads results.
 #
+# NOTE: this blocking poll loop is for scripts/cron. An interactive agent should NOT run it
+# in-session — a self-scheduling harness (e.g. Claude Code's ScheduleWakeup) should check once
+# per turn and reschedule instead, so a finished job can't strand the session.
+#
 # Usage: ./queue-and-monitor.sh <task_id> [output_dir]
 #
 # Arguments: