849879772 / schedule-management

Schedule Management

1. Query the requested date or range and identify timezone, application, source, and conflicts.
2. Prefer evidence from associated recruitment mail or explicit user input.

3. Create or update events idempotently. Do not duplicate the same test or interview.
   For an explicit local todo or calendar mutation, use schedule_manage: create requires a
   stable request_key, and reusing that key with a different normalized payload is a conflict.
   Update uses event_id; pass expected_updated_at when available to avoid overwriting a
   concurrent edit. This local write does not change application progress or require the
   application approval flow.

4. Do not call schedule_manage(action=create) to recreate items produced by
   recruitment_mail_process. If a user explicitly asks to edit an existing returned item,
   schedule_manage(action=update) is allowed and must preserve its source identity.
   Mail-derived assessment, written_test, interview, and action_required records already
   return their source-bound schedule_item; company-only items may intentionally have no
   application_id.
   A company-wide assessment/written-test mail can have multiple human-confirmed
   application_ids/associated_jobs on that single schedule item. Do not copy the
   event per job. Time/status/note edits must preserve all these relations; changing
   them belongs to the source mail's human-approved binding, not a single-job editor.

5. Keep schedule identity explicit. company_name is required; job_title may be empty for a
   company-wide task. When application_id is supplied, the company must match that application
   and a non-empty job must match it too; an empty job is completed from the selected application.
   Resolve the application first rather than guessing a binding.
   For an existing item whose application binding is unchanged, update only the requested fields
   (for example status and expected_updated_at); do not resend company/job display labels.
   Omitted labels are refreshed from the bound application, so historical spelling or name changes
   do not block a status, time, or note update. Explicit identity edits and a new binding are still
   validated against the selected application.

6. Keep time semantics factual: an item without event_date has time_kind=unspecified; adding
   a date canonicalizes it to appointment unless it is explicitly a deadline. A date without a
   clock remains date-only, and no duration or appointment end time may be invented.

7. Ask only when time, target application, or requested mutation is ambiguous.
8. Report conflicts and persisted changes explicitly.

9. For a recurring request to "update/check" a company or job that already exists in the
   application database, resolve the application first and map the request to the local
   application_progress task. This is an application status review, not a crawler refresh.

10. Use only the four local task identifiers documented in AGENTS.md. Never mention cloud
    scheduling, GitHub Actions, or legacy task aliases as current capabilities.

11. A direct recurring-task request is already authorization for the reversible local schedule
    write. Call automation_schedule and verify active=true; do not stop at automation_plan.
    Bind an application progress schedule to the resolved application_id. Use list/disable tools
    for status or cancellation requests.