Ca Feature

/ca-feature — spec-driven feature

The single permitted entry to implementation work. No feature code is written before a spec is approved and tdd Phase 1 clears. A one-line idea is not a spec — brainstorming makes it one.

Structured-artifact boundary

For new full-lane work or an existing .html spec/plan match, load <plugin-root>/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 validated identity, authority, binding and task-state operations replace this command's .md, approval-label and 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 .codearbiter/code-map.md is present, 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 its returned input to the fresh actor before mutation, execution of discovered commands, or a substantive review verdict. A coordinator's read alone is not delivery.

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 identity, index, and symbol-scoped read operations; do not scrape rendered labels or embedded JSON. For a Markdown pair, use the existing Markdown status ledger. Resume either exact format without creating or consulting a shadow artifact; the workflow must not create, rename, or convert its counterpart. On a match, confirm the resume with the user in one line ("resume <slug> at <point>?") and re-enter at the furthest checkpoint reached:

1. Plan exists with non-ACCEPTED tasks → executing-plans (its Phase 1 batches only the remaining tasks).
2. Plan exists, every task ACCEPTED → commit-gate (the work is done and verified; it was the commit that never happened).
3. Spec approved, no plan → writing-plans (<plugin-root>/routines/writing-plans/SKILL.md).
4. Spec exists but never approved → brainstorming (<plugin-root>/routines/brainstorming/SKILL.md), at its approval gate — not from scratch.

Re-running brainstorming against an already-approved spec is the failure mode this section exists to prevent: it discards approved decisions and re-asks answered questions. Only an explicit user request ("start over") restarts an existing slug — and that is logged to triage.log like any classification.

Step 0 — change-class triage (logged)

Before routing, classify the request. The small lane applies only when ALL of these hold — judged against $ARGUMENTS and a quick look at the code, never assumed:

• the change touches ≤ 2 implementation files (plus their tests);
• no §4 reference-map scope-touch: auth/crypto/secrets, dependencies, migrations/schema, telemetry, public API surface, domain vocabulary;
• no new dependency, endpoint, command, or configuration surface;
• the behavior change is expressible as 1–3 concrete, individually testable acceptance criteria.

Small lane: state the mini-spec inline (the 1–3 criteria) and STOP for the user's one-reply confirmation. On confirmation, append one line to <project-root>/.codearbiter/triage.log (append-only, >>):

[ISO-8601 timestamp] | BY: <git user.email> | LANE: small | SCOPE: <one-line> | BASIS: <criteria met>

Then route directly to tdd (<plugin-root>/routines/tdd/SKILL.md) — the confirmed criteria are its Phase 1 obligations; Phases 2–6 run unchanged — and exit through the full commit-gate and finishing-a-development-branch exactly as the full lane does. The lane trims ceremony, never gates.

Any criterion violated, or uncertain → full lane (below). Uncertainty is full-lane; the triage never guesses.