Summary
cli/src/apply.ts:978 parses the application-form schema assuming the Feishu (lark) native field shape, but ByteDance's own ATSX endpoint returns fields under different names. As a result, step 1 of the 3-step apply flow appears to "fail" — the schema is fetched, but no fields are recognized and the staged payload looks empty.
Why this is misleading
The CLI reports endpoint_verified: true and the code comment claims "same route as Feishu adapters; verified in 1.0.62". The route is the same, but the response envelope is not. So callers see a green light at the gate and a confusing emptiness at step 1.
Repro
```bash
job-pro apply --job 7526958357153368328 --schema
```
Compare the raw JSON from `jobs.bytedance.com` (ATSX) against what `apply.ts:978` extracts — field names like `name`, `email`, `phone`, `resume` show up but their container/keys differ from the lark-native shape.
Fix sketch
- Branch the schema parser on host: `jobs.bytedance.com` (ATSX) vs lark-native Feishu Recruit.
- Add a fixture-based test: a captured ATSX schema response + assertions on the 4 required fields.
- Drop or qualify the "verified in 1.0.62" comment — it was verified against lark, not ATSX.
Impact
End-to-end ByteDance auto-apply is not working today, despite the CLI's "45/50 apply-ready" framing. The first three gates (env consent / ready / endpoint_verified) pass, but step 2 of the Feishu 3-step upload (upload token → PUT file → POST applications) is never reached because step 1's parsed schema is wrong, and even if you bypass that, `~/.jobpro/bytedance.session.json` is required and the extension can't capture it (see related extension issues).
Summary
cli/src/apply.ts:978parses the application-form schema assuming the Feishu (lark) native field shape, but ByteDance's own ATSX endpoint returns fields under different names. As a result, step 1 of the 3-step apply flow appears to "fail" — the schema is fetched, but no fields are recognized and the staged payload looks empty.Why this is misleading
The CLI reports
endpoint_verified: trueand the code comment claims "same route as Feishu adapters; verified in 1.0.62". The route is the same, but the response envelope is not. So callers see a green light at the gate and a confusing emptiness at step 1.Repro
```bash
job-pro apply --job 7526958357153368328 --schema
```
Compare the raw JSON from `jobs.bytedance.com` (ATSX) against what `apply.ts:978` extracts — field names like `name`, `email`, `phone`, `resume` show up but their container/keys differ from the lark-native shape.
Fix sketch
Impact
End-to-end ByteDance auto-apply is not working today, despite the CLI's "45/50 apply-ready" framing. The first three gates (env consent / ready / endpoint_verified) pass, but step 2 of the Feishu 3-step upload (upload token → PUT file → POST applications) is never reached because step 1's parsed schema is wrong, and even if you bypass that, `~/.jobpro/bytedance.session.json` is required and the extension can't capture it (see related extension issues).