用途：ticket-up 是唯一的 Ticket 编写边界，把输入塑造成符合项目约定的 Ticket，并渲染到项目配置的存储渠道。编写前需阅读 references/TICKET_CONVENTION.md，其中定义 Ticket 的单元、种类、结构、生命周期与优先级。
输入与拆分：可接受已完成的 Manifest、直接工作请求、需单独管理的问题、运行源 Ticket 时发现的后续项。一个 Ticket 代表一个可独立调度的生命周期；共享同一结果、会被一起分配和关闭的工作应合并，仅在所有权、优先级、阻塞或关闭确有独立价值时拆分。拆分应产生可端到端运行或判断的切片，按实现层（如 schema、接口、界面）切分不被接受。Manifest 输入默认生成一个 Ticket，仅在明确要求委派或并行时按 Deliverable 拆分。问题仅在需要独立生命周期时生成 Question Ticket。后续发现先搜索开放集合并入已有 Ticket，再分组编写，并链接回源。
翻译原则：Ticket 是给可能没有 manifest-dev 的陌生人的契约，应重写而非摘录。Problem 与 Goal 转为 Why，Appetite 与 Out of bounds 转为 Scope，全局不变量转为 Rules，风险与假设转为 Watch out for，Deliverable 与 gate 汇总为散文式 Definition of done。
Auto 授权：普通新 Ticket 仅在无需人类知识、品味或权威且作者选择信任无人执行时授予 Auto。后续项需在本编写边界获得新的人类授权，或源 Ticket 已带 Auto 且后续项独立通过同一标准；不得直接复制源 Auto。
类型与依赖：每个 Ticket 从存储词汇中选一个类型，类型不授予执行权限。仅当一个 Ticket 的结果是完成或判断另一个所必需时才编码 Depends on。
渠道：先读 tickets/store-config.md，项目上下文文件可指定其他固定位置，否则询问一次并推荐共享跟踪器（有可达 GitHub 远程时推荐 GitHub Issues）。文件渠道写入 tickets/<effort-slug>/NN-<ticket-slug>.md，关闭后移入 done/。GitHub Issues 需读 references/GITHUB_STORE.md。其他跟踪器需写 tickets/<venue>-store.md 并在 store-config.md 中引用。首次使用某渠道前需展示计划并确认。
报告与限制：以短表呈现 ID、标题、种类、类型、Auto、依赖及落点。注意 gate 中的评估机制需翻译为可观察的完成描述；小问题列表不自动等于 Question Ticket 列表；当前完成定义内的缺陷属于未完成的源工作。