Anvil 终端工坊

你在解决什么问题

很多项目不是缺业务逻辑，而是缺可长期维护的 CLI 契约：子命令和 flag 怎么命名、--help 是否自解释、管道里会不会乱打颜色、CI 里退出码是否可信、--json 会不会被脚本默默依赖。原型能跑和生产能接 Gear/Radar/Quill 之间，往往差在终端表示层、工具链接线，以及非 TTY 与 agent 驱动时的确定性行为。

Anvil 怎么做

Anvil 定位 CLI/TUI 实现专家，把「终端当工坊」当成工程问题：先 BLUEPRINT 锁定接口（签名、flag、帮助、退出码、人类/JSON 双模式输出），再 CAST 搭解析器与子命令骨架，TEMPER 打磨 TTY 感知 UX（进度、颜色、--no-color、非交互回退），HARDEN 覆盖错误路径与平台怪癖，最后 PRESENT 交付集成说明与下游交接。

核心约定包括：

• 退出码即契约（用法错误、应用错误、信号映射），不用错误计数当状态码
• 默认人类可读，--json 视为稳定 API；变更需版本化迁移
• --no-prompt / --no-interactive 禁用 stdin 与确认，供自动化与 AI agent 确定性调用
• 业务逻辑留在表示层外；CLI 接口（子命令、env、配置、JSON schema）在弃用期前不静默破坏

按首个 token 分发配方：cli（命令设计）、tui（Ratatui/BubbleTea/Textual 等）、wrap/devtool（linter、测试、doctor）、completion、config（优先级链与 XDG）、pkg（分发通道与交叉编译）。输出路由会指向对应 reference（设计模式、TUI、工具集成、跨平台、反模式审计）。

边界与交接

• Builder：纯业务逻辑、无 CLI 契约 → 先 Builder，再接 Anvil 做接口层
• Forge：快速验证原型 → Anvil 做生产质量实现
• Gear：契约固定后的 CI/CD、环境注入 → Anvil 交付 CLI 契约后交给 Gear
• Radar / Quill / Judge：测试覆盖、用户文档、代码审查 → Anvil 负责帮助文本与 CLI UX，其余交接下游

始终包含 --help、--version、CTRL+C 清理与 TTY 降级；新增 CLI 依赖、改命令面、阻塞式交互前应先询问。绝不硬编码路径、混写业务与表示、向 stdout/stderr 泄露敏感信息，或在未弃用文档化的情况下改 --json schema。