Sync Work Items Recovery

/sync-work-items reads this when a run reports a terminal row, a refused pending push or an order-refused row. Its Read the run's output section holds the quoting, files-and-arguments and confirmation rules; every step here follows them. Each work sync order below is a discrete argv token, run only after the user confirms it.

Terminal recovery

A terminal row means something for the item may have landed, locally or in the tracker, so a re-run is never offered as the fix. Key the recovery on the row's state, the error: line's operation and the cause's step prefix (after <step>: ), read after any created <KEY>; at the start of the cause:

Order refusals

An order-refused row (<id>\tfailed\t-\torder-refused, or the item's own state when the order was refused while applying) carries a fixed cause on its error: line. Quote it, then take the next step it names:

An adopt on an incomplete corpus is not an order-refused row: its class is unparseable or retryable, and the #\tunidentified advice applies. An adopt that linked over different content says so on its own run with a note: <id>: adopt: line; /sync-work-items Step 3 handles the conflict that follows.

Pending-push recovery

A refused pending push is a terminal row whose error: line reads pending push refused (<reason>): …. The marker is at <paths.integrations>/<work.integration>/pending-push/<id>.json, built from accelerator config path integrations, the Active integration and a canonical id; read it with the Read tool. Every branch is settled by one work sync order, run only after the user confirms it:

• Show what the run reported: the reason token, the marker path, any carrier, and any created <KEY> at the start of this run's cause, the only key that counts as known. Quote the marker's contents only when the user asks to see them.
• --resolve <id>=adopt:<KEY> links an issue that exists. The CLI checks the key's shape, that the item carries no other external_id, that no other work item carries the key, and that the issue exists under that key, then links it and removes the marker. When the issue's title or body differ from the item's, the next sync reports a conflict to resolve as usual. Run it with --preview first and show the user the issue title its #\tadopt\t<id>\t<KEY>\t<title> record prints before confirming.
• --resolve <id>=create discards the marker and creates the issue in the same run, for an item the user has confirmed has no issue.
• Key known (a created <KEY> cause, or no refusal after one): offer adopt:<KEY>.
• prior-attempt-unknown: ask the user to search the tracker for the item's title first; offer adopt:<KEY> with a key they supply, or create when they found none.
• already-written: name the carrier the cause reports; never offer adopt or create, which the CLI refuses; ask the user which item is the real one.
• fingerprint-mismatch: the marker records the key of an issue that was created, and the item changed since. Offer adopt:<that key> first (the next run shows any difference as a conflict); the CLI refuses create unless that issue no longer exists.
• marker-unreadable: show the path; offer create only after the user has searched the tracker and found no issue, otherwise adopt:<KEY>.

Each order is a separate run:

accelerator work sync --target <id> --resolve <id>=adopt:<KEY>