[gateway] POST /api/routines — endpoint not yet implemented (blocks desktop client UX) #4150

Summary

The IronClaw desktop client (a Tauri v2 + SvelteKit native macOS client we're building at https://github.com/abbyshekit/ironclaw-desktop) needs POST /api/routines for creating new routines from the UI. Today users can list, view, toggle, trigger, and inspect runs of routines via the existing gateway routes — but the only way to add a routine is to bypass the desktop client and use a different surface.

Current behaviour

curl -X POST http://gateway:18789/api/routines -H 'Content-Type: application/json' -d '{...}' returns 405 Method Not Allowed. The /api/routines path in src/channels/web/platform/router.rs (around line 258) is registered with get(routines_list_handler) only — no POST handler. The siblings (/api/routines/{id}/toggle, /api/routines/{id}/trigger, DELETE /api/routines/{id}) exist in src/channels/web/features/routines/mod.rs, so this is a missing create-side counterpart.

Verified across 3 live smoke tests against IronClaw 0.28.2 (R7e 2026-05-27, R9c 2026-05-27, R22a 2026-05-27).

Desktop client wiring

The client method exists at src/lib/api/ironclaw.ts:1114 (createRoutine(req: CreateRoutineRequest)) with a NOTE (2026-05-27) marker explaining the gap. The request type is defined in src/lib/api/types.ts near line 150. No UI surfaces this call yet — a create-routine form can land in one PR once the server handler exists.

Expected behaviour

Mirroring the established routines wire shape from routines_list_handler (GET /api/routines returns objects with {id, name, enabled, trigger_summary, trigger_raw, trigger_type, last_run_at, next_fire_at, ...} per /api/routines docs):

Request:
  POST /api/routines
  Authorization: Bearer {token}
  Content-Type: application/json
  Body: {
    \"name\": \"Daily summary\",
    \"schedule\": \"0 8 * * *\",          // or richer {trigger: {type: \"cron\", cron_expr: \"...\"}, action: {prompt: \"...\"}}
    \"prompt\": \"Generate a daily digest\",
    \"enabled\": true                     // optional, default true
  }

Response: 201 CREATED
Body: {
  \"id\": \"routine-uuid\",
  \"name\": \"Daily summary\",
  \"enabled\": true,
  \"trigger_summary\": \"Every day at 8:00 AM\",
  \"trigger_raw\": \"0 8 * * *\",
  \"trigger_type\": \"cron\",
  \"last_run_at\": null,
  \"next_fire_at\": \"...\"
}

If the eventual schema differs (e.g. nested trigger + action objects rather than flat fields), happy to remap inside the client — we just need the canonical shape to be stable.

Why this matters

Without a create endpoint, the desktop client's routines surface is read-only: users can manage existing routines but can't author new ones without leaving the app or invoking the CLI. This is the next routines feature blocked on a gateway gap.

References

• Desktop client method: src/lib/api/ironclaw.ts:1114 in abbyshekit/ironclaw-desktop
• Request type: src/lib/api/types.ts:150 (CreateRoutineRequest)
• Server file likely involved: src/channels/web/features/routines/mod.rs (add routines_create_handler alongside the existing routines_list_handler / routines_delete_handler / routines_toggle_handler)
• Router file: src/channels/web/platform/router.rs — add .post(routines_create_handler) to the existing /api/routines route