/ca-feature

name: ca-feature
description: "Build an authorized feature from a maintained specification, testable criteria and useful plan, without duplicating user approval."
argument-hint: "<what you want to build>"

$ca-feature — spec-driven feature

The feature entry maintains a useful spec and plan before full-lane implementation. The user request supplies the intended authorization; the artifact engine does not require another permission code. Check criteria and applicable tests before claiming completion.

Durable work outcome

Use the installed `hooks/work.py` facade through [includes/helper-invocation.md](../../includes/helper-invocation.md) from the intended project worktree. An actionable feature has one `WORK-ID` through authoring, implementation and delivery. If the request names a work ID, read `work.py context <WORK-ID>` first and retain its exact bindings. Never equate two outcomes by title. If selection is ambiguous, list the bounded candidates and ask for an exact ID before changing either item.

For a full lane, resolve or create the canonical spec first. If an explicit `WORK-ID` was already selected, retain it and attach the actual spec ID there with `work.py attach <WORK-ID> --spec-id <SPEC-ID> --operation-id <stable-id>`. Otherwise search its stable origin with `work.py origins --origin feature-spec#<SPEC-ID>`. Reuse the returned work ID, or create once with `work.py create --title <outcome> --intent <outcome> --type feature --spec-id <SPEC-ID> --origin feature-spec#<SPEC-ID>` and a stable operation ID. A lost response is retried with the same operation ID or resolved by that exact origin; it is not a reason to create another item. Once the real plan exists, attach its `PLAN-ID` with `work.py attach <WORK-ID> --plan-id <PLAN-ID> --operation-id <stable-id>`. Recheck the selected work context after an uncertain attachment. A mismatched existing binding is a scoped conflict; do not hide it by opening another work item.

For a small lane, keep the mini-spec inline. Create a work item when the authorized change becomes actionable, without creating an HTML spec or plan for bookkeeping. Use a durable external source key as `--origin` when one exists; otherwise pass a stable `--operation-id` and reuse it for an uncertain retry. Retain and report the returned work ID for exact resume. On a later session, select that ID via `work.py list`/`get`, never a title-only match. For native-owned work, run `work.py view <WORK-ID> --save` after changes and report its returned local page path. The page is a replaceable snapshot; the work record remains canonical. `work.py view <WORK-ID>` still prints HTML when a native caller needs it. Legacy board work has no native derived view; use its selected board owner. Local `complete` records implementation progress, not passing checks, PR merge, release or provider synchronization. Preserve the existing test, host, commit and PR boundaries. In a native project with an explicit transition map, the ordinary lifecycle call also saves the configured issue and Project intent, or a waiting reason, in that same local transaction. Keep remote synchronization explicit through `work.py sync-mapped <WORK-ID>` after the selected timing condition. Do not make each model call stage both targets separately.

Structured-artifact boundary

For new full-lane work or an existing `.html` spec/plan match, load [includes/artifacts.md](../../includes/artifacts.md) before resume classification or artifact I/O. After lane classification, call `_select_authoring_route` with the trusted project root, slug, `workflow: feature`, and the selected lane. Use only its returned mode, format, and paths. For a selected HTML route it checks the installed capability before writing; a missing or invalid helper is a STOP and the workflow must not fall back to Markdown. Its typed identity, binding, and task-progress operations replace rendered-label and Markdown status-cell assumptions for that pipeline. New full-lane specs use the installed structured-artifact engine and default to canonical `.html`. An existing `.md` pair remains on the legacy path. Discovery requires a complete same-extension spec/plan pair: select that exact pair as authoritative. A mixed-extension or duplicate match is a STOP. A lone spec resumes in its exact format, and the next plan must use the same extension. The workflow must not create, rename, or convert its counterpart to repair ambiguity. HTML `--farm` dispatch stays blocked. Small-lane behavior is unchanged: its confirmed mini-spec remains inline and does not create a spec artifact.

**Orientation:** if the code map is present (`.codearbiter/code-map.md`, or its HTML knowledge document), read it first — a coarse concern→path→role map that orients task authoring. Absent is fine; it is read-on-demand, populated by context-creation or commit-gate heal. At each actual author or independent reviewer dispatch, use the private `_artifactpromptlib.compose_feature_actor_input` contract described in `tdd` and `subagent-driven-development`; send the bounded relevant input to that actor. Host permissions still apply to commands; delivery records do not independently grant or deny execution.

Resume — an interrupted pipeline is re-entered, never restarted

Before triage, scan `<project-root>/.codearbiter/specs/` and `plans/` for artifacts whose slug matches `$ARGUMENTS` (invoked bare, list every resumable pipeline and ask which). Call the private bridge resolver `_resolve_workflow_pair` with the trusted project root and selected slug; its returned paths and format own this resume. Select a complete same-extension pair as authoritative. A lone spec resumes in its exact format, and the next plan must use the same extension. A mixed-extension or duplicate match is a STOP. A crash, compaction, or closed session mid-pipeline loses nothing — the spec, the plan, and each task's state are on disk. For an HTML pair, obtain state only through the installed engine `iden