Add backend processing jobs

[PaulHax]

This adds an end-to-end processing jobs workflow to VolView. Users can discover tasks, configure and submit them, monitor active jobs, and review previous runs. Supported outputs can be loaded directly into the viewer.

Processing workflow

The new Jobs module provides a complete UI for running backend tasks. Forms are generated from each task's specification. Job state is kept separate from the backend implementation.

• Support integer, float, string, boolean, enumeration, source reference, and bounds inputs.
• Mint image, DICOM series, and labelmap inputs from the current VolView session.
• Poll job status and expose cancellation, deletion, logs, submitted parameters, and paginated history.
• Download completed outputs and apply known result intents as base images, layers, or segment groups.
• Preserve ordinary result files when an intent is missing, unknown, or malformed.

Backend contract

The new backend-contract package defines the neutral boundary between VolView and a processing service. Zod schemas are the normative source. Checked-in JSON Schema and OpenAPI documents are generated from them. Fixtures and drift checks keep the TypeScript types, wire payloads, and generated artifacts aligned.

• Define task discovery, task specifications, staged inputs, job handles, lifecycle states, history, results, and cancellation.
• Use a small neutral state vocabulary: pending, running, success, error, and cancelled.
• Validate semantic rules that JSON Schema cannot express, such as relationships between defaults and numeric bounds.
• Ship the contract with the VolView package so a backend can validate against the exact client version it serves.

The integration is backend-agnostic. VolView only knows the neutral API and result vocabulary. A deployment supplies one or more provider URLs through configuration. Each backend adapter translates its native task definitions, job states, and output records into the shared contract. Adding another backend does not require a new client-side job implementation.

Manifest serialization and restore

Session manifests now carry enough information to round-trip processing results safely. The manifest version moves to 6.4.0. Segment groups can store optional job provenance using the provider, job, and output IDs. This acts as a durable idempotency key and prevents the same restored output from being applied twice.

• Make segment descriptors optional. When they are absent, restore rebuilds them from non-background voxel values and overlays embedded .seg.nrrd metadata.
• Preserve explicit parent-image bindings and validate segment-group artifact references.
• Validate the core data-source graph before writing an archive. Reject duplicate, dangling, cyclic, or missing required sources.
• Omit invalid optional state, orphaned segment groups, and broken layer relationships instead of producing an unrestorable session.
• Remove orphaned archive members and warn when session content could not be saved.
• Restore valid groups independently. A missing or unreadable result no longer prevents the rest of the session from loading.

Supporting hardening

The surrounding dataset, import, deletion, authentication, and remote-save paths were tightened to support the new workflow. Dataset removal now cascades through dependent viewer state. Provider and save targets are origin-gated. Successful remote saves can also repoint the current launch URL to the newly saved session without exposing backend-specific routes to VolView.

[netlify]

✅ Deploy Preview for volview-dev ready!

Name	Link
🔨 Latest commit	dba1ade
🔍 Latest deploy log	https://app.netlify.com/projects/volview-dev/deploys/6a5ed2235fa01b00087d5b01
😎 Deploy Preview	https://deploy-preview-904--volview-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.