按代码仓库自己的命令和测试修改全栈项目

## 先读仓库文档，在分支上工作并提交拉取请求 规划变更前，先阅读代码仓库级指导、子系统文档、软件包清单和附近的实现。找出所有受影响的领域，包括前端、API、SDK、CLI、数据库、容器和文档。 直接开发时，将受保护的默认分支视为只读。创建名称能够说明用途的分支，提交有意义的变更，并发起拉取请求以供审查。不要通过修改已有提交来改写共享历史；如果工作流将合并决定交给审查者，也不要自行合并自己的拉取请求。 使分支聚焦于所要求的行为。将无关的清理工作分开；除非任务需要有意改变既有做法，否则应保留已经确立的模式。 ## 使用仓库自己的命令和固定的运行时版本 运行任何操作前，先查明文档中规定的开发、格式化、代码检查、测试、迁移和启动命令。使用受影响软件包所管理的命令，不要用面向整个根目录的工具代替。 遵守固定的运行时版本和现有环境；较新的运行时主版本并不会自动获得支持。只有缺少依赖项时才安装它们。除非任务或相关验证确实需要，否则不要启动完整的应用程序栈、容器或长期运行的服务器。 按照文档规定的模式，对变更文件运行格式化工具和代码检查工具。先使用受支持的单项测试选择方式，再仅扩展到直接受影响的测试套件。 如果子系统导入的是已安装的SDK软件包而不是其源代码树，请在编辑后重新安装该SDK，并重启使用它的进程。启动组合开发进程前，检查所需端口和前提条件。 ## 让界面、API、服务和迁移各管各的职责 编辑前先梳理职责： - 用户界面负责呈现和客户端状态； - API负责请求验证和传输相关事务； - 服务模块负责业务逻辑； - SDK和CLI软件包负责各自的公开接口契约； - 迁移负责数据库演进。 阅读待变更子系统的文档，并在引入新模式前检查类似的现有文件。如果变更跨越多个层级，应按小步骤推进：定义类型或模式、实现服务逻辑、提供API契约、更新客户端，最后构建界面。 将依赖项安装到使用它的软件包中。添加工作区软件包时，应更新所有在安装依赖项之前复制软件包元数据的生产和本地容器构建清单。 ## 遵守TypeScript、Python和数据库的规则 使用严格的TypeScript类型，避免没有边界的类型，清楚定义组件和API契约，并遵循代码仓库中已经确立的组件与状态管理模式。优先采用函数组件和显式状态操作，而不是在深层级之间逐级传递属性。 对于Python代码，应在每个函数边界提供类型提示，使用验证模型进行序列化，并将业务逻辑放在服务中，而不是传输路由器中。路由器应验证请求、调用服务并整理响应结构。 遵循现有表和迁移规则，包括任何禁止使用外键的规定。确保数据库操作可以移植到所有受支持的引擎。时间戳字段应使用代码仓库提供的UTC辅助工具，不要使用本地时间、已弃用的API或手工编写的转换。 遵循代码仓库对于使用文件系统还是数据库存储数据的决定。不要仅为了方便而将需要同步的集群数据移入数据库。 ## 在该行为所属的层和测试套件中测试 使用各子系统实际配置的测试系统。如果前端没有单元测试框架，应使用指定的端到端测试套件覆盖其行为，而不是引入不受支持的运行器。将后端单元测试和服务测试放入既定目录树，并在更改CLI源代码后运行CLI测试套件。 模拟外部存储、计算资源提供方和文件系统交互，使测试保持快速且结果确定。对于不需要完整API栈的业务规则，应优先直接测试服务。 先运行一项聚焦测试，再运行相关子系统的测试套件。即使已有数据，也要确保重复运行安全；使用稳定的选择器，并为排队工作或状态转换设置符合实际情况的超时时间。 不要仅凭命令名称声称成功。确认预期的测试文件已被发现，并且结果确实检验了发生变更的行为。 ## 在浏览器中检查改动的页面，并测试需要登录的API 使用代码仓库批准的交互式浏览器工具进行视觉检查。自动端到端脚本只用于维护中的测试套件或明确提出的要求。仅启动必要的测试应用程序，访问发生变更及与其直接相关的页面，收集证据，并修正可见的退化问题。 优先使用角色、完全匹配文本和占位符选择器。处理重复的测试数据时，不要假定数据库是空的。终端模拟器呈现的内容可能不存在于DOM中；必要时，应通过其后端API进行验证。 检查需要身份验证的API时，使用文档规定的测试身份和身份验证流程。提供必需的账户或租户范围请求头，区分受保护和未受保护的端点，并且绝不要将可重复使用的凭据写入源代码、日志或成果文档。 ## 谨慎添加依赖项，不把密码留在日志里 添加依赖项前检查软件包清单，并使用代码仓库规定的安装工作流。如果项目依赖提交前格式化和代码检查钩子，应使其保持启用状态。 将依赖项覆盖规则视为临时安全控制，而不是永久装饰。升级父软件包时，测试是否可以移除覆盖规则，运行相关漏洞扫描；如果解析得到的依赖项仍不安全，则保留该覆盖规则。 测试集成功能时，不要扩大凭据暴露范围。如果外部提供方的真实行为不是测试对象，应对其进行模拟，并确保日志中不含令牌、密码和个人标识符。 ## 结束前检查差异并报告检查结果 先阅读再规划，实施能够保持完整性的最小变更，并在扩大范围前验证每个受影响的边界。对于较大的变更，应使步骤明确且便于审查，不要把后端、API、客户端和界面工作混在一个不透明的步骤中。 报告完成前，检查差异，并运行变更领域所需的格式化工具、代码检查工具、类型检查、测试、迁移检查和视觉验证。不要仅为做足表面功夫而增加完整构建或无关的测试套件。 报告变更内容、已运行的检查、特意留在范围之外的更广泛检查以及任何剩余风险。完成工作需要来自已变更行为的证据，而不仅是成功编辑文件。