/ca-task

name: ca-task
description: Add, select, start, complete, or reopen local work through its owning store.
argument-hint: "add <description> | list | start <WORK-ID> | done <WORK-ID> | reopen <WORK-ID>"

$ca-task — selected local work

Use the installed `hooks/work.py` facade for ordinary work in both native and legacy projects. It selects the current owner, gives new work a stable `WORK-ID`, and performs one semantic action through that owner. Existing boards stay legacy until an explicit adoption. Do not create a board beside native work or write both owners. A mixed or unsafe store is a refusal to report, not a reason to switch writers.

Before invoking the helper, read the installed helper card:

[includes/helper-invocation.md](../../includes/helper-invocation.md) relative to this loaded skill.

Use this loaded command or skill as the card's resource input and resolve `hooks/work.py` exactly once. Run it with the card's selected Python interpreter from the intended project worktree. Keep caller text in literal arguments; do not interpolate it into shell syntax or search for a source/cache copy.

Ordinary actions

• **List or select:** `work.py list --limit 32`; continue with

`work.py list --offset <next_offset> --membership-sha256 <returned-sha256>` until the item is found or the listing is exhausted. Then use `work.py get <WORK-ID>` for the selected item. Use the returned `work_id`, not a title or dotted legacy alias. If the complete listing has no item or selection is ambiguous, stop and report it.

• **Add:** `work.py create --title <description> --intent <description>

--type unknown --operation-id <stable-request-id>`. Pass `--origin <source-key>` when work comes from a durable source. A distinct action gets a new request ID; an uncertain retry keeps the original ID. Use the returned `work_id` for later actions.

• **Start:** `work.py start <WORK-ID> --operation-id <stable-request-id>`.
• **Complete:** `work.py complete <WORK-ID> --operation-id <stable-request-id>`.

Queued work already performed can be recorded complete directly. Do not invent a start event. This records local progress; checks remain unknown until their actual evidence is assessed.

• **Reopen:** `work.py reopen <WORK-ID> --operation-id <stable-request-id>`.

For native projects that explicitly configure `work.py transition-map-configure`, these same start, complete and reopen calls save their configured issue and single-select Project intent, or a specific waiting reason, in the same local work transaction. The transition makes no GitHub request. An absent or disabled map leaves ordinary lifecycle behavior available. Read `work.py get <WORK-ID>` or `work.py view <WORK-ID>` for separate local progress, check, delivery and tracker states. `work.py transition-map-get` shows whether the selected native project opted in; configure once with IDs discovered from the existing provider and Project tools. Never infer an option ID from its display label.

When explicitly asked to transmit mapped targets, use `work.py sync-mapped <WORK-ID> [--pull-number N]`. This may send the bound issue state and the one configured Project field; it reports each target separately. The configured provider's after-merge timing applies to both mapped targets, even through a lower-level sync command. Existing manually staged Project effects retain their explicit sync-now behavior. Disabling the map pauses mapped sends and does not undo remote changes. Reconcile an uncertain send before trying the latest desired state. A human may change a Project field between its read and update; report that race instead of claiming remote compare-and-set.

For a create, bind the caller's description and stable request ID as separate variables after resolving the installed helper and interpreter from the card. Pass each value as a literal argument from the intended worktree. A distinct intent may be bound separately when its wording differs from the title.

PowerShell create invocation

$caCreateArgs = @('create', '--title', $caDescription, '--intent', $caDescription, '--type', 'unknown', '--operation-id', $caRequestId)
& $caPython -B $caHelper @caCreateArgs
if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }

POSIX create invocation

"$ca_python" -B "$ca_helper" create --title "$ca_description" --intent "$ca_description" --type unknown --operation-id "$ca_request_id"

The facade reads the selected revision for an ordinary update and applies the owner's exact change check. When a caller already holds the preimage, pass `--expected-revision` and `--expected-model-sha256` together for native work, or `--expected-model-sha256` with the returned board hash for legacy work. Keep the same request ID and preimage after an uncertain result. Native work returns its journaled result on an exact retry. A legacy update refuses a stale preimage, including one already applied; inspect the selected row before acting again. Do not overwrite a changed item by minting a fresh request ID.

For a historical board row that cannot be selected through a stable `WORK-ID`, including an originless row with an existing dotted ID, `hooks/taskwrite.py` remains an explicit compatibility or repair path. Inspect the exact row and use its dotted ID, or the unique title for an ID-less row, with the documented selector and board lock; do not teach best-effort title matching as the normal /task route. Direct board edits remain invalid.

Related owners

• Harvest promotes selected follow-ups through the current work owner.
• `$ca-standup` owns archival and preserves undated historical rows. Native

items use `work.py`; legacy rows stay with `taskwrite.py` for that selected archive.

• Work lifecycle changes ride their associated work commit through

`commit-gate` under ADR-0008. A separate `chore(board)` PR for an ordinary transition is the anti-pattern; it can claim progress before the work lands.

Hard gate

• Never hand-