[Bug]: opencli douyin draft failed

[heng-robot]

Description

I have logged in creator.douyin.com and "opencli douyin activities" works well . But it failed when "opencli douyin draft".
"
🔒 Not logged in to creator.douyin.com
→ Please open Chrome and log in to https://creator.douyin.com"

I'm sure I've already logged in the website.

Steps to Reproduce

1. Run opencli douyin draft --**
2. 🔒 Not logged in to creator.douyin.com
   → Please open Chrome and log in to https://creator.douyin.com
3. chrome tab : login status .

Expected Behavior

it works

OpenCLI Version

1.5.5

Node.js Version

22.x

Operating System

macOS

Logs / Screenshots

opencli -V
1.5.5

 node -v
v22.18.0

[Astro-Han]

I reproduced this locally with opencli v1.5.6.

What I observed:

• opencli doctor is OK, browser bridge is connected
• opencli douyin activities -f json works and returns data
• opencli douyin draft /tmp/opencli-empty.mp4 --title test -f json fails with:
  • 🔒 Not logged in to creator.douyin.com

So this does reproduce the issue pattern: a normal creator-center read command can work, while draft still reports "not logged in".

Main diagnosis:

• The failure happens at the first upload step in draft, inside getSts2Credentials()
• This does not look like a real login-state problem
• I manually fetched the same STS2 endpoint from the same browser context and it returned valid temporary upload credentials successfully
• That suggests the current code is likely parsing the STS2 response with the wrong shape and then mapping that parsing failure to AuthRequiredError

In other words, the current draft error message is likely misleading: the browser session is logged in, but the STS2 credential response is being interpreted incorrectly.

There also seem to be a couple of separate response-shape mismatches in other Douyin commands, but for this issue the primary problem is around the STS2 credential handling used by draft / publish.

[Astro-Han]

I was able to reproduce the issue locally and have submitted a fix here:

• fix(douyin): repair creator draft flow #640

The main problem is not that the browser session is completely logged out. The root causes were differences between the current Douyin creator center behavior and the assumptions in the existing implementation:

1. The original draft upload/save flow depended on an outdated creator upload path, which caused non-auth failures to be reported as Not logged in to creator.douyin.com.
2. The current creator API payloads no longer match the field shapes assumed by the code, which affected sts2, profile, and activities.
3. The custom cover flow also needs to wait for the creator page's local cover-check state to finish, rather than relying on coarse page-wide text checks.

This fix includes:

• compatibility updates for the current creator payload shapes in sts2, profile, and activities
• moving douyin draft onto the live creator page flow
• returning the real recoverable draft_id from the current page flow
• tightening the custom cover wait logic so it follows the local quick-check state transition, with behavior-level tests added for that path

I verified this locally with:

• pnpm vitest run src/clis/douyin/draft.test.ts
• pnpm vitest run src/clis/douyin
• pnpm run build
• a real douyin draft ... --cover ... -f json run, which now succeeds and produces a resumable draft

If you have time, please try the PR branch as well. Once the PR is merged, this issue should be ready to close.