[wagnercosta]

What

asknews stories list sent whatever was typed after --start-timestamp to the API as a string. The help labelled the option [query, string, optional], so an agent following the help naturally typed an ISO datetime (as news search --start-datetime and x --start-datetime take) and got back 422: Input should be a valid integer. In an agent evaluation, three different models hit that 422 on their first stories list call and only recovered by retrying with Unix seconds.

Changes

• stories list time bounds. New --start-datetime / --end-datetime (ISO 8601), mirroring news search and x. --start-timestamp / --end-timestamp keep the API's names, take Unix seconds, and accept an ISO datetime too; a value that is neither fails locally with a usage error instead of a 422. --hours-back keeps working as before.
• Generator: nullable parameters keep their real type. The OpenAPI schema publishes optional query parameters as anyOf: [{type: X}, {type: "null"}] with no top-level type, which the generator collapsed to string. 45 parameters were mislabelled this way (17 integers, 21 arrays, 4 numbers, 3 booleans), so the help misled the reader and the parser never validated them. extractParameters now reads the one non-null variant: --start-timestamp is integer, array parameters collect and split like the curated ones, enums on the variant become Choices in the help (for example --sort-by on stories list). The manifest, the command reference and the embedded skill references are regenerated from the pinned 0.32.3 schema; no schema refresh is included.
• Array parameters of the api commands now collect and split. A consequence of the type fix: api news search-news --string-guarantee "climate, change" used to send one element climate, change and now sends two, as the curated commands already do; the JSON form '["climate, change"]' still sends one.
• Skill: stories list then stories get. The task recipe now says what each step returns and that any question about how a story developed, its timeline or its latest update is answered from stories get <uuid>, never from the list alone (the list carries one update and no articles). It names the time-bound flags. In the same evaluation no model ever called stories get; they answered from the list.

After review

An independent review pass added three small changes in the second commit: --start-datetime together with --start-timestamp (or the end pair) is a usage error instead of a silent precedence; a boolean parse error names its option (--full-articles expects true or false), which the type fix made reachable; the skill names the update fields (updates[0].headline, updates[0].story).

Verification

• pnpm lint, pnpm typecheck: clean.
• pnpm test:coverage: 129 passed, 1 failed. The failure is output.test.ts > renders web search with field-accurate columns and provenance, which fails identically on an untouched main checkout in this environment (terminal hyperlink fallback); it is not touched by this change.
• New tests: stories list sends start_timestamp/end_timestamp as Unix seconds for all three input forms and rejects a non-date; a contract test asserts that every nullable schema parameter's manifest type matches its non-null variant.
• asknews stories list --help shows the four time-bound options with their descriptions.

Notes

• The weekly schema-drift workflow is already red on main (live schema 0.32.8 against pinned 0.32.3); that refresh is a separate fix: as usual.
• The docs site pages are synced from this repo at release time (pnpm sync:docs), so the stories page and the published skill pick this up with the next release.