Approvals and schedules

Outcome

You can resolve an attempt-scoped tool approval and manage a schedule without bypassing generation, budget, tenant, or idempotency fences.

Prerequisites

Read the execution and state model. Use an authenticated project and preserve the current aggregate and schedule versions returned by the API.

Steps

1. List an attempt's approvals, inspect actor, exact action, normalized arguments, target, data exposure, budget impact, policy version, generation, expiry, and argument hash, then resolve the exact approval through its authenticated REST command. Allow, deny, and expiry remain durable product outcomes; a runtime prompt is not authority.
2. Create a project schedule with a frozen run template: title, objective, model profile, hard cost ceiling, up to 32 unique dataset artifacts, notification_policy: "none", and overlap policy skip or buffer_one.
3. Set a whole-second, timezone-aware starts_at. Omit every_seconds for one execution, or choose an interval from 60 seconds through 365 days with an optional later ends_at.
4. Read desired_state (active, paused, or deleted) separately from provider sync_state (pending, applied, or rejected). Update, pause, resume, and delete with expected_version.
5. Treat each Temporal firing as an ordinary idempotent run with the template's budget, profile, and datasets. The five-minute catch-up window and overlap policy never grant extra authority.
6. When a trusted connector presents a notification reply, accept only the closed pause_schedule action for its authenticated recipient and exact workspace, project, source run, schedule, and schedule version. The authority expires within seven days and is consumed once as the ordinary PauseScheduleCommand; reply text is never accepted as a prompt or instruction.

Verify

A changed argument hash or generation requires a new approval. Repeating the same command identity returns the same accepted result. A schedule cannot bypass a hard budget, tenant boundary, cancellation policy, or explicit provider profile; inspect its resulting ordinary run and event cursor. A repeated, expired, wrong-recipient, cross-run, or cross-workspace notification authority is rejected, while an accepted reply emits the same canonical schedule.paused event as the REST command.

Recover

If an approval outcome is ambiguous, keep work paused and reload the durable request before any side effect. If schedule synchronization is rejected, preserve last_error_code, correct the versioned configuration, and retry reconciliation. If an invocation overlaps unexpectedly, pause future starts and preserve the ordinary run for inspection.

Next task

Understand execution and state.