validation-gates.md - 缺少原始上下文会让你的代码变得毫无意义。

这个问题实际上是一个观察，社区可以验证我要提出的观点。在 validate-gates.md 中，有如下说明： 3. 迭代修复过程 当测试失败时： 仔细分析失败原因 确定根本原因 实施修复 重新运行测试以验证修复 继续迭代直到所有测试通过 记录任何不明显的修复 我在 generate-prp.md 中看到，你要求向子代理传递上下文，但我曾经看到过这种情况可能不会发生。如果此验证门户代理缺少来自 Claude.md 的上下文，例如 PLANNING 和 TASK，那么在迭代阶段，它将在尝试通过测试时完全失败。我曾经多次看到过这种情况，LLM 会使用任何代码来通过测试，明显违反了你的规则和架构。我是否是唯一一个看到这一点的人？ 此外，对整个概念应用更多的"工程"。值得赞扬的是，你付出了很大的努力，但你的推理中存在明显的漏洞。 从头开始。md 非常混乱，因为大多数功能都将在产品投入使用后出现。我认为它应该称为"功能要求.md"（或类似的文件名，表明这是一个"不断变化"的文档），并填充开发人员解释功能意图的对话的结论。 然后，使用 Claude、PLANNING 等中已提供的信息，LLM 应制定 10 个澄清问题，然后根据这些答案更新它们。 所有这些对话应从"功能要求.md"文件中提取出来，然后你可以开始循环。你还可以指定命令来根据功能要求创建文件夹，从而可以隔离这些任务并保留它们以供长期使用。 关于验证门户，我认为你应该将其保留为"修订者"，但输出应非常一致，以便指明需要修复的代码，而不是试图修复它。然后，你可以有一个"测试子代理"，它了解了架构、样式、模式等方面的一切，并让它进行修复。但是，它已经听起来像是应该由主要对话负责的，而不是子代理。 最后，但并非最不重要，PRP 听起来很酷，但它完全是虚构的。它只不过是一个结构良好、内容丰富的 PRD，这是软件开发中的正确术语。它将帮助你让人们采用这个仓库。 再次赞扬你，并继续改进它。这是一个很好的第一步。