Refactor the torc CLI (#241)

* Refactor the torc CLI

The goal of this commit is to simplify the user experience.
- The primary workflow lifecycle commands are now at the root level.
- Useful workflows summary/status information is moved into torc status.
- Move reports functionality into other subcommands.

* Refactor slurm-tests control script to use torc

Author: daniel-thom

.config/nextest.toml

@@ -3,8 +3,12 @@
 # nextest runs tests in separate processes.
 
 [profile.default]
-# Retry flaky tests up to 2 times
-retries = 2
+# Allow extra time for the first test in each file, which may trigger a cargo
+# build of server/runner binaries via build_test_binaries() in the #[once]
+# fixture. Multiple test files start in parallel, and while cargo serializes
+# concurrent builds via its lock, the waiting processes can exceed the default
+# 60-second timeout.
+slow-timeout = { period = "120s", terminate-after = 3 }
 
 [test-groups]
 # Slurm mock tests - modify PATH and mock executables

CLAUDE.md

@@ -498,7 +498,7 @@ sqlite3 server/db/sqlite/dev.db
 - `torc workflows submit <id>` - Submit workflow to scheduler (requires
   on_workflow_start/schedule_nodes action)
 - `torc workflows run <id>` - Run workflow locally
-- `torc workflows initialize <id>` - Initialize workflow (set up dependencies without execution)
+- `torc workflows init <id>` - Initialize workflow (set up dependencies without execution)
 - `torc workflows status <id>` - Check workflow status
 
 **Job Management**:

docs/src/SUMMARY.md

@@ -112,6 +112,7 @@
   - [Shell Completions](./specialized/tools/shell-completions.md)
 - [Design & Architecture](./specialized/design/index.md)
   - [Client Architecture](./specialized/design/client.md)
+  - [HTTP API Design](./specialized/design/http-api.md)
   - [Workflow Actions](./specialized/design/workflow-actions.md)
   - [Web Dashboard Design](./specialized/design/dashboard.md)
   - [Server API Handler](./specialized/design/server.md)

docs/src/core/concepts/job-runners.md

@@ -7,7 +7,8 @@ Job runners are worker processes that execute jobs on compute resources.
 Torc supports three execution modes:
 
 1. **Local Runner** (`torc run`) - Runs jobs on the local machine with resource tracking
-2. **HPC/Slurm Runner** (`torc submit-slurm`) - Runs jobs on Slurm-allocated compute nodes
+2. **HPC/Slurm Runner** (`torc slurm generate` + `torc submit`) - Runs jobs on Slurm-allocated
+   compute nodes
 3. **Remote Workers** (`torc remote run`) - Distributes jobs across SSH-accessible machines
 
 ### Local Runner

docs/src/core/concepts/reinitialization.md

@@ -6,7 +6,7 @@ appropriate jobs for re-execution.
 
 ## When to Use Reinitialization
 
-Use `torc workflows reinitialize` when:
+Use `torc workflows reinit` when:
 
 - **Input files changed** — You modified an input file and want dependent jobs to rerun
 - **Configuration updated** — You changed user_data parameters
@@ -18,13 +18,13 @@ Use `torc workflows reinitialize` when:
 
 ```bash
 # Preview what would change (recommended first step)
-torc workflows reinitialize <workflow_id> --dry-run
+torc workflows reinit <workflow_id> --dry-run
 
 # Reinitialize the workflow
-torc workflows reinitialize <workflow_id>
+torc workflows reinit <workflow_id>
 
 # Force reinitialization even with warnings
-torc workflows reinitialize <workflow_id> --force
+torc workflows reinit <workflow_id> --force
 ```
 
 ## How Change Detection Works
@@ -42,7 +42,7 @@ for re-execution.
 echo "new data" > input.json
 
 # Reinitialize detects the change
-torc workflows reinitialize <workflow_id>
+torc workflows reinit <workflow_id>
 # Output: Reset 3 jobs due to changed inputs
 ```
 
@@ -87,7 +87,7 @@ postprocess (depends on process output) → also marked
 Always use `--dry-run` first to preview changes without modifying anything:
 
 ```bash
-torc workflows reinitialize <workflow_id> --dry-run
+torc workflows reinit <workflow_id> --dry-run
 ```
 
 Example output:

docs/src/core/how-to/cancel-workflow.md

@@ -5,7 +5,7 @@ Stop a running workflow and terminate its jobs.
 ## Cancel a Workflow
 
 ```bash
-torc workflows cancel <workflow_id>
+torc cancel <workflow_id>
 ```
 
 This:
@@ -20,7 +20,7 @@ This:
 Verify the workflow was canceled:
 
 ```bash
-torc workflows status <workflow_id>
+torc status <workflow_id>
 ```
 
 Or check completion status:
@@ -43,11 +43,12 @@ To resume a canceled workflow:
 
 ```bash
 # Reinitialize to reset canceled jobs
-torc workflows reinitialize <workflow_id>
+torc workflows reinit <workflow_id>
 
-# Run again
-torc workflows run <workflow_id>
-torc workflows submit <workflow_id>
+# Run again locally
+torc run <workflow_id>
+# Or submit to scheduler
+torc submit <workflow_id>
 ```
 
 Jobs that completed before cancellation remain completed.

docs/src/core/how-to/check-resource-utilization.md

@@ -6,7 +6,7 @@ limits.
 ## Quick Start
 
 ```bash
-torc reports check-resource-utilization <workflow_id>
+torc workflows check-resources <workflow_id>
 ```
 
 Example output:
@@ -25,15 +25,15 @@ Job ID | Job Name    | Resource | Specified | Peak Used | Over-Utilization
 Include jobs that stayed within limits:
 
 ```bash
-torc reports check-resource-utilization <workflow_id> --all
+torc workflows check-resources <workflow_id> --all
 ```
 
 ## Check a Specific Run
 
 For workflows that have been reinitialized multiple times:
 
 ```bash
-torc reports check-resource-utilization <workflow_id> --run-id 2
+torc workflows check-resources <workflow_id> --run-id 2
 ```
 
 ## Automatically Correct Requirements

docs/src/core/how-to/debug-failed-job.md

@@ -32,7 +32,7 @@ Common exit codes:
 
 ```bash
 # Get log paths
-torc reports results <workflow_id> --job-id <job_id>
+torc results list --include-logs <workflow_id> --job-id <job_id>
 
 # View stderr (usually contains error messages)
 cat output/job_stdio/job_wf43_j15_r1_a1.e
@@ -52,7 +52,7 @@ cat output/job_stdio/job_wf43_j15_r1_a1.log
 Did the job exceed its resource limits?
 
 ```bash
-torc reports check-resource-utilization <workflow_id>
+torc workflows check-resources <workflow_id>
 ```
 
 Look for:
@@ -92,9 +92,10 @@ After fixing the issue:
 # Reinitialize to reset failed jobs
 torc workflows reset-status --failed --reinitialize <workflow_id>
 
-# Run again
-torc workflows run <workflow_id>
-torc submit-slurm <workflow_id>
+# Run again locally
+torc run <workflow_id>
+# Or re-submit to Slurm
+torc submit <workflow_id>
 ```
 
 ## See Also

docs/src/core/how-to/track-workflow-status.md

@@ -5,7 +5,7 @@ Monitor a running workflow's progress using the CLI, TUI, or dashboard.
 ## Quick Status Check
 
 ```bash
-torc reports summary <workflow_id>
+torc status <workflow_id>
 ```
 
 Example output:
@@ -25,7 +25,7 @@ Jobs by Status:
 Watch status update every 10 seconds:
 
 ```bash
-watch -n 10 torc reports summary <workflow_id>
+watch -n 10 torc status <workflow_id>
 ```
 
 ## Interactive TUI

docs/src/core/how-to/view-job-logs.md

@@ -5,8 +5,8 @@ Find and read the stdout/stderr output from job execution.
 ## Find Log File Paths
 
 ```bash
-torc reports results <workflow_id>
-torc reports results <workflow_id> --job-id 15
+torc results list --include-logs <workflow_id>
+torc results list --include-logs <workflow_id> --job-id 15
 ```
 
 Output includes:
@@ -71,7 +71,7 @@ Quickly find logs for failed jobs:
 torc jobs list <workflow_id> --status failed
 
 # Then view each job's logs
-torc reports results <workflow_id> --job-id <failed_job_id>
+torc results list --include-logs <workflow_id> --job-id <failed_job_id>
 ```
 
 ## View Logs in TUI or Dashboard