From the IDE, cancel or relaunch the job

What you are seeing

Sprint 114 taught IDE agents to wait for a terminal AAP job and summarize a bounded stdout tail. Sprint 117 wrote that outcome on the ticket. Sprint 118 let them export and sync Configuration-as-Code. Then they stopped.

A wrong inventory or a hung run still had no recover path. A missing URL, missing token, or license cap still looked like a mystery 4xx. The operator loop was observe-and-stuck.

Sprint 119 ships AAP recover + operator UX: confirm-gated cancel and relaunch, a read-only connectivity and license snapshot, and thin failure Skills.

Still out on purpose: Crane job cancel, SPA Launch UI. post_aap_launch stays policy + confirm:true. There is no public POST /aap/cancel or /aap/relaunch. MCP does not accept or return AAP tokens.

Confirm is the gated act

Use post_aap_cancel with job_id=<id> confirm=true.
Tell me the job_id and status. Do not pass a token.

Missing or false confirm refuses without calling Controller. Same for post_aap_relaunch.

Relaunch returns a new job

Use post_aap_relaunch job_id=<id> confirm=true.
Give me the new job_id and job_ui_url. Then poll get_aap_job.

Relaunch starts a new run from the same job. Use the new id, not the source id.

Why is AAP blocked?

Use get_aap_connectivity.
Tell me whether the URL is configured, whether a token is present, and the license snapshot.
Do not print any token values.

url_configured and token_present are booleans. License comes from the existing snapshot — no secrets.

Same capability ids on HTTP /mcp/ and stdio. After you take the appliance update, fully restart the IDE MCP process so cancel, relaunch, and connectivity appear.

Default Skill ide_ticket_to_playbook still does not launch and does not cancel or relaunch. ide_ticket_to_job_outcome still says do not cancel. Use ide_job_recover when you want status → confirm-gated cancel or relaunch → poll.

Failure packs (read-only): ide_aap_unreachable, ide_aap_license_blocked, ide_aap_scm_failure.

PAT and transport: MCP quickstart (Configuration → MCP Connect).

Why it matters

• For IDE agents: stop a hung job or rerun a bad inventory without leaving chat.
• For operators: ask “can I create / launch?” and get URL / token / license instead of a mystery 4xx.
• For the product: observe, write-back, CaC mutations, and recover are now one IDE operator loop. Crane job cancel stays demand-gated.

Try it (about five minutes)

Goal: inspect a job, cancel or relaunch it with confirm, and see why AAP would block a create.

0. Prerequisites

• Appliance running with AAP (or lab Controller) configured.
• PAT from Configuration → MCP Connect (or HTTP /mcp/ with Bearer).
• A known job_id from post_aap_launch or get_aap_job. Do not paste tokens into chat.
• Reload stdio or Cursor after the update so cancel, relaunch, and connectivity appear.

1. See the job

Use get_aap_job with job_id=<id>.
Tell me status, and whether it looks hung or failed.

2. Connectivity

Use get_aap_connectivity.
Is the URL configured? Is a token present? What does the license snapshot say?

3. Cancel

Use post_aap_cancel job_id=<id> confirm=true.
Tell me the job_id and status. If Controller is down, say aap_unavailable.

4. Or relaunch

Use post_aap_relaunch job_id=<id> confirm=true.
Give me the new job_id and job_ui_url. Then poll get_aap_job.

5. Optional Skill

Follow ide_job_recover for job_id=<id>.
Mutations only with confirm:true. Do not pass tokens.
Do not cancel from ide_ticket_to_playbook.

Still open

On purpose, this slice does not add:

• Crane job cancel or poll-until-done on MCP
• SPA Launch UI

post_aap_launch remains policy + confirm:true.