jianying-draft-schema

JianYing Draft

Used to construct or review structured Job/Plan; not responsible for bypassing the CLI to write draft protocols directly.

When to use

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

Capability boundaries

• ✅ Can do: Generate deterministic plans based on real paths and probe results; execute domain operations when capability is supported ; output the actually achieved evidence level.
• ⚠️ Requires conditions: Writes must use isolated copies; costs, 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, do not fabricate resource IDs, media facts, or success states.

Step 1 — Establish a factual baseline

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

Step 2 — Handshake capabilities

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

Step 3 — Validate inputs

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 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. On ambiguous output, timeout, or partial success, 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 goal; report the actual level, failed fields, recoverable actions, and unverified items.

Rules

• Material durations, 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; re-confirm if any field changes.
• 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; it is forbidden to fill in results with inferences.

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 final film acceptance: project verify 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 stop and be changed to a new output.
4. Automatically retry ambiguous: First query the task, audit, and external artifacts; only after confirming no side effects occurred may the user approve a retry.
5. Fill in resources or times from memory: Resource IDs come from the catalog, times come from probe/ASR/project data; if unobtainable, explicitly block.
6. Vaguely ask for more information: First give an executable read-only plan, then explicitly list gaps such as paths, delivery level, or authorization.

Verification checklist

• CLI identity, version, and capability recorded.
• All input paths, media facts, and hashes are reviewable.
• Write target is isolated from source draft; confirmation points are precisely bound.
• Failure and ambiguous paths retain task ID, logs, and recovery suggestions.
• Final wording matches the actual evidence level.

Run contract

• Trigger conditions: user needs Job/Plan Schema, domain objects, timeline structure, v1 compatibility, or version diagnostics.
• Required capability:schema.job_v2、schema.plan_v1_compat。
• Minimum CLI version:1.6.0; a capability handshake is still required before submission.
• Default risk:read_only; generating a plan only does not produce draft side effects.
• Input facts: target operation, new or existing draft, canvas/FPS, material probe results, track and segment time relationships, expected evidence.
• Confirmation points: plan compilation requires no confirmation; when executing the plan, confirmation is bound by the specific write or external operation.
• Success evidence:plan; Schema validation passing does not equal draft structure or real Jianying validation passing.
• Prohibited actions: must not generate Python draft scripts, must not call external headless checkout, must not directly spell out private wire fields not validated by Schema.

Core rules

• Root schema is jianying-job/v2, operation is create/edit/inspect/verify/publish/export/batch.
• Time uses integer microseconds; frame-sensitive positions also obey the project's FrameRate quantization results.
• New projects use project.type = new; existing drafts use existing, and an isolated output must be provided when writing.
• Materials first media probe --json, do not substitute designed duration for measured facts.
• v1 input can only be placed in the compatibility envelope, converted by the CLI with field-level diagnostics returned.
• Unknown schema, breaking version, or missing capability must fail structurally.

Field model, operation selection, and verification levels are in references/workflow.md. Executable minimal example in examples/minimal-job.json。

Progressive materials

• On first execution, load normal path to get the end-to-end sequence.
• When encountering failure or unknown state, load failure recovery and error recovery table。
• When the user requests privilege escalation, overwriting, or automatic retry, load boundary refusal。
• Before delivery, complete item by item the verification checklist, and do not claim completion based only on a plan or file existence.