feat(http-api): add GET /agent-task/runs/:id as a pure read

[chubes4]

The finding overstated the gap, and the headline is what already works. Two of its five "missing" items exist, one of them backwards. Reporting that rather than building past it.

What already works — because cook and fanout are controller jobs now

Finding claimed missing	Reality
submit	Exists. POST /controller/jobs → enqueue_controller_job → driver("agent-task.cook", v). Idempotency-keyed; validate_secret_references fails closed on any inline prompt/env/token via deny_unknown_fields.
cancel	Exists — and the finding was backwards. POST /controller/jobs/:id/cancel works; the generic POST /jobs/:id/cancel deliberately refuses controller jobs (store/mod.rs:1564) with a hint pointing at the right route, so the driver's cancel() can stop the work it owns.
cook report / gate evidence	Reachable. GET /jobs/:id/events carries driver-projected public_progress/public_result; evidence URIs hydrate through GET /runs/:id/artifacts/:id/content.
retry	Genuinely absent. Correctly out of scope.
read a run by id	Genuinely absent — but GET /activity/:id already resolved agent-task run ids, including Cook aliases.

#11857 and #11871 closed most of this as a side effect.

Existing redaction is already sound and needed no change: ControllerJobState (holding the private request) hangs off StoredJob, not Job, and job_store.get() returns stored.job.clone() — so GET /jobs/:id cannot leak it. CookJobDriver::public_error already collapses to a typed code plus "controller-owned cook supervision failed", precisely because cook error text quotes provider output.

The one real gap, and why it is a pure read

GET /agent-task/runs/:id — an agent-task-scoped read that fails closed on a non-agent-task id.

It does not call agent_task_service's status function. It could not, and should not.

• Could not: homeboy-agents/Cargo.toml states it — "Depends on homeboy-core; core does not depend on it." http_api.rs is core. That call is a dependency cycle.
• Should not: status_with_options does ~8 store::write_record calls and, for a non-controller-local record, reconcile_runner_job_state — a live network round trip to the runner. On a serial accept loop that stalls the entire daemon. This file already refused exactly this once: require_run's doc comment (Adopt runs_service/evidence_report facade across observation-store consumers (single activity-aware surface) #6768) declines the reconciling facade for the same reason.

So it resolves via activity::agent_task_provider::probe_by_id — an existing, registered, indexed, explicitly non-mutating lookup (#10308) that already handles Cook-id aliasing, returning ActivityItem, the same projection GET /activity/:id serves. Not an invented shape.

Deliberately not activity::show_activity, which falls back to a full-corpus scan of up to 1000 records across three stores when probes miss.

The response carries reconciles: false and reconcile_with: "homeboy agent-task status" rather than letting a caller assume freshness.

SSE — not feasible, and not attempted

daemon/mod.rs:1155:

for stream in listener.incoming() {
    Ok(stream) => { let _ = handle_connection(stream, &job_store, ...); }

Inline, single-threaded, no per-connection spawn. One SSE client would hold the accept loop for the life of the stream, blocking /health, daemon status, and the reverse-broker /runner/jobs/* routes remote runners depend on. That is a total daemon outage, not degradation. Zero hits for event-stream / chunked / Transfer-Encoding anywhere.

Making it safe needs: per-connection concurrency at 1155; a streaming writer (write_http_response emits Content-Length + Connection: close and returns after one write!); bounds that do not exist (max streams, max lifetime, keepalive frames); and socket timeouts.

Pre-existing hazard found while reading: read_http_request blocks on stream.read() with no timeout, so today a client that connects and sends nothing wedges the entire daemon. Filed separately — it deserves attention independent of this work.

Cheaper alternative, proposed not built: JobEvent already carries sequence: u64, but job_store.events() returns the whole Vec under a mutex every call. A GET /jobs/:id/events?after=N cursor is a pure request/response change needing zero restructuring, bounds the payload, and turns O(n²) polling into O(n).

Auth and redaction

Auth: identical to neighbours by inheritance. broker_auth applies only to /files/* and /runner/*; the read-only API is reached via _ => route_read_only_api(...) without it. Protection is the daemon's hard loopback-only bind validation. This route sits in the same fallthrough — not less protected, and deliberately not more, since a lone authenticated route in an unauthenticated block is confusing rather than safer.

Redaction, three layers: ActivityItem is a typed allowlist and hardcodes command/cwd to None for agent-task records, so no prompt or provider output is reachable; a failing probe reports probe_failed: true and never its message, because the daemon copies err.message straight into the body; and the id is length-capped at 256 bytes before the store lookup.

No write path added — tests assert POST /agent-task/runs/:id, /agent-task/runs, .../cancel, .../retry all fail to route.

Verification

cargo check --workspace --tests clean. http_api tests: 36 passed, 1 failed — artifact_content_serves_encoded_artifact_store_locator, which I confirmed fails identically on origin/main. Pre-existing, filed separately, unrelated to this change.

Flagging

• The happy path is untested and I could not test it in core. Core's tests depend on no agent-task provider being registered (activity.rs:572), and registration is process-global and irreversible, so a fake would poison the shared lib-test binary. It needs a homeboy-agents-level test.
• I edited http_api/types.rs to add the HttpEndpoint variant — impossible otherwise.
• probe_failed conflates a store outage with a miss (both 404). Deliberate — it matches resolve_activity_item, and the alternative leaks error text.
• requested_id and run_id may differ when a Cook alias resolves to an attempt record; both are exposed.
• daemon/mod.rs needed zero changes — the _ => route_read_only_api(...) fallthrough picks the route up, and no daemon arm shadows /agent-task.