Edit Issue - .issue.db

Title *

Description

All poll watches share job_name 'agent_sched_'+def_id[:8] where def_id is the FIXED SCHEDULED_AGENT_DSL definition -> every poll watch collides on one job_name (agent_sched_d0a0cb4c). stop_gmail_watch only DEACTIVATES (POST /workflows/schedules/{name}/cancel sets is_active=f; the API DELETE is also a soft cancel - row persists). On recreate, watch_gmail calls tools.cron.durable_cron with the same job_name; durable_cron is idempotent-by-job_name so it SKIPS, leaving the schedule inactive with the OLD goal -> recreate silently no-ops (goal change never takes; watch appears 'active' in the tool return but workflow_schedules row stays is_active=f). Observed while deploying #783: had to hard-DELETE the public.workflow_schedules row (DELETE FROM ... WHERE workflow_name='agent_sched_d0a0cb4c') before recreate produced a fresh active schedule with the new goal. FIX OPTIONS: (a) stop_gmail_watch hard-deletes the schedule (real DELETE, not soft cancel) so recreate is clean; (b) durable_cron upserts target_params/goal when job exists; (c) make job_name encode the goal/config hash so different goals don't collide. Also: /api/v1/schedules/{id} DELETE is a soft-cancel that leaves the row - misleading ('status: deleted' but row remains). Secondary: subject:highway match also catches GitHub CI notification emails (repo path contains 'highway') - consider tightening match guidance.

Due Date (YYYY-MM-DD)

Tags (comma separated)

Related Issues (IDs)

Enter IDs of issues related to this one. They will be linked as 'related'.

Edit Issue #784