project-bootstrap

项目引导

将 Jess 的默认配置应用于用户要求的仓库设置。用户要求创建应用或小型原型，并不意味着要使用完整模板。除非请求中包含迁移，否则应保留已有工具链。

选择范围

根据任务推断语言、产物类型和所需设置。区分最小可运行项目与面向分发的仓库。实施前说明重要的基础设施选择。只有在缺失信息会影响用户负责的决策时才提问。

• 最小设置：源代码布局、依赖清单，以及运行和验证项目所需的命令。
• 仓库工具：格式化工具、代码检查工具、类型／构建检查，以及 CI。
• 分发：与产品相适应的发布自动化和面向贡献者的文件。
• 完整 Jess 模板：仓库工具、适用的分发文件，以及 Agent 规则和审查基础设施。仅在用户要求完整模板或这些门禁时使用。

工具默认配置

语言	格式化工具	代码检查工具	类型／构建检查
Rust	rustfmt	clippy	cargo build / cargo test
Go	gofmt / goimports	staticcheck + go vet	go build / go test
TypeScript	oxfmt	oxlint	tsc --noEmit
Python	ruff format	ruff check	mypy 或 pyright

每种语言只使用一种格式化工具和一份代码检查配置。在支持的情况下，启用严格类型检查。保留边界解析的灵活性：不要全局禁止未知输入类型、运行时收窄类型或合理的 React 副作用。必要时使用 code-craft 获取特定语言的指导。

对于新的 TypeScript 应用或完整模板，应根据项目将采用的 code-craft 证明阶梯配置技术栈：在类型检查中使用带语言服务诊断的 Effect，在边界处使用 Effect Schema 或 Zod，为命名工作流使用 xstate，使用带有其代码检查预设的 gdp-ts，使用 @effect/vitest 配合 Vitest，使用 Vercel Emulate 进行服务提供商测试，并遵循 database-craft 使用 Postgres。配置代码检查工具，使其对 any、未经检查的 as、非空断言 !、未处理的 Promise，以及没有理由的抑制操作报错。原型只配置实际用到的内容。

对于新的 Rust 服务，按照 code-craft 的 Rust 参考配置服务端技术栈：tokio、axum、snafu、aerosol 和 sqlx；在 [workspace.lints] 中设置包含 disallowed_methods 和 disallowed_types 的拒绝列表；使用 nextest，并设置一个 tests/it 测试 crate，同时在库和二进制目标上设置 test = false；并在 CI 中运行 cargo sqlx prepare --check。

在一份配方中定义检查套件，供 CI 和本地开发共用。如果用户要求配置钩子，则使用同一配方或范围明确的快速子集。不要仅仅为了重复 CI，就在每次提交时运行耗时的完整套件检查。

Agent 基础设施

如果用户要求实施 Agent 规则或 AI 审查，应将每条规则放在能够忠实表达它的最强约束层。优先使用编译器和代码检查，而不是新增 Agent 规则系统。不要在多个层重复设置同一门禁。

对于需要强制执行的 Agent 专属规则，尽可能使用结构化匹配，并提供独立于 Agent 修改的 CI 检查。对于 AI 审查门禁，应确保审查者定义可供审查，并通过仓库的所有权规则加以保护。评估失败时，必需的门禁不得静默通过。

分发与项目文件

对于要以二进制形式分发的 CLI，优先使用由标签触发的发布，并为支持的平台提供带校验和的压缩包。根据标签确定版本。仅在用户要求或分发计划需要时才包含安装程序；安装前必须验证校验和。

根据目标用户确定支持的平台和软件包注册表。 对于尚未发布的原型，不要构建平台矩阵。

对于计划公开分发的仓库，请包含许可证、贡献指南以及用于私下报告安全问题的渠道。如果用户要求完整模板或这些内容有特定用途，再添加行为准则、问题模板、依赖项更新和发布工作流。

Jess 对新许可证的选择是 AGPL-3.0-or-later 或 Apache-2.0。除非用户已做出选择，否则在为新项目授权时应询问使用哪种许可证。使用 AGPL 时，Jess 默认采用 CC-BY-SA-4.0 作为文档许可证，并将其记录在 NOTICE 中。保留现有许可证和第三方声明。

验证并报告

运行生成的设置并执行必要检查。确认 CI 会调用维护中的检查配方。报告已配置的内容，以及任何未经验证的平台或外部服务。未经授权，不得发布、创建远程仓库或配置付费服务。