tasqx-workflowlisted

# tasqx workflow The MCP server sends the loop itself on connect — search before you decide, track multi-step work as tasks, brief then start then annotate then complete, store a decision with its why — and CLAUDE.md carries the setup-specific rules. This file holds only what neither says. tasqx is one JSON API behind three clients: the CLI, an MCP server (thirty-two `tasqx_*` tools), and HTML reports. Prefer the MCP tools. Fall back to the CLI for the verbs the MCP deliberately lacks: `next`, `why`, `agenda`, `chart`, `export`, `import`, `report --html`, `memory import`, `undo`, `use`, `archive`, and `tasqx --no-daemon tokens recompute` (refused over the daemon socket). ## Checks are claims, annotations are prose An acceptance criterion goes in `tasqx_add_check`, never in an annotation: a check has a state that completion can be measured against. tasqx never runs a check — the criterion is a claim and the evidence a citation — so mark them with `tasqx_set_check` or `checks_passed` on completion, each with `evidence`. `failed` is a normal outcome worth recording; remove a check only when the criterion was the wrong thing to ask. Everything else is an annotation, stored verbatim. ## Reading a task The answer is the rendered markdown alone (D151); use it as-is, and pass `include_json: true` only when a script needs the raw JSON beside it. `tasqx_brief_task` derives its memory query from the task's title, tags and project, so you never guess terms that silently find nothin