remote-compute-ssh

You've decided to run this on the user's SSH host. This skill covers the
orchestration layer — partitions, env activation, job scripts, file transfer,
recovery — not the science; what to run and why comes from the task and its
own skills. Each `c.submit_job()` puts an approval modal in front of the user
and, once approved, spends their allocation; a string of failed submits costs
their attention, their compute, and their trust. So the shape of a good run
is: read what's already known about this host, ask once for what isn't, land
the first submit, and write down what you learned about the host or compute
provider so the next session goes straight to the job.

## Workflow

Every `host.compute.*` call in this skill runs via the **`repl` tool**
(the control-plane kernel), not the `python` tool. Job submission opens the
user's approval modal and the SSH connection from the orchestrator's own
process; that has to happen outside the sandboxed data workspace, so
`host.compute` simply isn't attached in the `python` tool (you'd see
`host has no method 'compute'`). The two kernels share your workspace
directory but not memory, so the rhythm is: prepare inputs in a `python`
cell (write `./in.dat`, pickle what the job needs), run
`create → submit_job` in a `repl` cell and let the cell return — the
kernel never blocks on compute. Then call the `wait_for_notification`
brain-tool to park until the daemon's poller emits the `compute_done`
notification, and return to the `python` tool to read the harvested
`hpc/<jobId>/` files. The `repl` tool is stdlib-only (`python -I -S`) —
keep pandas/numpy work in the `python` tool and pass data through files.

Start with the `compute_details({provider, mode:'read'})` tool, then bind once:
`c = host.compute.create(provider)`. The doc's shape tells you how much
discovery is left: `### env:` blocks and gotchas mean prior sessions did the
legwork — trust it. A bare `## Resources` header means first contact — spend
one batched `c.call_command('id; module avail 2>&1 | head -40; ls -la ~',
intent=..., login_shell=True)` and one `ask_about_compute` now, before any
submit. The header's `scheduler:` line is detection, not ground truth; `none`
on a thin login node means a heavy direct-exec job would crowd other users, so
when the resources look thin and the details doc has no prior note, ask first.

If the prose doc has a known-working activation, write it directly into your
`command` (e.g. `source <path>/activate && <tool> ...`). If it doesn't, find
one via `c.call_command()` (`module avail X`, `conda env list`, likely app
dirs) or ask. Install only once you've established the tool genuinely isn't
there — user-space (venv/conda under scratch), via `c.call_command()` for a
quick install or as its own `c.submit_job()` if it needs a build node.
Whichever route produced an activation, run the entrypoint once via
`c.call_command()` before building the real job on it.

Then `job = c.submit_job(...)` (see below). `inputs=[{src:'file', dst_filename:
...}]` stages the file for you — there's no `c.upload()` step, and once
submitted there's nothing to verify with `c.call_command('cat ...')`; the job
reads `./<dst_filename>` from its own workdir. End the cell — `submit_job`
returns immediately and the daemon's background poller polls the remote,
harvests everything the job wrote into your workspace under `hpc/<jobId>/`,
and emits a `compute_done` notification when done.

Park on the `wait_for_notification` brain-tool until that notification
arrives. Its payload carries `{job_id, status, exit_code, featured_files,
output_file_count, ...}` — `featured_files` is the subset matching your
featured `outputs:` globs (omitting `outputs:` features everything). Publish
what you want with `save_artifacts(payload['featured_files'])` — that step is
what gives them provenance and surfaces them in the artifact panel. If you
need the full result dict (all `output_files`, `left_on_remote`, etc.),
re-enter a `repl` cell and call `r = c.attach_job(job_id).result()` — a
non-blocking read of what the poller already harvested.
`open(r['output_files'][i])` reads any harvested file directly. Chain a
remote-resident output via
`inputs:[{remote_path: r['left_on_remote'][i]['uri']}]`. Between the
notification and `close()` you can still
`c.download(f"{job.workdir}/<file>")` for anything the harvest missed.
`c.download('/any/absolute/host/path')` works for **any readable file on
the host**, not just job outputs — paths outside scratch/data_roots raise an
approval card the user clicks Allow on. When the user asks you to
fetch a host file, call `c.download()` with the path they gave; the approval
card is the authorization gate, so don't refuse on their behalf and don't
`cp` into scratch first to dodge it. Dotfiles / paths under a dot-directory
(`~/.ssh/*`, `.gitconfig`, `.env`, …) get a hardened per-file confirmation.
`c.close()` once you've confirmed — it cleans up the job workdirs on the
host. Hand back the result verbatim.

## What to record

The `compute_details()` tool is the only state that survives across sessions,
and three of your inputs are the user teaching you how their host works: an
`ask_about_compute` answer, a `User: <text>` redirect from a declined approval
(they clicked Respond and typed what to do instead), or guidance relayed in the
conversation. When one arrives, treat it as a teach loop — read the durable
fact, append it via the `compute_details({mode:'append'})` tool with a
`per user <date>` tag, echo
back what you understood in your next `intent` so the user sees the teaching
landed, then act on it.

Record an activation/partition/account combination you watched succeed too,
tagged with how you know: `verified <date>` if you ran the entrypoint and saw
exit 0, `per user` if from `ask_about_compute`, `untested` if inferred. A
single inline gotcha ("this tool needs `module load cuda/<ver>` here") is worth
keeping; per-job state and transient errors aren't.

When asking, ask once per gap and bat