Module tasks 

HTTP surface for the Task/Run persistence axis (issue #13 ID hierarchy; GET /v1/tasks, GET /v1/tasks/:id, POST /v1/tasks/:id/runs, GET /v1/runs/:id). POST /v1/tasks itself stays in this module (it is the entry point tasks_start shares with the flow-eval path) — see the tasks module doc for the split rationale. HTTP surface for the Task/Run persistence axis (issue #13 ID-hierarchy reconciliation: Blueprint → Task → Run → Step → Attempt).

• GET /v1/tasks — list every persisted TaskRecord, newest first.
• GET /v1/tasks/:id — a TaskRecord plus every RunRecord kicked from it.
• POST /v1/tasks/:id/runs — re-kick an existing Task: mints a fresh RunId, replays the stored blueprint_ref / input_ctx through TaskApplication::handle_with_run, and returns the new {task_id, run_id} pair.
• GET /v1/runs/:id — a single RunRecord (step_entries trace included).

POST /v1/tasks itself (the flow-eval entry point, tasks_start / run_flow_form) stays in crate::lib — it is the pre-existing Operator-inject-aware dispatch path this module’s handlers re-kick through, not a new one. This module owns the read/list/re-kick surface plus the [finalize_run] persistence helper both paths share.

Authorization follows the same convention as the existing POST /v1/tasks entry: no Authorization header is required (the route is open), and the only Operator-session correlation available is the request-body-level operator_sid (see crate::FlowTasksReq doc) — this module invents no new auth mechanism.

Structs

RunKickResponse

Response body for POST /v1/tasks/:id/runs.

TaskDetailResponse

Response body for GET /v1/tasks/:id.

TasksListQuery

Query params for GET /v1/tasks.

Functions

run_get

GET /v1/runs/:id. Returns a single RunRecord (its step_entries trace included).

task_get

GET /v1/tasks/:id. Returns the TaskRecord plus every RunRecord kicked from it (RunStore::list_by_task, oldest kick first).

task_rekick

POST /v1/tasks/:id/runs. Re-kicks an existing Task: reads its stored blueprint_ref / input_ctx, mints a fresh RunId, dispatches through TaskApplication::handle_with_run via TaskApplicationInput::automate (the unadorned Operator-default path — no per-request Operator override support here, unlike POST /v1/tasks; the stored Task carries no such preferences) plus a freshly-built RunContext (issue #13 run_id propagation, so this kick’s steps get their own step_entries trace), and persists the outcome via [finalize_run].

tasks_list

GET /v1/tasks?limit=N. Lists every persisted TaskRecord, newest first.