# felhom.eu — task reports

> **Overwrite** this file with a summary of the most recent task only (uniform with the other repos; not cumulative). The cumulative hub history lives in [hub/CHANGELOG.md](hub/CHANGELOG.md).

---

# REPORT — Slice 10B (hub half): signed-op job completion (hub v0.10.0) (2026-06-10)

## Type

TASK (CC-implemented). The hub half of slice 10B. Pairs with `felhom-agent` v0.16.0 (the signing CLI
+ verify-and-execute machinery + the storage-wipe consumer).

## What changed (hub)

Small by design — the hub stores + serves the operator-signed blobs **opaquely** (it holds no signing
key, can neither forge nor open them; the agent verifies + executes). 10B adds the **completion** path.

### Store + API
- **`DELETE /api/v1/hosts/{host_id}/jobs/{job_id}`** (per-host key, **self-scoped**; global key may
  clear any) — the agent calls it after executing OR terminally rejecting a job. Idempotent. Store:
  `DeleteSignedJob`.
- Reused unchanged from 10A: `POST /admin/hosts/{id}/jobs` (operator enqueue), `GET /hosts/{id}/jobs`
  (agent fetch), `has_signed_ops` envelope flag. The signed blob stays opaque on the wire (a base64
  `{op_blob_b64, sig_armored}` envelope) — **no jobs-wire golden change**.

## Tests (green)
- `DELETE …/jobs/{id}` self-scoped (host A cannot clear host B's job → 403) + idempotent.

## Docs
- Doc 03 §4 (the operator-signed path is LIVE: gate → pending op → offline signature → verify
  (pinned key / nonce-burn / expiry / host + durable-id anti-retarget) → execute; key floor: not in
  the hub, not in the agent), §6 (the 8C data-bearing wipe now completes via 10B), §9 slice table
  (**10B done**; 10C escrow-consumption spike-validated, 10D DR capstone pending).

## Security framing (why the hub stays minimal)
The hub is deliberately a dumb queue here: it cannot forge a signed op (no key) and the agent never
trusts a queued blob until the pinned-key verify passes. A **compromised hub queuing a forged blob is
rejected** by the agent (tested in felhom-agent). That is the whole point of the offline-key design.

## Pending
- Build + deploy hub v0.10.0 (+ agent v0.16.0) and live-validate the full loop on the demo: a
  data-bearing wipe → `pending_signature` → offline-signed → queued → agent verifies + wipes the
  device; replay + non-pinned-key rejected.