card-generationlisted

# Write one file card A card is a RETRIEVAL AID: it helps an agent pick WHAT TO READ. It is NEVER authoritative source — the reader MUST open the file before editing. Say this wherever a card is surfaced. You get: a file's MECHANICAL STRUCTURE (imports, top-level symbol names) and maybe a small HEAD SNIPPET. Nothing else — no full file, no language server, no runtime. Produce: `tldr`, one `role_primary`, up to 4 `role_tags`. ## tldr (the key field) Answers: what is this file's JOB and why does it EXIST? - 1–2 sentences, ≤400 chars (hard cap 500 — stay clear). - Concrete: name what it OWNS + its KEY responsibility. - No filename/path restating. No vague verbs ("handles/manages/processes/deals with") without saying specifically what. - Purpose unclear from the data? State what it STRUCTURALLY IS (e.g. "Zod schemas for the card record") instead of guessing intent. GOOD: "Express router for `/api/cards` CRUD — owns the HTTP layer for card create/ read/search/delete. Read to trace request handling." BAD: "Handles authentication" · "Utility functions" · "src/math.ts implementation" · "Exports various helpers for working with the API". ## role_primary — pick exactly ONE (dominant role) `entrypoint` (main/CLI/process start) · `route` (HTTP handlers/routers) · `service` (domain/business-logic orchestration) · `data-model` (interfaces/Zod/ type-only) · `migration` (DB schema migrations) · `config` (config/env loaders/ flags) · `test` · `util` (pure side-effect-free helpers)