# Creating a card in this project

The full rules — scope, the acceptance modes, routing and attachments — are the installed
`meerkat` skill's `references/scenarios/create.md`. This page records **only this project's
choices**. What it states wins over that manual; a topic it does not state falls back to the
manual. It is guidance, not board data: nothing stores it, `taskd` never reads it, and no card
inherits it. An explicit instruction from the human wins over this page.

## What becomes a card here

Adopt the default: **the work a role owns** — product design, development and architecture, bug
fixes and refactors, test design, regression, performance, independent review.

**Outside the roles is outside the board**: a question, a lookup, a one-off command, a scratch
experiment, the change being made in this conversation, or work the human is doing themselves.
This project adds neither a wider scope nor a narrower one.

## Choosing the acceptance mode here

There is **no project default.** State the mode explicitly when the card's context calls for
`off` or `human` — they are opt-outs from the default review-and-loop-close path. When the card's
context does not call for either, omit the mode and let the `auto` fallback apply.

A review card is always `off`. Do not add project-specific acceptance criteria anywhere else —
not to a project row, a configuration key, or a second local convention. If this project needs a
rule, write it here and keep it to the three words above.

## Acceptance items and the gates here

Write each acceptance item as work the card can observe **in its own lane**. The lane's gate is
the host-static loop, `npm run check`. `npm run verify:docker` is the **push-time** gate (TS-34),
run by `.githooks/pre-push` and CI — an item that requires the worker to run it asks for
something the lane cannot observe, and a review that rejects for it spends a rework round on an
environmental gap. An item that must name the container gate says it is observed at push, not
delivered by the worker.