fix: leave the container limit to the API, and release a spec sync only when the CLI changes

[yiichou]

Stacked on #51. Once #51 is merged, this needs a rebase onto main.

Why

The published openapi.yaml is now in English. Running the sync locally against it showed one problem in #51. The new spec also changes several request bodies (random_choices on the choice fields, a new GoodsItemUpdateInput, keys moved within FieldUpdateInput), so spec-diff titled the sync feat: follow openapi.yaml changes to createForm, createTable, updateForm and 1 more. But the CLI sends bodies as given, so those schemas change nothing it does; only its tests read them. Merging that sync would have cut a release with no change in it, and a changelog line saying otherwise.

Comparing the two specs also turned up a container limit the CLI kept a copy of, and help text still naming payment numbers in Chinese.

What changed

• spec-diff decides feat from what the CLI does with the spec at run time. A sync is a feat when the method, path or parameters of an operation the CLI calls change, or a list of values a flag reads with choices / bodyChoices. A request body, an operation the CLI does not call, or prose is a chore. spec-diff reads the lookups off the source and stops if one does not name its operation and field in literals, so the refund/payout options now pass the lookup from the call site. src/spec-diff.test.ts covers each case against the spec in the checkout.
• entry count no longer refuses an eleventh container. The API states the limit of 10 in its prose, not its schema, so the CLI's copy would keep refusing after the API took more. The API answers with a 400 that says so. The help still says up to 10.
• Payment help uses the spec's English names: WeChat Pay / Alipay, trade_no / merchant_out_trade_no / out_trade_no, refund_no, payouts. 小金商户 stays, as the spec keeps it.

Against the English spec

With these changes, the sync of the current published spec comes out as:

chore: sync openapi.yaml, nothing the CLI checks or offers changed
- Request bodies the CLI sends as given changed, for the API to judge; the tests hold the CLI's own bodies to them: createForm, createTable, updateForm, updateTable
- Schemas changed: CheckBoxInput, DepartmentInput, … (16)

npm run check and all tests also pass with that spec in place of the bundled one, so the first workflow_dispatch after merge should open a green chore PR.

Noticed, not changed here

The spec says "Required." in the description of metrics (the four aggregate operations) and form_tokens (countEntriesAcrossForms) but has required: false in their schema. If it marks them required, call() checks them for free.

Testing

• npm run check and npm test (282 tests) pass on each of the three commits.

Refs: #T17509

🤖 Generated with Claude Code

[yiichou]

Test results

Unit tests. npm run check is clean and npm test passes, 282 tests. Each of the three commits also passes on its own.

1. When a sync releases. I ran the steps of spec-sync.yml locally against the spec published today:

• Regenerating, check and test all pass, and the title comes out as chore: sync openapi.yaml, nothing the CLI checks or offers changed.
• With listSmsAuditStatuses removed from that spec, check fails and the title is feat: follow openapi.yaml changes to listSmsAuditStatuses. The PR body then shows the type error at src/commands/sms.ts.

2. entry count against the live API (read-only):

• With 10 forms it answers 10 rows.
• With 11 forms the request is sent and the API answers 400 At most 10 forms can be counted in one call, got 11.
• One form still counts normally, and several forms with --keyword are still refused locally.
• Behaviour change: 11 containers now exit 5 (refused by the API) instead of 2 (usage). A script that checked for 2 there needs updating.

3. Payment commands. I built #51 and this branch and compared them:

• --help for every command: the only differences are the 4 lines of wording this PR changes.
• Every flag that offers a fixed list of values: all 19 lists are identical, including refund/payout --status and --include.
• Bad values are still refused locally with exit 2.

The test account has no 小金商户, so the live payment calls answer 404. A raw request with paid_status=bogus gets a 400 from the API's request check before it reaches that 404, so the API checks parameters first. The requests the CLI sends, paid_status comma-joined included, pass that check.