Genesis 项目工作
Genesis 是一个解释与验证的辅助工具。它不会取代代码库、测试、Git 审查或编码代理。
确立新产品方向
对于蓝图尚未确立产品方向的新项目，在用户明确说明以下内容之前，不要进行技术研究或创建源代码：所构建的内容、谁或什么将使用或调用它，以及第一个可观察到的有用结果。仅询问未解决的高影响力问题。一个回复仅确认其明确回答的内容；技术栈确认并非产品意图。
一旦产品方向明确，选择一条最小的实现路径，通过选定的技术指南或权威技术文档（当目录中没有匹配项时），并且只读取该路径所需的内容。不要调查替代方案、克隆整个技术仓库、检查不相关的包内部结构，或将研究委托出去，除非一个具体的失败需要一次精确的调查。
运行 Genesis 命令
在运行第一个 Genesis 操作之前，先解析调用方式。不要使用 Genesis 操作或 genesis --version 作为可用性探测。
- 读取仓库根目录下的
package.json。仅当清单的name为genesis-compiler，或其dependencies、devDependencies或optionalDependencies包含确切的genesis-compiler键时，才将 Genesis 视为项目固定（project-pinned）。 - 对于项目固定的仓库，使用
npm exec --no -- genesis <参数>调用每个 Genesis CLI 操作。这样运行不会获取其他包。如果声明的包未安装，报告该项目依赖未准备好；不要回退到另一个 Genesis 版本。 - 否则，不要尝试
npm exec。运行command -v genesis（或当前 shell 等效的PATH查找）。当它解析到一个可执行文件时，直接调用genesis <参数>。 - 当两个来源都不可用时，停止并报告 Genesis 不可用。永远不要仅仅为了满足工作流指令而安装或更新 Genesis。
成功解析调用是常规操作。不要说明 Genesis 是项目固定的还是在 PATH 上，也永远不要将直接使用 PATH 描述为回退。仅在解析失败或用户明确询问时才提及调用方式是如何选择的。
遵循配置的协作方法进行面向用户的更新，包括其技术深度和回复长度。报告具体的进展、发现或障碍；不要宣布你正在遵循指南。
解决明确的技术选择
在外部技术研究或实现之前，当用户明确指定了一项技术、框架、语言或数据库，而该技术尚未被选定时：
- 作为第一个技术操作，运行 Genesis
stack list操作。 - 如果某个目录组件与选择完全匹配，询问：“<技术> 在 Genesis 中可用。你希望我将它添加到该项目中并根据其官方指南准备应用吗？” 在没有得到确认之前，不要运行
stack add <部分...>。 - 如果确认，添加该组件，让 Genesis 应用其声明的依赖闭包，并同步由该组件声明的任何权威代理技能。遵循在同一任务中由
stack add返回的准备提示：使每个具体化的项目契约成为现实，或用有证据的现实替换完整部分。然后运行context .，或在源代码存在后运行相关源代码路径，加载适用的已安装技能（如果存在），并遵循该技术自有的指南来准备实际的项目依赖。永远不要从组件 ID 推断安装命令。 - 如果拒绝，继续而不添加该组件或再次询问。如果没有目录组件匹配，不要发明一个；正常继续，使用该技术拥有的权威文档。
建立上下文
- 读取
genesis/blueprint.md以了解非技术性的产品意图。 - 读取
genesis/engineering.md以了解选定的工程概况和任何项目特定要求。 - 读取
genesis/stack.md以了解选定的技术组成、资源和验证命令。 - 定位请求所涉及的源代码。
- 在添加辅助或公共操作之前，运行 Genesis
index <名称或路径>操作。当现有函数已经拥有该行为时，重用现有函数。 - 运行 Genesis
context <路径...>操作以获取相关的程序解释和选定的技术栈上下文。 - 从
.agents/skills/或代理自身的已安装技能目录中加载适用的技术技能。
对于现有应用的首次技术栈选择，在接受具体化的组件提议之前，检查其实际的设置、构建和输出命令。一个选定的组件描述的是其当前的基础；它不会静默地移植旧源代码。当现有命令不同时，保持实现不变，并替换完整的项目拥有的消费者操作（例如，主机的 ## Workspace setup 或 ## Outputs）。Genesis 将这些部分视为不透明文本；只有命名的消费者拥有其含义和执行权。在提议的配方与源代码匹配之前，不要声称其可用。
程序是简洁、易错的解释。其源代码和可选的实现映射有助于导航，但绝不能替代阅读代码、测试和运行时行为。
.genesis/machine-city.json 是一个派生的详细文件/函数映射。.genesis/program-city.json 是一个派生的更简单的子系统/操作映射。两者都不是权威或证据；它们都被 git 忽略，并且可以通过 Genesis index 操作重新生成。
执行普通的本地工作
- 应用由 Genesis 提供的有效工程方法。每个变更必须易于推理，并且是满足已知需求的最小目标实现。不要过度设计或使其复杂化，不要添加推测性的抽象、层、依赖、基础设施、兼容性路径、分布式模式、密码学或其他高级机制。
- 当一个具体需求使物质复杂性成为必要时，在编写之前停下来。解释为什么直接设计不足以及提议的最小新增复杂性是什么，然后要求用户批准或澄清权衡。永远不要静默地覆盖工程方法。
- 直接在当前的 Git 树中工作，并在普通的差异中留下有用的编辑内容。
- 当实现有意改变可观察的产品行为时，在同一轮次中保持蓝图和受影响的程序模块一致。私有重构可能只需要修正的源代码或信息性的实现映射，并且可能不需要编辑解释性内容。当实现有意改变相应的命令或能力时，保持精确的消费者拥有的操作声明（例如主机的
## Outputs）一致。在那里只记录能力元数据和环境变量名称，绝不要记录值或机密；不要将该部分推断或执行为 Genesis 行为。将.genesis/视为可替换的派生导航数据，而非创作的产品意图。 - 遵循既定的项目和技术的接缝，而不是创建并行的框架、持久化层、传输层、验证器或 UI 系统。
- 永远不要虚构不可用的外部资源值，或将字面环境变量名作为数据传递。报告缺失的资源并保留有用的工作。
- 保持实现直接且内聚。在报告完成之前，应用任何提供的技术栈变更后指南；它是本次实现轮次的一部分，而不是另一个代理轮次的请求。在有帮助时运行有针对性的检查。
验证与报告
在实施过程中，选择与变更相关的检查。在所选技术的工作区基础存在之后，根据项目的验证策略或用户请求，通过 Genesis verify 运行技术栈声明的最终检查。完成一个项目或恢复会话本身并不需要广泛的验证运行。将完整输出保留在本地工件中，保留退出状态，并在展开日志之前阅读摘要和相关失败摘录。不要为了节省时间或令牌而削弱断言或省略所需的覆盖范围。一个未配置的结果意味着声明的工作区或检查尚不存在；它不是失败检查。在报告完成之前，将请求的可观察行为、所需的输入和资源、声明的项目操作以及有针对性的证据与实际存在的进行比较。报告更改的文件、实际运行的检查、任何未证明的内容以及仍需注意的内容。永远不要声称未运行的检查已通过，或通过的检查证明了整个产品。
子系统维护
当一个更改添加、移除或改变了子系统的职责、程序成员资格或数据所有权/使用时，在同一个实现轮次中维护 genesis/subsystems.md。在更改相关代码之前读取该映射。重用现有的子系统，除非有证据表明存在不同的职责。每个子系统需要一个源目录，并且每个程序模块只声明一次；程序文件夹名称不决定成员资格。保持表引用基于模式/迁移；Genesis 不会检查数据库。当这些关联保持不变时，私有辅助更改不需要编辑映射。
如果 genesis/subsystems.md 缺失，或者在现有的已解释应用中为空，请在实现之前根据实际源代码、模式和现有程序创建它。这是普通的解释性采纳，不是阻碍，也不是再次请求许可的理由。保留现有程序和源代码；检查相关职责并完成最小且真实的映射。初始化可以创建空文件，但只有代理能赋予其含义。