Skip to main content
opentrain todos manages the same Project To-dos list employers and AI trainers see in the product. Every fan-out command previews by default and writes only with explicit confirmation. The todos command tree requires CLI 0.5.4 or later:
The configured account must have the Project To-dos agent surface enabled. A full-access key supplies project_todos:read and project_todos:write, but it does not bypass that account gate; AGENT_SURFACE_DISABLED means the account needs enablement, not another token rotation.

Read and report

List output includes the flat item catalog, per-person progress, and a pre-pagination summary. Personal emails never appear; people are shown as contract IDs with masked names.

Create and assign (preview first)

Running without --confirm-live is a no-write preview: it prints the exact masked recipients and count, future-hire semantics, projected due/blocking behavior, duplicate candidates, warnings — and, for broad audiences, the preflight receipt token with its expiry.
  • --audience is always required; there is no default.
  • SELECTED takes repeatable --contract-id flags or --contract-ids a,b; duplicate or non-SELECTED stray IDs are rejected before any network call.
  • Broad live runs require --yes and --preflight-receipt from the preview you reviewed, so a roster or payload change since that preview fails server-side instead of assigning people you never saw.
  • --allow-duplicate overrides the exact-duplicate refusal.
  • todos assign-item and todos archive-item follow the same preview-then-confirm shape; the archive preview prints exactly how many open assignments will close.

Review and transitions

These single-assignment commands execute directly — no --confirm-live step. Pass a stable --idempotency-key so retries converge (one is generated when omitted). --expected-submitted-at is the stale-review guard: a resubmission in the meantime rejects the decision.

Enable, disable, and the raw escape hatch

todos manage cannot bypass safety: create_item, assign, and archive_item bodies are redirected to the focused commands, and fan-out actions without an explicit audience fail before any request is sent.

Quizzes

Quiz assignment requires an explicit stable --idempotency-key so a retry cannot create duplicate worker-visible obligations; broad quiz audiences require --yes plus --preflight-receipt from the reviewed preview. remediate plan validates a retake batch and emits the exact per-row commands to run individually. See the API reference for every field, and the concept page for the safety model.