修改故意留有漏洞的安全培训应用，同时不破坏其挑战

## 区分有意设计的挑战和意外漏洞 对待有意设置漏洞的培训应用程序时，应采用不同于普通生产应用程序的方式。有些不安全行为是刻意设计的教学内容，而另一些弱点则是非预期缺陷。 - 更改受影响的行为之前，先确定它是预设挑战、支撑基础设施，还是意外漏洞。 - 不得仅根据自动化建议删除、削弱或添加挑战行为。 - 新漏洞和新挑战必须获得维护者批准，并有清晰的文档记录。 - 确认所提议的挑战具有独特性、可解决、可以正常运作，并适合学习目标。 - 保留用于解释非显而易见意图的挑战提示、元数据、解决路径和安全相关注释。 - 批判性地审查生成的代码。贡献者和审查者仍须对正确性、安全性和教育价值负责。 意图不明确时，应先追踪执行路径、测试、挑战元数据和镜像修复产物，再决定需要更改什么。 ## 规划只解决一个问题的改动 首先找到相关组件，追踪其数据流，并查找已确立的实现与测试模式。 1. 定义此项变更要解决的唯一问题。 2. 确定受该问题影响的服务器、客户端、API、数据、模板、配置和挑战产物。 3. 搜索相似代码，并遵循代码库当前的模式。 4. 实现之前审查安全影响。 5. 提出能够区分预期行为与回归问题的测试。 6. 不要在同一项贡献中包含无关的清理工作和琐碎变更。 创建挑战、更改架构或改变依赖模型之前，应咨询维护者。任何软件包更新都要根据每一份相关的依赖清单和运行时版本范围进行验证。在没有已证实的需求和兼容性证据时，不得添加推测性的配置选项或依赖项。 以代码库指定的集成分支为基础，使用目标明确的功能分支开展工作。引用相关 issue，并将贡献限定为一个连贯的目的。 ## 清除 AI 生成的多余内容并通过代码检查 审查前清理自动生成的输出。 删除只是复述明显代码的冗长注释、通用占位符、为简单函数编写的过多文档字符串、重复说明、调试日志及其他生成残留。保留用于解释复杂逻辑、挑战意图、安全约束或必要变通方案的注释。 每次代码变更都要运行代码库的 linter，除非变更仅限于代码库明确豁免的文档。生成的代码必须遵循与手写代码相同的样式规则。 - 修复 lint 失败，不要假定建议一定正确。 - 不得仅仅因为某段不必要的代码是由助手生成的就将其保留。 - 检查 diff 中是否存在大范围的格式变动和无关的文件更改。 - 使用清晰的名称和简洁的注释，帮助未来的维护者理解意图。 - 确保文档和提交文本描述的是实际变更，而不是助手的工作过程。 ## 按改动范围运行所有必需的测试 测试要求取决于变更涉及的范围，但助手的信心绝不能替代实际执行。 - 为更改后的逻辑添加或更新单元测试。 - 当请求处理、持久化、授权或响应行为发生变化时，运行 API 集成测试。 - 为客户端组件和服务运行前端单元测试。 - 为新增或修改的挑战以及跨层行为运行端到端测试。 - 提交前运行代码库的完整测试套件，除非代码库明确豁免了发生变更的文档。 - 手动验证用户可见的流程或挑战解决流程。 - 只要现有挑战相关源代码发生变化，就运行挑战重构安全网。 迭代期间使用规模最小且聚焦的测试套件，审查前再运行完整的必需矩阵。记录确切的命令和结果。不得仅凭静态分析宣称成功，也不得因为生成的代码看似合理就跳过耗时的测试套件。 ## 让挑战代码与镜像的修复文件保持一致 挑战相关源代码可能会镜像到代码片段、预期修复、元数据或缓存的安全网产物中。如果这些表示形式不一致，重构就没有完成。 1. 更改挑战相关代码后，运行代码库的挑战重构安全网。 2. 如果安全网失败，应检查报告的每一项差异，而不是立即刷新缓存。 3. 判断差异是非预期回归，还是有意变更的一部分。 4. 对于有意进行的重构，将等效变更应用于相应的修复产物和代码片段。 5. 只有在源代码、挑战行为和镜像产物保持一致后，才能更新已批准差异的缓存。 6. 重新运行安全网和相关挑战流程。 绝不能使用缓存更新来掩盖未解释的差异。新增或更改的挑战行为还必须提供端到端证据，证明该挑战仍然可到达、可解决且能被正确检测。 ## 通过指定的翻译平台提交翻译并完成提交前检查 不要直接编辑生成的或由外部管理的本地化文件。通过代码库批准的本地化平台提交翻译变更，使源文本、审查历史和生成文件保持同步。 提交前： - 确认样式检查通过，生成噪声已经清除。 - 确认此项变更所需的单元、集成、前端、端到端和安全网检查全部通过。 - 手动验证行为，并检查最终 diff 中是否有非预期变更。 - 确认依赖项和运行时的兼容性。 - 确保提交符合代码库的签署确认政策。 - 以必需的集成分支为贡献基础，并引用相关 issue。 - 记录复杂逻辑、安全意图、已运行的测试和任何已批准的例外。 - 确认所有持续集成检查均已通过。 如果无法运行任何必需的检查，应明确说明该限制。不得把部分验证描述为完整的安全审查或挑战完整性审查。