code-craft

代码之道

让类型证明它们能证明的内容，只测试它们无法证明的内容。每个不变量都只有一个负责人：能够实际证明它的证明阶梯中最高的一阶。顺序为：类型和代码检查工具、效应、证明、数据库约束、单元测试、集成测试、端到端测试。

遵循仓库当前的指示和既定惯例。当所请求的更改需要设计决策时，采用以下默认做法；这些做法不代表可以进行无关的重构或引入新工具。

阅读与当前决策相关的参考资料：

决策	参考资料
决定由哪一阶负责不变量	证明阶梯
表示状态、工作流和领域身份	非法状态
将外部输入解码为有用的类型	解析，而非验证
为依赖项、失败和资源生命周期提供类型	效应
为可恢复的错误和必需的关卡建模	将错误视为值
守护敏感的前置条件	证明参数
选择抽象或调查性能	简洁性
维护模块边界及其文档	架构文档

只有在语言惯用法、并发或工具细节相关时，才阅读语言参考：TypeScript、Rust、Go 或 Python。

对于新编写的 TypeScript 代码和完整的项目模板，Jess 的技术栈是 Effect、Effect Schema 或 Zod、xstate 和 gdp-ts。对于新的 Rust 服务端，技术栈是 tokio、axum、snafu、aerosol 和 sqlx。在现有仓库中，使用对应的现有技术；添加其中任何一项都属于架构变更，应先征求意见。

对于架构、约束、查询和任务，请使用 database-craft；对于测试阶梯，请使用 testing-craft。如果请求涉及仓库搭建，请使用 project-bootstrap。遵循项目要求的验证流程；代码审查并不自动要求运行完整测试套件。

改编自 leonardomso/rust-skills（MIT）、Matklad 的 Rust100k 系列、Alexis King 关于解析和类型安全的文章，以及 Matt Noonan 的《Ghosts of Departed Proofs》。