v1.11.0

• D is a three-part modal instead of a one-line prompt. Delegating now
  asks the three questions a delegation actually has — who (a person or the
  agent pool), which mode, and the note the receiver works from — on a modal
  that is complete by keyboard and by mouse. Re-delegating prefills all three
  from the current marker, and one submit writes them in a single undo step.
  Release and undelegate are explicit affordances, and both confirm before they
  act, which retires the old flat word grammar: implement,
  release and the clear words used to share one text field, so the shortest
  inputs performed the widest and most destructive actions and a three-letter
  prefix minimum was the only thing standing between a keystroke and a revoked
  claim. Typing a verb into a text box is no longer how work is taken away.

• The three-part delegation reaches the CLI and HTTP. tasks delegate <ref> <mode> --note "…" writes who, in what mode, and the briefing the receiver
  reads in ONE store write and therefore one undo step — no surface composes a
  delegation out of a delegate followed by a note write. --note-file <path>
  and --note-file - (stdin) exist because a long briefing written by an agent
  should not have to fight shell quoting. A mode is now accepted alongside
  --to <email>, so a person can be asked for a refine just as an agent can.
  Omitting the note keeps any existing briefing — restating the mode must not
  silently erase instructions — and --note off/none/"" clears it, the
  same two words a work reference clears with and both already reserved mode
  names, so a clear instruction can never be read as a mode. tasks delegate <ref> --note "…" with no mode and no --to rewrites the briefing in place,
  for an owner correcting instructions without re-sending a delegation.

• Delegation reads show all three parts. show prints the mode and the
  briefing in full, list --delegated and list --agent-ready print the mode
  in the headline with a one-line preview of the note beneath it, and --json
  carries both as first-class members of the delegation object everywhere —
  including list --agent-ready --json, which is what an agent heartbeat
  reads.

• The HTTP delegation writes work. POST /api/v1/tasks/{id}/{delegate, undelegate,claim,release}, PUT …/work_ref, and the new PUT …/delegation_note answered 501 because the mandatory If-Match could not
  be honoured — the store did not compare a revision inside its delegation
  transaction, and dropping a precondition a client set is worse than refusing.
  It does now, under the same lock the write runs in, so the routes perform the
  operation with their preconditions intact: 200 with the whole canonical
  task and a fresh ETag, 412 on a stale revision, and 409 on a lost claim
  race carrying holder and at as their own fields rather than as prose an
  agent would have to re-parse.

• Answer a proposal for work that is already done in one keystroke. On a
  PROPOSED row c now approves the proposal AND completes the accepted task in
  a single write and a single undo step, so undo restores PROPOSED exactly;
  rejecting was previously the only one-key way to clear such a row, and it
  recorded a decline — the wrong history, and the wrong signal to whoever
  proposed the task. The store still never completes a PROPOSED task: the
  approval lands first inside the same transaction. tasks approve <ref> --done and POST /api/v1/tasks/{id}/approve?complete=true are the CLI and
  HTTP spellings of the same shared command, both --json/ETag-honest. The
  proposal row's key hints now describe what the keys actually do.

• Refuse a recurring proposal in check. Recurrence is a schedule for accepted
  work — completing a recurring task rolls it forward instead of finishing it —
  and no write path could ever produce the shape, but a hand-edited, repaired,
  or foreign-device file could, and it passed validation. Now recur on a
  PROPOSED task is a check error, and approve+complete refuses it rather
  than reporting a DONE that did not happen.

• A delegation becomes three orthogonal parts — who (a person or the agent
  pool), mode (refine/research/implement), and a new optional
  note, free text briefing the receiver on how to work on the task and
  where the work should land, up to 2000 characters with paragraphs allowed.
  Store and schema support only in this entry; the CLI, HTTP, and TUI
  spellings follow in the surface work. The note is stored last in the marker,
  so a store written by an earlier release loads, checks clean, and re-emits
  byte for byte. A mode is now valid on a human delegation as well: "Pat,
  this is a refine" is a thing the data model can say. The note travels with
  the delegation it briefs — kept across a mode change or a new assignee of the
  same kind, dropped when a person replaces the pool or the reverse — carries
  its own transition stamp on an unclaimed delegation so the most recent
  briefing wins a multi-device merge (a note on a live claim leaves the claim's
  own stamp alone, so briefing a working agent survives a sync), and merges
  atomically with the rest of the marker, where undelegate still always wins.

• The mode vocabulary is carried as a value on the store and checker options
  rather than checked against a literal, so configuring the set later is one
  field, not a hunt through the code.

• The delegation mode vocabulary is yours to choose. delegation_modes = triage, ship in ~/.config/tasks/config (or TASKS_DELEGATION_MODES)
  replaces refine, research, implement everywhere at once: what tasks delegate <ref> <mode> accepts, what a refusal quotes back, the delegate
  usage line, tasks help, the TUI ? overlay and delegate modal, the check view,
  and the API's vocabulary document. A mode is a bare lowercase word and
  carries no label — the label is the word. With no config key, behaviour is
  exactly what it was.

• A delegation_modes list this binary cannot honour — a word of the wrong
  shape, a duplicate, a reserved word, an empty list — is ignored whole, with
  a warning on stderr naming the problem and the set actually in use. Keeping the readable
  half would run you against a vocabulary you never wrote. Nothing about a bad
  list makes the store unreadable or unwritable.

• A record whose mode the active vocabulary does not list still loads, shows,
  and checks: check reports it as a WARNING, never an error. Which words are
  listed is a setting, and settings change — editing delegation_modes, or
  syncing a file from a machine configured differently, can no longer invalidate
  a file your tasks live in. A stored mode of the wrong shape is still an
  error, and writing an unlisted mode is still refused.

• tasks config and tasks config --json report the resolved
  delegation_modes and where they came from, alongside every other setting.

• off, none, clear, and release are reserved and cannot be configured as
  modes: release is a delegation verb and the others clear a work reference or
  a note, so a mode spelled like one of them would make an instruction and a
  mode indistinguishable wherever both are written in one place. The collision
  is reported when the config is read, not at the moment the verb is needed.

• Hosts embedding the TUI through pkg/tui get ExportCommandsWith(modes) to
  describe delegation with their own store's vocabulary; plain ExportCommands
  now renders the built-in set rather than an unfilled template.