flyloft 0.2.0__tar.gz → 0.2.2__tar.gz

{flyloft-0.2.0 → flyloft-0.2.2}/.github/workflows/ci.yml

@@ -76,11 +76,14 @@ jobs:
 
   client:
     runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        python: ["3.11", "3.12"]
     steps:
       - uses: actions/checkout@v4
         with:
           fetch-depth: 0
       - uses: astral-sh/setup-uv@v6
-      - run: uv venv client-venv && uv pip install --python client-venv/bin/python .
+      - run: uv venv client-venv --python ${{ matrix.python }} && uv pip install --python client-venv/bin/python .
       - run: client-venv/bin/flyloft --help
-      - run: client-venv/bin/flyloft install-skill
+      - run: client-venv/bin/flyloft install --harness claude

{flyloft-0.2.0 → flyloft-0.2.2}/PKG-INFO

@@ -1,8 +1,8 @@
 Metadata-Version: 2.5
 Name: flyloft
-Version: 0.2.0
+Version: 0.2.2
 Summary: Agent swarms for empirical research on Slurm clusters
-Requires-Python: >=3.12
+Requires-Python: >=3.11
 Requires-Dist: httpx>=0.27
 Requires-Dist: typer>=0.12
 Provides-Extra: server

{flyloft-0.2.0 → flyloft-0.2.2}/docs/ARCHITECTURE.md

@@ -1,6 +1,6 @@
 # flyloft Architecture
 
-Status: approved 2026-09-21. Stage 1 complete on 2026-09-23 (see [design/stage-1.md](design/stage-1.md)); stage 2 complete on 2026-09-23 (tiers one, two, and three passed; see [design/stage-2.md](design/stage-2.md)); stage 3a complete (see [design/stage-3a.md](design/stage-3a.md)). Stage 3b complete (see [design/stage-3b.md](design/stage-3b.md)). Stage 4a complete on 2026-09-25 (tiers one, two, and three passed; see [design/stage-4a.md](design/stage-4a.md)). Stage 4b complete on 2026-09-25 (tiers one, two, and three passed; see [design/stage-4b.md](design/stage-4b.md)). Stage 5a complete on 2026-09-27 (tiers one, two, and three passed; see [design/stage-5a.md](design/stage-5a.md)). Stage 5b complete on 2026-09-27 (tiers one and three passed; see [design/stage-5b.md](design/stage-5b.md)). Stage 5c complete on 2026-09-28 (tiers one and three passed; see [design/stage-5c.md](design/stage-5c.md)). Stage 5d complete on 2026-09-28 (tiers one and three passed; see [design/stage-5d.md](design/stage-5d.md)). Stage 6a complete on 2026-09-29 (tiers one and three passed; see [design/stage-6a.md](design/stage-6a.md)). Stage 6b complete on 2026-09-30 (tiers one and three passed; see [design/stage-6b.md](design/stage-6b.md)). Stage 7 complete on 2026-09-30 (tiers one, two, and three passed; see [design/stage-7.md](design/stage-7.md)). Every staged part is built. The vision's revision of 2026-10-13 widens flyloft to two modes, investigate and optimize, with a lab-wide toolshed; what comes next is in §6, *What comes next*. The Projects rework's board flow and template repositories are built and closed on 2026-10-19 (tiers one, two, and three passed; see [design/projects.md](design/projects.md)); the investigate mode is next, in four parts, the first built (see [design/investigate.md](design/investigate.md)); then the agent interface, where the researcher's own coding agent starts work and the board is where they come back to (see [design/agent-interface.md](design/agent-interface.md)).
+Status: approved 2026-09-21. Stage 1 complete on 2026-09-23 (see [design/stage-1.md](design/stage-1.md)); stage 2 complete on 2026-09-23 (tiers one, two, and three passed; see [design/stage-2.md](design/stage-2.md)); stage 3a complete (see [design/stage-3a.md](design/stage-3a.md)). Stage 3b complete (see [design/stage-3b.md](design/stage-3b.md)). Stage 4a complete on 2026-09-25 (tiers one, two, and three passed; see [design/stage-4a.md](design/stage-4a.md)). Stage 4b complete on 2026-09-25 (tiers one, two, and three passed; see [design/stage-4b.md](design/stage-4b.md)). Stage 5a complete on 2026-09-27 (tiers one, two, and three passed; see [design/stage-5a.md](design/stage-5a.md)). Stage 5b complete on 2026-09-27 (tiers one and three passed; see [design/stage-5b.md](design/stage-5b.md)). Stage 5c complete on 2026-09-28 (tiers one and three passed; see [design/stage-5c.md](design/stage-5c.md)). Stage 5d complete on 2026-09-28 (tiers one and three passed; see [design/stage-5d.md](design/stage-5d.md)). Stage 6a complete on 2026-09-29 (tiers one and three passed; see [design/stage-6a.md](design/stage-6a.md)). Stage 6b complete on 2026-09-30 (tiers one and three passed; see [design/stage-6b.md](design/stage-6b.md)). Stage 7 complete on 2026-09-30 (tiers one, two, and three passed; see [design/stage-7.md](design/stage-7.md)). Every staged part is built. The vision's revision of 2026-10-13 widens flyloft to two modes, investigate and optimize, with a lab-wide toolshed; what comes next is in §6, *What comes next*. The Projects rework's board flow and template repositories are built and closed on 2026-10-19 (tiers one, two, and three passed; see [design/projects.md](design/projects.md)); the investigate mode is next, in four parts, the first built (see [design/investigate.md](design/investigate.md)); then the agent interface, where the researcher's own coding agent starts work and the board is where they come back to (see [design/agent-interface.md](design/agent-interface.md)). A critic-judged campaign's 0-GPU runs go to its cluster's CPU partition, sized within a CPU-run limit (see [design/cpu-partition.md](design/cpu-partition.md)).
 
 This document settles the shape of flyloft: the record that holds its state, the lifecycle and authority rules, the agent turn, the subsystem boundaries, and the stages by which the system grows. It fixes what is expensive to change later and leaves everything else to the design document of the stage that needs it. [VISION.md](VISION.md) says what flyloft is for; [AGENTS.md](../AGENTS.md) says how to work on it. This document is the bridge between them.
 
@@ -197,7 +197,7 @@ Two processes write to the record from the first turn, the service and the tool
 
 **The Compute page.** After campaign-level compute, its own change ([design/compute.md](design/compute.md)): a sidebar page where each cluster says what each GPU type its file lists has (free GPUs, flyloft's running and queued jobs, nodes, CPUs, memory, longest run, and most free on a node), cached for 30 seconds and asked per cluster over the runs module's SSH client; the launch page's GPU type select shows each type's free count.
 
-**What comes next.** The vision's revision of 2026-10-13 widens flyloft from optimization to two modes, investigate and optimize, and adds a toolshed shared across the lab. Stages 1 through 7 built the optimize mode. What follows is staged like everything before it, each part with its own scenario and a design document written when it begins: the Projects rework, which makes bringing a project one flow on the board and turns templates into GitHub template repositories registered with flyloft (see [design/projects.md](design/projects.md)); then the investigate mode, in four parts: a solo, exploratory investigation whose project may be only a brief ([design/investigate.md](design/investigate.md)); a test fixed in advance, making findings confirmed; the toolshed; and investigation at swarm size. Then the agent interface ([design/agent-interface.md](design/agent-interface.md)): the researcher's coding agent is flyloft's front door (sign-in from a laptop, `submit` of a brief that flyloft turns into a repository and a campaign, a `flyloft` client with every initiating action, a skill), the host's commands move under `flyloft host` and admin actions under `flyloft admin`, and the board becomes where people monitor and steer; its second part adds tasks, a third label on the investigation engine. Their mechanics are decided in their design documents, not here.
+**What comes next.** The vision's revision of 2026-10-13 widens flyloft from optimization to two modes, investigate and optimize, and adds a toolshed shared across the lab. Stages 1 through 7 built the optimize mode. What follows is staged like everything before it, each part with its own scenario and a design document written when it begins: the Projects rework, which makes bringing a project one flow on the board and turns templates into GitHub template repositories registered with flyloft (see [design/projects.md](design/projects.md)); then the investigate mode, in four parts: a solo, exploratory investigation whose project may be only a brief ([design/investigate.md](design/investigate.md)); a test fixed in advance, making findings confirmed; the toolshed; and investigation at swarm size. Then the agent interface ([design/agent-interface.md](design/agent-interface.md)): the researcher's coding agent is flyloft's front door (sign-in from a laptop, `submit` of a brief that flyloft turns into a repository and a campaign, a `flyloft` client with every initiating action, a skill), the host's commands move under `flyloft host` and admin actions under `flyloft admin`, and the board becomes where people monitor and steer; its second part adds tasks, a third label on the investigation engine ([design/tasks.md](design/tasks.md)); both are built and closed (2026-10-22). Their mechanics are decided in their design documents, not here.
 
 Recovery is built when a stage loses work, most likely stage three, when a service restart first interrupts many turns at once. It is not scheduled.
 
@@ -377,16 +377,21 @@ Ideas that have arrived before their stage. Adding a line here is how an impulse
 | Searching or filtering the template list in New project | When a lab has more templates than fit on a screen |
 | Memory reading investigations: an earlier investigation's account and findings in a later campaign's assignment (today memory skips investigations both ways) | When an optimize campaign follows an investigation on the same project |
 | A size cap on an investigation run's collected `out/` | When a run is seen copying something large back to the host |
+| Computed completion for tasks: a checklist the ask is parsed into | When critics are seen accepting incomplete outputs |
 | Two campaigns writing a project's work directory at once | When two are seen colliding there |
 | An "Empty project" choice on New project that writes the brief on the board and creates the repository | Superseded by `flyloft submit`: see [design/agent-interface.md](design/agent-interface.md) |
 | The toolshed (part 3 of investigate) and a data equivalent: where the lab's datasets live, how they are versioned, what has been fetched and prepared | Near-term, after the agent interface; each its own design |
 | A Claude Code plugin and marketplace for the flyloft skill (the skill's directory plus a manifest) | When a lab member wants it from a marketplace, or a hook or second component is needed |
-| The flyloft skill for Codex and OpenCode | When a lab member uses one |
+| The flyloft skill for Codex and OpenCode | Done 2026-10-22: `flyloft install` serves every harness found |
 | `flyloft logout`, several hosts per laptop, refreshing a session before it expires | When one is missed |
 | Deleting the board's initiation flows (New project, registration, the launch wizard) and the database-direct `flyloft host campaign` and `host project` commands | When the agent interface is seen to cover what people and operators use them for |
 | flyloft as a monitor and troubleshooter of the lab's compute, from what it already observes (node and job states, failure diagnostics, capacity) | When the agent interface and tasks are in use |
 | HTTPS for the board and the client (a 30-day session crosses the intranet in the clear: an accepted risk for the first version, see [design/agent-interface.md](design/agent-interface.md) §3) | When the host leaves netbird or a lab policy asks |
 | An MCP catalogue of knowledge sources (bioRxiv, PubMed, ChEMBL) for flyloft's own agents: per-role permissions, credentials, and what a source returned on the record; with the toolshed, in one lab-owned repository | With the toolshed, when the first investigation needs a source its agents cannot reach |
+| A CPU row on the Compute page and in `flyloft options` ([design/cpu-partition.md](design/cpu-partition.md) §6) | When a launch goes wrong for want of it |
+| A CPU budget ([design/cpu-partition.md](design/cpu-partition.md) §6) | When CPU work on the shared node needs a bound beyond run slots and the CPU-run limit |
+| Choosing a GPU type per run within a campaign; budgeting must then weigh the types ([design/cpu-partition.md](design/cpu-partition.md) §6) | When a campaign needs two GPU types |
+| The request and the render of a CPU run disagreeing when `cpu_partition` changes while a run is preparing; the fix is to key `_is_cpu_run` on `run.cpus is not None` | When it is observed |
 
 ## References
 

{flyloft-0.2.0 → flyloft-0.2.2}/docs/NEW_PROJECT.md

@@ -70,9 +70,9 @@ What follows from it:
       training loop, evaluation, and output), only smaller: a smoke path that skips the evaluation hides the bugs
       validation exists to find.
 
-## 2a. A project for investigation
+## 2a. A project for investigation or a task
 
-A researcher who wants a question investigated, not a metric optimized, needs no run command. The repository may hold
+A researcher who wants a question investigated or a task done, not a metric optimized, needs no run command. The repository may hold
 only its brief: the agents write everything else on the campaign branch. The brief says:
 
 - what the project is and the question's background, in a paragraph;
@@ -81,14 +81,14 @@ only its brief: the agents write everything else on the campaign branch. The bri
 - what agents must not do (no training on a held-out set, no more than one GPU per run).
 
 The usual path is `flyloft submit` from the researcher's own agent: on the researcher's laptop, `pip install flyloft`,
-`flyloft login --host <board URL>`, and `flyloft install-skill --harness claude-code` give the agent the flyloft skill,
-whose `handoff.md` holds the brief template. The agent writes the brief and an investigation file, runs
+`flyloft login --host <board URL>`, and `flyloft install` give the agent (Claude Code, Codex, or OpenCode) the flyloft skill,
+whose `handoff.md` holds the brief template. The agent writes the brief and an investigation or task file, runs
 `flyloft submit <directory> --name <name> --campaign <file> --check` until it reports no problem, and submits: flyloft
-creates the repository under the lab's organization, registers the project, and launches the investigation.
+creates the repository under the lab's organization, registers the project, and launches the campaign. A task is submitted the same way: `task.toml` with `type = "task"`, and the brief says what needs doing and what done looks like.
 
 To register a repository by hand instead, use **My own repository** on **New project**, or `flyloft register <url>
 --name <name>`, leaving the run command and results path blank; there is nothing to validate. Launch it with
-**Investigate a question**. Every job an investigation runs has
+**Investigate a question** or **Do a task**. Every job a critic-judged campaign runs has
 `$FLYLOFT_PROJECT_WORK`, the project's directory on the cluster, where environments, weights, and data stay for later
 campaigns, and `$FLYLOFT_OUT`, whose contents come back to the board. When the account recommends an optimization, add
 a run command that meets section 2, validate it, and launch **Optimize a metric** on the same project: what the

{flyloft-0.2.0 → flyloft-0.2.2}/docs/design/agent-interface.md

@@ -24,7 +24,7 @@ VISION.md was revised with the human section by section on 2026-10-20: the openi
 
 ## 2. Scenario
 
-*Once per researcher.* `pip install flyloft` on the laptop; `flyloft install-skill --harness claude-code`; `flyloft login --host http://<board>`: a device code appears, they approve on GitHub, and the client prints "signed in to flyloft as briney". Someone not on the allowlist is refused with who to ask.
+*Once per researcher.* `pip install flyloft` on the laptop; `flyloft install` (the skill, into every harness found: Claude Code, Codex, OpenCode); `flyloft login --host http://<board>`: a device code appears, they approve on GitHub, and the client prints "signed in to flyloft as briney". Someone not on the allowlist is refused with who to ask.
 
 *The slow cooker.*
 
@@ -57,7 +57,7 @@ The laptop holds only a flyloft session, never a GitHub token. The GitHub token
 
 **Transport.** The host's network is the lab's intranet, and the board stays plain HTTP: an accepted risk for the first version, since a 30-day session crosses that network in the clear. HTTPS is on the deferred list, to be picked up when the host leaves netbird or a lab policy asks.
 
-**Versions.** Every request carries `X-Flyloft-Client: <version>` and every reply `X-Flyloft-Host: <version>`, both the one package's version. The host holds `MIN_CLIENT`, bumped whenever the API changes incompatibly; an older client gets 426 with "your flyloft client is 1.4.0; this host needs 1.6.0 or newer: `pip install -U flyloft`", which the skill treats as an instruction. A client newer than the host prints one warning line ("this host runs 1.5.0; some commands may not work") and continues; the API rejects unknown request fields rather than dropping them, so a new field never vanishes quietly. `install-skill` writes the client's version into `SKILL.md`, and the client warns once per command when the installed skill's version differs ("run `flyloft install-skill`"). No compatibility framework beyond this: one supported pairing, the newest of each.
+**Versions.** Every request carries `X-Flyloft-Client: <version>` and every reply `X-Flyloft-Host: <version>`, both the one package's version. The host holds `MIN_CLIENT`, bumped whenever the API changes incompatibly; an older client gets 426 with "your flyloft client is 1.4.0; this host needs 1.6.0 or newer: `pip install -U flyloft`", which the skill treats as an instruction. A client newer than the host prints one warning line ("this host runs 1.5.0; some commands may not work") and continues; the API rejects unknown request fields rather than dropping them, so a new field never vanishes quietly. `install` writes the client's version into `SKILL.md`, and the client warns once per command when the installed skill's version differs ("run `flyloft install`"). No compatibility framework beyond this: one supported pairing, the newest of each.
 
 ## 4. `submit` on the host
 
@@ -101,7 +101,7 @@ The reply carries the project, the repository URL, the campaign id, and the boar
 | `stop ID` | `POST /api/campaigns/{id}/stop` |
 | `admin user list / add LOGIN [--admin] / remove LOGIN / promote LOGIN / demote LOGIN` | `GET/POST/PATCH/DELETE /api/users…`, 403 for a non-admin |
 | `admin user logout LOGIN` | `DELETE /api/users/{login}/sessions` |
-| `install-skill --harness claude-code` | copies the packaged skill to `~/.claude/skills/flyloft/`, overwriting, with the client's version written in |
+| `install [--harness claude\|codex\|opencode]` | copies the packaged skill, with the client's version written in, to `~/.claude/skills/flyloft/` for Claude Code and `~/.agents/skills/flyloft/` for Codex and OpenCode (both read it); without `--harness`, every harness whose CLI is on `PATH`; overwriting |
 
 `status` with no id lists the researcher's campaigns, one line each (state, kind, project, what is running or the latest finding, budget); with an id it shows the experiments or runs, the findings, the budget, the notes, and the account once written.
 
@@ -120,12 +120,12 @@ The client ships in the existing `flyloft` package. The researcher's commands ar
 5. **Checking in**: `status`, then `status ID`, leading with the account when there is one. `steer` and `stop` only when asked.
 6. **Graduating**, when an account recommends an optimization and the researcher wants it: the investigation's code is on its branch behind a draft pull request, so have the researcher review and merge it first; then clone, wire the contract, push, `project set`, `validate` (read the report; fix what it names), `launch` with the metric and target the account named.
 7. **Bringing an existing repository**: the contract, `register`, `validate`, `launch`.
-8. **Refusals** are the host's own sentences: fix what they name and retry; never work around one, such as by creating a repository by hand. A 426 means the client is too old: run `pip install -U flyloft` and retry; a skill-version warning means `flyloft install-skill`.
+8. **Refusals** are the host's own sentences: fix what they name and retry; never work around one, such as by creating a repository by hand. A 426 means the client is too old: run `pip install -U flyloft` and retry; a skill-version warning means `flyloft install`.
 9. **Administering**, only when the researcher is an admin and asks: `flyloft admin user …`; a 403 means they are not.
 
 ## 7. The board, `flyloft host`, and `flyloft admin`
 
-The board shows every project and campaign and lets people steer and stop. This part adds a "Start new work from your agent" panel under the home page's campaign list (also its empty state): `pip install flyloft`, `flyloft login --host <this board's URL>`, `flyloft install-skill --harness claude-code`, with the URL filled in; the launch page's first line points to it. The Admin page gains "end every session" per user. New project, registration, and the launch wizard stay as they are.
+The board shows every project and campaign and lets people steer and stop. This part adds a "Start new work from your agent" panel under the home page's campaign list (also its empty state): `pip install flyloft`, `flyloft login --host <this board's URL>`, `flyloft install`, with the URL filled in; the launch page's first line points to it. The Admin page gains "end every session" per user. New project, registration, and the launch wizard stay as they are.
 
 `flyloft host` holds every host-side operator command, unchanged in behavior: `serve`, `web`, `up`, `init`, `doctor`, `db migrate`, host `status`, the operator's `login`, the database-direct `campaign` and `project` groups, and `user`, which is the bootstrap: `flyloft host user add --admin LOGIN` makes the first admin on a fresh host, before anyone can sign in; afterwards admins use `flyloft admin user …` over the API, from anywhere. `flyloft admin` holds only what needs the admin role.
 
@@ -135,7 +135,7 @@ The board shows every project and campaign and lets people steer and stop. This
 
 **Tier one** (`tests/e2e/test_agent_interface.py`: the fake cluster, the stand-in GitHub with device endpoints and organization repositories, scripted agents; the client through `CliRunner` against the board app served over HTTP, as the browser tests serve it):
 
-- `login` (the stand-in approves; a `slow_down` is honored), `options`, `install-skill` into a temporary home, `submit --check` (every problem at once, the manifest), `submit` of a brief and plan: the stand-in holds `brineylab/<name>` created with the researcher's token, the implementer's assignment carries the plan, and the scripted investigator runs it to an account that `status` shows; `steer` and `stop` on a second submission; `logout`, after which the next command is a 401.
+- `login` (the stand-in approves; a `slow_down` is honored), `options`, `install` into a temporary home, `submit --check` (every problem at once, the manifest), `submit` of a brief and plan: the stand-in holds `brineylab/<name>` created with the researcher's token, the implementer's assignment carries the plan, and the scripted investigator runs it to an account that `status` shows; `steer` and `stop` on a second submission; `logout`, after which the next command is a 401.
 - Graduation: merge the investigation's pull request on the stand-in, clone, add the toy project's run contract, push; `project set`, `validate`, `launch` an optimization run by the scripted crew.
 - `register` of the toy repository, `validate`, `launch`.
 - Refusals, each leaving nothing on the stand-in GitHub: no brief; a refused campaign file; a name taken (the refusal names the existing project and campaign); a researcher not on the allowlist; an expired session; an optimization on a brief-only project; a `.env` in the directory (not sent), a tracked file holding a `ghp_` token (refused with its line), a symlink (not followed), a 25 MB file; a client below `MIN_CLIENT` (426 with the upgrade line); a client newer than the host (one warning line, then the output).
@@ -143,11 +143,11 @@ The board shows every project and campaign and lets people steer and stop. This
 - The board's panel shows this board's URL, and the Admin page ends a user's sessions (browser).
 - The skill: every command and flag it names exists in the client, and its text states the budget's overshoot and names `submit --check` and the merge-before-graduation step.
 - The host's commands under `host`: the existing suite passes with its invocations moved; a unit test writes units with the old names, upgrades, and finds them rewritten and the aliases answering.
-- CI installs the package without extras and runs `flyloft --help`, `flyloft install-skill`, and the client's unit tests, so a server import in the client fails there, not on a researcher's laptop.
+- CI installs the package without extras and runs `flyloft --help`, `flyloft install`, and the client's unit tests, so a server import in the client fails there, not on a researcher's laptop.
 
 **Tier two** (live, no model tokens): `submit` against real GitHub creates a private `brineylab/flyloft-tier2-<date>` (the human deletes it afterward: flyloft's token has no `delete_repo`); a scripted investigator runs one job on slinky; `status` reads it back. The session is created on the host, since `login` needs a person at GitHub.
 
-**Tier three:** the human, with Claude Code: `pip install flyloft`, `install-skill`, `login`, the ESM-C conversation, `submit`, and `status` from the harness days later. It is investigate part 1's tier three as well.
+**Tier three:** the human, with Claude Code: `pip install flyloft`, `install`, `login`, the ESM-C conversation, `submit`, and `status` from the harness days later. It is investigate part 1's tier three as well.
 
 ## 9. Part 2: tasks
 

flyloft-0.2.2/docs/design/cpu-partition.md

@@ -0,0 +1,122 @@
+# The CPU Partition: Design
+
+Status: approved 2026-10-22; widened the same day to tasks after [tasks.md](tasks.md) merged; built on branch `feature/cpu-partition`. Tier one passed (625 passed, 9 skipped; two `test_client` failures are environmental on the build host). Tier two passed on bcr: the setup run went to partition `cpu` with `cpu=8, mem=16G` and no GPU; the GPU run went to `l40s` with its share of the node (`cpu=48, gres/gpu=1, mem=179G`) and imported the environment the CPU run built. Follows investigate, part 1 ([investigate.md](investigate.md)) and tasks ([tasks.md](tasks.md)): it sends the 0-GPU runs of both critic-judged types to a cluster's CPU nodes.
+
+Throughout, *critic-judged* means an investigation or a task (`Campaign.critic_judged`), the two types whose implementer sizes its own runs. Optimize campaigns give every run the campaign's resources and at least one GPU, so they have no 0-GPU runs and nothing here touches them.
+
+A critic-judged campaign's implementer already sizes each run: its command, GPUs from zero to the campaign's ceiling, and time limit. A run that asks for no GPUs is a setup run, but it still goes to the partition of the campaign's GPU type and gets the campaign's CPUs and memory. On a GPU partition with no CPUs set, that is one CPU. That is useless for real data work, and it takes CPUs and memory from GPU nodes.
+
+This change sends a no-GPU run to the cluster's CPU partition, when the cluster names one. It gives such a run its own CPUs and memory, within a CPU-run limit the researcher sets at launch. GPU runs are untouched. Their CPUs and memory stay what the campaign names, or their share of the node, so that a GPU job never takes the CPUs its node's other GPUs need.
+
+## 1. Scenario
+
+The researcher retests curriculum learning for antibody language models on held-out donors. The paired data is an existing release. The unpaired data must be rebuilt first: a fresh download of OAS unpaired sequences, filtered, held-out donors removed, and clustered at 95% with mmseqs `linclust`. That is a CPU job of hours that needs on the order of 100 CPUs and several hundred GB of memory.
+
+1. **The cluster names its CPU partition.** bcr's file has `cpu_partition = "cpu"`: one node, 256 CPUs, about 1 TB, shared by the lab.
+2. **The researcher launches an investigation** on bcr:
+   - GPU type `l40s`, each run up to 4 GPUs for 48 hours;
+   - each CPU run up to 128 CPUs and 384G, half the CPU node.
+3. **The implementer builds the data first.** It commits the build code and requests a setup run with 0 GPUs, 96 CPUs, 256G and 24 hours.
+   - The job goes to `cpu` with those numbers.
+   - It writes the release under `$FLYLOFT_PROJECT_WORK/data/` and a summary to `$FLYLOFT_OUT`.
+   - It is charged nothing against the GPU-hour budget, and it holds one run slot while it runs.
+4. **Then it trains.** Its training runs ask for GPUs and go to `l40s` exactly as today, with the campaign's CPUs and memory or the cluster's share for each GPU.
+5. **Refusals:**
+   - a CPU run asking for 200 CPUs, or for 512G, is refused with the limit it exceeded;
+   - so is a CPU run that names no CPUs or memory;
+   - so is a GPU run that names CPUs or memory.
+
+## 2. What changes
+
+**The cluster file.** `ClusterConfig` gains `cpu_partition: str | None`.
+- It differs from `partition`, which is the fallback for every job whose GPU type names none. `cpu_partition` is only for jobs that ask for no GPUs.
+- A cluster without one behaves as today.
+- bcr's file is `clusters/bcr.toml` in the lab's `brineylab/flyloft-config` repository. It gains `cpu_partition = "cpu"` in a pull request there once this change is deployed, not in this repository.
+- `examples/live-config/clusters/slinky.toml` gains a commented `cpu_partition` line, and the misleading comment on its `partition` line is corrected.
+
+**The CPU node runs the same jobs.** On bcr the `cpu` node is x86_64 like the GPU nodes. It mounts the same `/mnt/data`, where `remote_work_dir` and the project work directory live, and every partition has the same images under `/mnt/data/containers/`. So:
+- a CPU run takes the cluster's one `container_image` and `container_mounts`;
+- an environment a setup run builds on `cpu` serves a GPU run after it.
+
+The existing tier-two test `test_live_an_investigation_sizes_its_runs_and_keeps_its_environment` checks exactly that, and once the live config names `cpu_partition` it exercises this path. Per-partition containers are not needed.
+
+**The CPU-run limit.**
+- **Where it is set:** the campaign file's `resources` gains `cpu_run_cpus: int | None` and `cpu_run_mem: str | None`, stored on the campaign by migration `0028_cpu_runs.sql`. They are the most one CPU run may ask for. They are separate from `cpus` and `mem`, which keep their meaning for every GPU run.
+- **`validate_campaign`:**
+  - refuses either field on a campaign that is not critic-judged ("only an investigation or a task takes a CPU-run limit");
+  - refuses either field on a cluster with no `cpu_partition`;
+  - refuses a `cpu_run_cpus` below 1;
+  - refuses a `cpu_run_mem` that does not parse.
+- **Left empty:** both are optional. Left empty, a CPU run may ask for whatever Slurm will grant on the node.
+
+**A CPU run's request.** `RunRequestBody` gains `cpus: int | None` and `mem: str | None`, and the migration adds nullable `run.cpus`, `run.mem` and `run.partition`. In `_request_investigation_run`:
+- **A run with 0 GPUs on a cluster with a `cpu_partition` is a CPU run.**
+  - It must name `cpus` (at least 1) and `mem`.
+  - `mem` is in Slurm's form: a whole number with an optional `K`, `M`, `G` or `T`, megabytes when bare.
+  - Each is at most the campaign's CPU-run limit when one is set. Memory is compared in megabytes.
+- **A run with GPUs, or a 0-GPU run on a cluster without a `cpu_partition`, may not name `cpus` or `mem`.** It gets the campaign's, as every run does today.
+
+**Where a run goes.** `render_job_script` sends a CPU run to `cpu_partition` with its own `--cpus-per-task` and `--mem`. Every other job is rendered exactly as today. Only a critic-judged campaign's runs can ask for no GPUs, so optimize campaigns, validations and measurements are unchanged. The partition a run was submitted to is stored on the run (`run.partition`, written by the service when it submits). The board then reports where the run went, even if the cluster's file changes later.
+
+**The agent's tool.** `investigation_request_run` gains optional `cpus` and `mem`. Its description says:
+- a run with 0 GPUs goes to the cluster's CPU nodes when it has them, and then names its CPUs and memory;
+- a GPU run names neither.
+
+The implementer's assignment, through the shared `_cj_implementer_rules.md.j2` and `_cj_record.md.j2` partials used by both types, shows the CPU-run limit beside the GPU and time ceilings, when the cluster has a CPU partition. It says that data work belongs on a CPU run, sized to what it needs.
+
+**The budget.** Unchanged. A run is charged its own GPUs times its time, so a CPU run costs nothing. Run slots and the CPU-run limit are the only bounds on CPU work. As today, no run, a CPU run included, is accepted once the GPU-hour budget is spent: the investigation ends at its budget anyway.
+
+## 3. The board
+
+- **The host's API.** `ClusterView` gains `cpu_partition`, so the launch page knows whether to offer a CPU-run limit.
+- **Launch.** When the chosen cluster has a CPU partition, an investigation's or a task's Compute step adds "each CPU run may ask for up to" CPUs and memory, both optional. The existing CPUs and memory fields keep their meaning for GPU runs.
+- **The run and its page.** A CPU run shows its request as CPUs, memory and time, "on cpu". A GPU run is shown as today. `npm run types` regenerates `web/src/api/types.ts`.
+
+## 4. Tests
+
+**Tier one** (`tests/e2e/test_investigate.py`, extended). The fake cluster's file names a `cpu_partition`, and the campaign sets a CPU-run limit.
+- **A CPU run:** the scripted investigator requests a 0-GPU setup run with its own CPUs and memory. Its job script has the CPU partition, `--cpus-per-task` and `--mem`, and no `--gres`.
+- **A GPU run in the same campaign** renders exactly as before: the GPU type's partition and the campaign's CPUs and memory.
+- **Refusals, each with its reason:**
+  - a CPU run over the CPU limit, and one over the memory limit;
+  - a CPU run that names no CPUs or memory;
+  - a GPU run that names CPUs.
+- **Campaign files that are refused:** a CPU-run limit on an optimize campaign, and one on a cluster without a `cpu_partition`.
+- **A cluster without a `cpu_partition`:** a 0-GPU run renders as today.
+- **A task with a 0-GPU ceiling** on the cluster with a CPU partition: its run names its CPUs and memory, goes to the CPU partition, and is charged nothing. The existing task scenario (`tests/e2e/test_tasks.py`, cluster `local`) passes unchanged.
+- **In the browser:** launching on that cluster offers the CPU-run fields, and the run page shows the CPU run's request.
+
+**A unit test** for the memory parser and comparison: `512`, `8G`, `384G`, `1T`, and refusals of `8GB`, `1.5G` and `-1G`.
+
+**Tier two** (live on slinky, scripted, no model tokens). An investigation on bcr with a CPU-run limit of 16 CPUs and 32G requests a 0-GPU setup run with 8 CPUs and 16G that writes `nproc` and the job's memory limit to `$FLYLOFT_OUT`.
+- Checked: `sacct` shows it ran on `cpu` with 8 CPUs and 16G, and its `out/` came back.
+- The test skips with a reason when the live config's cluster names no `cpu_partition`. The tester's live config gains `cpu_partition = "cpu"`.
+
+**Tier three** is the curriculum retest's data build.
+
+## 5. Code layout
+
+```
+src/flyloft/migrations/0028_cpu_runs.sql        campaign.cpu_run_cpus, cpu_run_mem; run.cpus, mem, partition
+src/flyloft/config/models.py                    ClusterConfig.cpu_partition; ResourceProfile cpu_run_cpus,
+                                                cpu_run_mem; Slurm memory parsing
+src/flyloft/config/load.py                      the CPU-run limit's rules
+src/flyloft/record/models.py                    RunRequestBody and Run cpus, mem; Campaign's CPU-run limit
+src/flyloft/record/launch.py, record/store.py   store the CPU-run limit; insert and read run.cpus, mem, partition
+src/flyloft/record/actions.py                   a CPU run's request and its limit
+src/flyloft/runs/staging.py                     a CPU run to cpu_partition with its own cpus, mem
+src/flyloft/service/tick.py                     record the partition a run was submitted to
+src/flyloft/tools/server.py                     investigation_request_run takes cpus, mem
+src/flyloft/turns/roles/implementer.investigate.md.j2   the CPU-run limit; data work on a CPU run
+src/flyloft/web/schemas.py, record/views.py     ClusterView.cpu_partition; a CPU run's request and partition
+web/src/...                                     the launch's CPU-run fields and the run's request
+examples/live-config/clusters/slinky.toml       cpu_partition, and the partition comment corrected
+```
+
+## 6. Out of scope
+
+- **Choosing a GPU type per run** within a campaign. It would change budgeting (a B200-hour is not an L40S-hour), and this scenario trains on one type.
+- **Resizing a GPU run's CPUs or memory.** A GPU job keeps the campaign's values or its share of the node, so it never takes CPUs its node's other GPUs need.
+- **A separate CPU-run limit per type.** Investigations and tasks share one rule.
+- **A CPU row on the Compute page and in `flyloft options`.** The researcher sets the limit from what they know of the node; added when a launch goes wrong for want of it.
+- **A CPU budget.** Run slots and the CPU-run limit bound CPU work, at the researcher's call.

flyloft-0.2.2/docs/design/tasks.md

@@ -0,0 +1,77 @@
+# Tasks: Design
+
+Status: approved 2026-10-21; built the same day on branch `tasks`. Tier one passed (599 passed, 9 skipped; the task scenario is `tests/e2e/test_tasks.py`). No tier two (§6). Tier three passed on 2026-10-22: `v0.2.1` released and deployed, a task talked through in Claude Code with the flyloft skill, submitted, and run. Closed. Part 2 of the agent interface ([agent-interface.md](agent-interface.md) §9 decided its shape); the third kind of work in [VISION.md](../VISION.md).
+
+A *task* is work that needs doing, whose product is its output: benchmark these five models on this suite, rerun the analysis a reviewer asked for, process this dataset into that format. There is no hypothesis and nothing to judge worth pursuing. The agents do all of what was asked and nothing beyond it, and the product is the output, reported faithfully with the runs that produced it. A task runs on the investigation engine built in part 1 of investigate: one implementer that sizes its own runs in the project work directory, one critic, one reporter, a brief-only project, and `submit` from the researcher's agent. What differs is the framing the three roles are given, how a task completes, and the words the board and the pull request use.
+
+Shipped alongside, because they are small and the human asked during tier three: the package's Python floor drops to 3.11 (two one-line rewrites in the server; the client needs only `tomllib`), and `flyloft login` shows its address and code in a panel on a terminal.
+
+## 1. Scenario
+
+The researcher wants a reviewer's request done: the lab's model and four published ones, each run on a standard benchmark suite, as one table for the response to reviewers.
+
+1. **Conversation.** With Claude Code and the flyloft skill: *What do you want to do?* (the table), *Why is this important?* (the manuscript's revision), *How will you know it is done?* (every model on every benchmark, one table, each number traceable to a run). The ask is not exploratory, so the fourth question is not asked. The skill proposes a **task** and says why: the product is the output, not a finding. The agent writes `BRIEF.md` (the models and where they are published, the benchmark suite and where it lives, the table's shape, what agents must not do) and `task.toml` (`type = "task"`), checks, and submits on the researcher's "submit".
+2. **The work.** The implementer brings up the models in `$FLYLOFT_PROJECT_WORK`, runs every model on every benchmark, and posts the output: one finding whose claim is the table, with every run it rests on cited. It does nothing the ask did not call for.
+3. **The judgment.** The critic checks the output against the ask: every model on every benchmark the brief named, no number in the table that the runs do not show, nothing left out. The first output lacks one model on one benchmark; the critic blocks it naming the gap; the implementer runs it and posts a superseding output; the critic accepts.
+4. **The end.** The implementer concludes: a task concludes only once an output has been accepted and nothing is in flight. The reporter writes the account: what was done and where the outputs are, what was tried, what could not be done; "what to ask next" only if there is something to say.
+5. **The researcher** reads it in the harness (`flyloft status <id>`) or on the board, where the campaign is labeled a task and its outputs are not called exploratory, and drops the table into the response to reviewers.
+
+## 2. One engine, two labels
+
+`investigation` and `task` are campaign types; both are **critic-judged**: `Campaign.critic_judged` (true for either) replaces every `type == "investigation"` test in the server (35 of them) and `criticJudged(c)` the board's. Everything part 1 built serves both: the run sizing and slots, the project work directory, `out/`, findings that cite runs, the three roles, `conclude`, the account, publication after the first accepted finding, memory skipping them.
+
+| | Investigation | Task |
+|---|---|---|
+| What the researcher fixes | what they want to know | work that needs doing |
+| The implementer | the fewest runs that show whether there is anything there; one seed | all of what was asked, nothing beyond it |
+| A finding is | what the experiments suggest, with its limits (*exploratory*) | an **output**: the deliverable, with the runs that produced it |
+| The critic asks | does the claim say no more than its evidence shows; are all arms reported | is the output complete against the ask; is every number in it one the runs show; is anything the ask named missing |
+| Concluding | nothing in flight, no finding under review | the same, **and at least one accepted output** |
+| The account | `answer` and `next` required | `answer` (what was done, where the outputs are) required; `next` optional |
+| Words | "investigation"; findings tagged exploratory; "The question" | "task"; outputs untagged; "The ask" |
+
+**Completion.** A task's completion is judged by the critic, not computed: what was asked is prose in the brief, so nothing but a reader can tell whether the table has every row. The rule that makes this binding is in `conclude`: a task is refused while no finding is accepted ("no output has been accepted yet; post the output and wait for the critic"). An implementer that wants to end a task therefore has to produce the deliverable and get it past the critic. The critic's block names what is missing, and the superseding-finding path already carries the corrected output.
+
+**CPU-only work.** Many tasks need no GPU. `validate_campaign`'s rule that a bounded campaign asks for at least one GPU per run exempts critic-judged campaigns: their implementer sizes each run, and the ceiling may be `gpus = 0`. `gpu_hours` stays required for both types (one rule, one field); with a 0-GPU ceiling no run can charge against it, and the task ends at its conclusion or a stall. The launch page and the skill say so.
+
+## 3. What is recorded
+
+Nothing new in the schema. `CampaignFile.type` and the campaign's `type` column accept `"task"`; `validate_campaign` applies the investigation rules (no metric, direction, baseline, target, dry window, islands, or replication; `gpu_hours`; exactly implementer, critic, reporter) to both critic-judged types. `submit` accepts both. `report`'s rule: an investigation needs `answer` and `next`; a task needs `answer`.
+
+## 4. Roles
+
+Each investigation template gains its task variant, chosen by type: `implementer.task.md.j2`, `critic.task.md.j2`, `reporter.task.md.j2`. The shared blocks (the project work directory and `out/` rules, run sizing, the record, refusals) move into includes used by both variants, so the two differ only in their framing paragraphs:
+
+- **Implementer.** Do all of what was asked and nothing beyond it. Setup runs, then the work, in as many runs as it takes, in parallel up to the slots. The deliverable is one finding, its claim the output as the brief asked for it (a table, a file in `out/`, a converted dataset in the project work directory), citing every run it rests on. Post it when it is complete; the critic checks completeness. After a block, do what it names and post a superseding output. Conclude once the output is accepted.
+- **Critic.** Judge completeness and faithfulness against the ask: every item the brief named is there; every number is one the cited runs' outputs show; nothing is reported that was not run. Never ask for more than the ask; never judge whether the result is interesting. A block names exactly what is missing or wrong.
+- **Reporter.** Wakes once at the end. `answer`: what was done and where the outputs are (paths in `out/` or the project work directory, the table itself when it is short). `found`: the outputs; `tried`: the runs; `ruled_out` and `open`: what could not be done and why; `next` only when the work showed something worth asking.
+
+The heading over the campaign's question reads "The ask" in every critic-judged assignment; an investigation's reads the same.
+
+## 5. The board, the pull request, the client, the skill
+
+- **Launch:** the Question step offers three choices: **Investigate a question**, **Do a task**, **Optimize a metric** (the last disabled without a run command). A task's steps are an investigation's; its Compute step allows 0 GPUs per run, with the line "with no GPU, the budget never charges; the task ends when its implementer concludes".
+- **Labels:** the card, the campaign page, the finished row, the PR head, and `flyloft status` say "task"; an output is shown without the *exploratory* tag; the account's "Worth asking next" section appears only when `next` is non-empty.
+- **`submit` and `launch`** take `type = "task"`.
+- **The skill:** proposes a task when the ask has no hypothesis and nothing to judge worth pursuing (the benchmark, the reviewer's analysis, the conversion), an investigation otherwise; `handoff.md` gains an annotated `task.toml`.
+
+## 6. Tests
+
+**Tier one** (`tests/e2e/test_tasks.py`, fake cluster, stand-in GitHub, scripted agents):
+- A scripted task implementer runs two "benchmark" jobs, posts an output whose table lacks one row; a scripted critic blocks it naming the row; the implementer runs the missing job and posts a superseding output; the critic accepts; `conclude` is refused before the acceptance ("no output has been accepted yet") and succeeds after; the reporter's account has an `answer` and an empty `next`.
+- A task with a 0-GPU ceiling launches, its runs are charged nothing, and it ends at its conclusion.
+- `submit` of a `task.toml` from the client, and `status` labeling it a task.
+- Browser: the card and page say "task" and show no "exploratory" tag; the launch page's three choices.
+- The investigation scenarios pass unchanged (the predicate did not change their behavior).
+- Unit: `conclude`'s accepted-output rule, `report`'s task rule, `validate_campaign` accepting a 0-GPU task and refusing a 0-GPU optimization.
+
+**Tier two:** none of its own. The engine's live path was exercised by investigate part 1 and the agent interface; a task runs the same code with different prose.
+
+**Tier three:** the human's walk from Claude Code: a task submitted by their agent, judged, and read back.
+
+## 7. Out of scope
+
+- Computed completion (a checklist the ask is parsed into). The critic judges; if critics are seen accepting incomplete outputs, that is the trigger.
+- A task with no budget at all (`gpu_hours` optional). One rule for both types until a researcher asks.
+- Outputs larger than `out/` carries (a converted dataset lives in the project work directory; the account names its path).
+- Tasks at swarm size.