BACK-604 - Allow explicit unassign in CLI and TUI when defaultAssignee is set

[MrLesk]

Problem

With defaultAssignee configured there was no way to create or edit a task so that it ends
up unassigned. -a "" was parsed by parseDelimitedStringList, which collapses a blank
value to undefined, so an explicitly empty -a was indistinguishable from an omitted one:
task create "T" -a "" still got the configured default, and task edit T -a "" was a
silent no-op.

The behaviour that was assumed to already exist on the other surfaces turned out to be
partly missing too (verified live before the fix):

Surface	Explicit empty assignee, before this PR
CLI task create / draft create -a ""	default applied (blank collapsed to absent)
CLI task edit -a ""	no-op
MCP task_create assignee: []	default applied
MCP task_edit assignee: []	no-op — buildTaskUpdateInput ran normalizeStringList, which drops []
Web PUT /api/tasks/:id assignee: []	cleared (the only surface that worked)
Web POST /api/tasks assignee: []	default applied
TUI	no assignee editing surface at all

So core.editTaskOrDraft already honoured an explicit empty list, but only the Web edit
payload could actually reach it, and createTaskFromInput treated an empty list as absent
on every surface.

Fix

One rule, applied in the shared core path: an absent assignee means "no opinion" (the
configured defaultAssignee applies on create, the existing value is kept on edit) and
an explicit empty assignee means "unassigned".

• src/core/backlog.ts — createTaskFromInput keys the default off input.assignee === undefined
  instead of "the normalized list is empty".
• src/utils/task-builders.ts — new parseClearableStringList preserves the absent-vs-explicit-empty
  distinction coming out of Commander (undefined when the flag is absent, [] when it is present
  with only blank values).
• src/cli.ts — task create, draft create and task edit use it for -a; task edit now sets
  the field even when the parsed list is empty. -a someone is unchanged.
• src/utils/task-edit-builder.ts — assignee resolves through the existing
  sanitizeClearableStringArray helper already used for dependencies/references/documentation, which
  fixes MCP task_edit in the same place as the CLI.
• src/web/components/TaskDetailsModal.tsx — the create payload omits assignee when the chip input
  is blank. The modal always sent assignee: [], so honouring the explicit empty at core would
  otherwise have silently disabled defaultAssignee for every Web-created task. A blank field on
  create now means "no opinion", exactly like an omitted -a; Web edit still sends [] and clears.
• Help text, the MCP task_create/task_edit schema descriptions, ADVANCED-CONFIG.md and the
  shipped task-creation instructions document the empty-value convention.

No new flags: the empty value works fine through Commander, so there is no --clear-assignee.

Not done: the TUI acceptance criterion

AC #3 ("The TUI can clear the assignee of a task") is left unchecked because the TUI has no
assignee editing surface to extend:

• the TUI create composer (src/ui/components/task-composer.ts) has only title, description,
  status, type and priority;
• the TUI edit action (src/ui/board.ts, src/ui/task-viewer-with-search.ts → core.editTaskInTui)
  shells out to $EDITOR on the task markdown, so the only TUI route to an assignee today is editing
  the frontmatter by hand;
• every other assignee reference under src/ui/ is display or filter-only.

The interactive assignee prompts that do exist are the clack CLI wizards in
src/commands/task-wizard.ts (task create / task edit with no flags in a TTY), not the TUI. The
edit wizard pre-fills the current assignees and already clears them when the field is blanked, so
interactive CLI clearing works today. Adding a TUI assignee field would be a new UI surface, so it is
left for a product decision.

Evidence

bunx tsc --noEmit clean, bun run check . clean, full bun run test green.

Tests added:

• src/test/core.test.ts — explicit empty assignee overrides defaultAssignee for tasks and drafts
  (the existing "applies defaultAssignee when created without an assignee" test is the control).
• src/test/cli-init-create.test.ts — task create -a "" with defaultAssignee set is unassigned.
• src/test/draft-create-consistency.test.ts — same for draft create.
• src/test/cli-task-view-edit.test.ts — task edit -a "" clears; a title-only edit keeps the
  existing assignees.
• src/test/mcp-tasks.test.ts — task_create applies the default, task_create with assignee: []
  does not, task_edit with assignee: [] clears.
• src/test/web-task-types.test.tsx — the create payload omits a blank assignee.
• src/test/cli-guidance.test.ts — help text documents the empty value.

Manual check with defaultAssignee: ["@alice","@bob"]:

task create "Control default"              -> assignee: ['@alice', '@bob']
task create "Explicit unassigned" -a ""    -> assignee: []
task create "Explicit carol" -a @carol     -> assignee: ['@carol']
draft create "Draft unassigned" -a ""      -> assignee: []
task edit task-3 -a ""                     -> assignee: []
task edit task-1 -t "renamed"              -> assignee: ['@alice', '@bob'] (unchanged)

For review

-a "" now means "clear", while #878 (BACK-603) made a blank value an error for --dep/--ref/--doc
on create, with --clear-refs/--clear-deps/--clear-docs as the clearing mechanism on edit. Assignee
has no --clear-assignee flag and the empty value is the mechanism approved for this task, so the two
list-flag conventions now differ. Flagging in case you want them aligned later.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9d272dec3a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".