Agents module: a manual run reports 'queued' and executes nothing

POST /api/agents/[id]/run returns 202 Accepted with status: 'queued' and the message Agent "<name>" run has been queued. Nothing is queued.

// apps/web/src/app/api/agents/[id]/run/route.ts
    // Update the agent's lastRun timestamp
    await prisma.agent.update({ where: { id }, data: { lastRun: new Date() } });

    const result = { ..., status: 'queued', message: `Agent "${agent.name}" run has been queued...` };
    return NextResponse.json(result, { status: 202 });

Its own docstring is honest about it — "In a full implementation, this would also enqueue a job via the job queue for the configured action type." Nothing in packages/outpost/queue or apps/worker reads Agent rows at all.

Why it matters

The row's lastRun timestamp is updated, so the UI shows a recent successful run. An operator gets a 202, a "queued" status, and a fresh timestamp — three independent signals that the agent ran. It did not. This is a false completion rather than a missing feature, which is the more expensive kind.

Phase 3F is marked ✅ DONE in the Build Plan, with the caveat buried in the plan text: "Execution framework TBD — may be simple cron-style automations initially." That TBD was never resolved.

Decision needed

The Build Plan lists this as an open decision: full automation framework, or simple cron-style jobs? Until it is answered, the honest options are:

1. Wire runs to a real AGENT_RUN job type and a handler, or
2. Return 501 and disable the run button, so the UI stops reporting success.

Either is better than the current state. (2) is a few lines and can ship immediately while (1) is decided.

Start with apps/web/src/app/api/agents/[id]/run/route.ts, then inspect packages/outpost/queue and apps/worker for existing job types and handlers. Confirm how the current response and lastRun update are consumed by the UI. Done means the selected behavior is implemented consistently and no longer reports a successful queued run when nothing executes.