# Decision: JianYing 6.0+ draft encryption

Status: **decided — detect, do not decrypt** (revisit gated, see below).
Scope: `draft_content.json` encryption introduced by JianYing (剪映) 6.0+.
Related: `capcut decrypt`, `docs/version-support.md`, pyJianYingDraft #142/#169/#174.

## Context

JianYing is the Chinese build of CapCut. From 6.0+ it stores `draft_content.json`
as an AES-encrypted binary payload instead of plaintext JSON. The Chinese README
is one of the most-viewed paths in this repo, so the JianYing lane has real
demand. The adjacent project `pyJianYingDraft` is larger and gets steady requests
to "just decrypt it." CapCut International is **not** encrypted — only JianYing.

The question for this repo: should `capcut-cli` ship a decryption routine?

## Decision

No. The CLI **detects** encryption and explains the workaround; it does not
decrypt. This is implemented in `src/decrypt.ts` (`detectEncryption`) and surfaced
by `capcut decrypt <file>`.

This is a gated compatibility decision, not a permanent refusal. It changes only
if every tripwire below clears.

## Why

- **Legal posture.** Shipping a routine whose only purpose is to undo a vendor's
  encryption is a different risk class from reading a documented plaintext format.
  The community-known algorithms are reverse-engineered, not licensed.
- **Algorithm in flux.** The keys/algorithm have shifted across JianYing point
  releases (see pyJianYingDraft #142/#169/#174). A decryptor would be a moving
  maintenance target with a high breakage rate per JianYing update.
- **The repo's differentiated claim is "local, deterministic, agent-drivable."**
  A brittle, legally-grey decryptor fights that claim. Detection + a clear
  workaround keeps the trust surface clean.

## What we do instead (and why it is enough for most users)

`capcut decrypt` reports the situation and points to, in order of preference:

1. Pin JianYing to 5.9.x and block auto-update (last widely-used plaintext line).
2. Use CapCut International — not encrypted.
3. For an already-encrypted draft, the community references (pyJianYingDraft #142,
   duoec/duo-video) — explicitly outside this tool.

Detection heuristic: a `draft_content.json` that does not begin with `{` and does
not parse as JSON is reported as the encrypted JianYing 6.0+ case; a file that
starts with `{` but fails to parse is reported as *corruption*, not encryption,
so the two failure modes are not conflated.

## Fixture collection (how we'd gather evidence without decrypting)

We can advance the JianYing lane without touching decryption:

- `capcut fixture <project> --out <dir>` produces a redacted, media-free bundle of
  the timeline files. For an *encrypted* draft this captures the envelope/markers
  (size, leading bytes via `diagnose`) so detection can be sharpened from real
  samples rather than guesses.
- Plaintext/exported JianYing variants (5.9.x, or 6.0+ "export project") can be
  added as committed fixtures and exercised by the normal command suite.

## Tripwires to revisit shipping decryption

Revisit only if **all** of these hold:

1. A stable, documented algorithm exists across at least two consecutive JianYing
   releases (not a single-version reverse-engineering).
2. The legal posture is clear enough to state in the README without hedging.
3. There is a maintainer commitment to track JianYing releases, because a
   decryptor that silently breaks is worse than an honest "not supported."

Until then: detect, explain, and collect fixtures. Do not decrypt.