jianying-recover

JianYing Recover

Restore failed tasks, transaction snapshots, and external operation status. First determine the side effects that have already occurred, then choose the recovery action.

When to use

• The user explicitly requests the CapCut capability corresponding to this skill's title and accepts handling it through the unified Rust jianying CLI.
• The user needs an auditable plan, execution, or verification evidence, rather than just a conceptual answer.
• When the requirement is not yet clear, first hand it to jianying-use for routing; this skill should not be used to handle other editors, ordinary video knowledge Q&A, or speculative execution lacking necessary materials.

Capability boundaries

• ✅ Can do: Generate a deterministic plan based on real paths and probe results; when capability is supported , execute operations in this domain; output the evidence level actually achieved.
• ⚠️ Requires conditions: Writes must use an isolated copy; fees, external services, and native application actions must have precise approval; playback or export conclusions must have corresponding runtime evidence.
• ❌ Out of scope: Do not automatically install or upgrade the CLI, do not generate Python draft scripts, do not call external headless checkout, do not overwrite source drafts, and do not fabricate asset IDs, media facts, or success statuses.

Step 1 — Establish a factual baseline

Record the user's goal, absolute paths, host platform, target deliverables, and allowed side effects; when information is insufficient, first provide a read-only diagnostic plan and list the missing facts item by item.

Step 2 — Handshake capabilities

Run version, doctor, and capabilities checks. A satisfied version does not mean the capability is available;partial、external_dependency or a missing status must enter the degraded path.

Step 3 — Validate input

Probe media, drafts, configuration, or task status; reject nonexistent paths, out-of-range times, unknown schemas, mismatched hashes, and approvals that cannot be bound to a target.

Step 4 — Form a deterministic plan

Write the operations, parameters, output paths, risk levels, confirmation points, and expected evidence into the plan. Order multiple tasks as "read-only facts → reversible writes → external/native actions".

Step 5 — Execute or stop before the gate

Execute only supported and authorized steps. When output is ambiguous, times out, or partially succeeds, retain the task ID, audit logs, and artifacts; do not automatically retry.

Step 6 — Verify and deliver

Run structural validation, then append cold reopen, playback, or native export evidence according to the target; report the actual level, failed fields, recoverable actions, and unverified items.

Rules

• Media duration, dimensions, streams, hashes, and draft versions in the plan must come from tool output.
• Approval must be bound to the command, parameters, target, validity period, and budget; if any field changes, reconfirm.
• User data is processed only within local target paths and the declared external Provider boundary; unrelated credentials must not be collected, uploaded, or logged.
• When current evidence is insufficient, use UNVERIFIED、BLOCKED or AMBIGUOUS, and do not fill in results with inference.

Gotchas

1. Treating version as capability: Always check the specific capability; do not execute directly just because the CLI version is new enough.
2. Treating structural validation as film acceptance: project verify It only proves the structural layer; playback and native export require independent evidence.
3. Directly modifying the source draft: First create an isolated copy and record the input hash. Any in-place overwrite request must be stopped and changed to a new output.
4. Automatically retry ambiguous cases: First query the task, audit, and external artifacts. Only after confirming that no side effects occurred can the user approve a retry.
5. Filling in resources or times from memory: Resource IDs come from the catalog, and times come from probe/ASR/project data; if they cannot be obtained, explicitly block.
6. Vaguely asking for more information: First give an executable read-only plan, then explicitly list gaps such as paths, delivery levels, or authorization.

Verification checklist

• CLI identity, version, and capabilities have been recorded.
• All input paths, media facts, and hashes can be reviewed.
• Write targets are isolated from source drafts, and confirmation points are precisely bound.
• Failure and ambiguous paths retain the task ID, logs, and recovery recommendations.
• The final wording is consistent with the actual evidence level.

Run contract

• Trigger conditions: task failure/interruption/ambiguity, incomplete draft writing, need to roll back to a snapshot or relink materials.
• Required capabilities:job.show、job.retry、job.audit、store.restore。
• Minimum CLI version:1.6.0; before recovery, complete the capability and runtime identity handshake again.
• Default risk:high_risk_write; show/audit is read_only.
• Input facts: task ID, state root, audit events, source/working copy/snapshot, external artifacts, current hashes, and editor state.
• Confirmation points: retry, restore, overwrite target, resubmit a paid request, or restart the native task, each confirmed separately.
• Success evidence:structural; after recovery, the cold reopen, playback, or export acceptance of the original goal still needs to be completed again.
• Prohibited actions: do not generate Python draft scripts, do not call external headless checkout, do not guess that an ambiguous request was not executed, do not overwrite user drafts in place, or delete recovery evidence.

Workflow

1. job show and job audit to get the status, last checkpoint, and recovery command.
2. Check the output, snapshot, and external artifact hashes, and distinguish clear failures from ambiguous ones.
3. For a clear failure, after fixing the input and obtaining new approval, job retry。
4. Draft transactions use store restore or the snapshot recovery given by the audit; before recovery, ensure that Jianying is not occupying the target.
5. Rerun project verify, and continue the evidence gates required by the original task.

For state decisions and recovery cases, see references/workflow.md. For the verification Job, see examples/minimal-job.json。

Progressive materials

• For first execution, load normal path first to get the end-to-end order.
• When encountering failure or an unknown state, load failure recovery and error recovery table。
• When the user requests exceeding authority, overwriting, or automatic retry, load boundary refusal。
• Before delivery, complete verification checklistitem by item; do not claim completion based only on a plan or the existence of files.