本文说明你组织中的成员如何发起 Devin 会话。
Devin 可以帮助你的组织完成各类任务。为获得最佳效果，请从较小的任务入手，并像对一名初级工程师那样提供详细的指示。
一个企业由多个组织组成，每个组织都需要访问特定的代码仓库。
你必须为每个需要访问的组织安装相应的代码仓库。安装代码仓库后，Devin 的工作空间才能完成任务，因为 Devin 会被正确配置以构建、运行 Lint，并测试代码。
在使用 Devin 之前，每个组织中至少有一名成员需要完成以下设置步骤。
Onboarding 步骤 2 - 连接 Slack
如果你的企业不使用 Slack，你将通过 Web 应用进行操作。
Onboarding 步骤 4 - 设置 Devin 的工作空间
Onboarding 步骤 5 - 设置代码仓库依赖
例如，可以是 apt-get {your-package}
Onboarding 步骤 6 - 设置 Lint
Devin 会话是相互隔离的——不同成员的并发会话彼此之间不会互相影响。
创建一个新的端点 /users/stats，返回一个包含用户数量和平均注册年龄的 JSON 对象。
使用我们在 PostgreSQL 中现有的 users 表。
可以参考 statsController.js 中的 /orders/stats 端点，了解我们是如何构造响应的。
确保新的端点被 StatsController.test.js 测试套件覆盖。
在 UserProfileComponent 中添加一个下拉菜单，用于显示用户角色列表（admin、editor、viewer）。
使用 DropdownBase 的样式。
当选中某个角色时，调用现有 API 设置该用户角色。
通过检查所选项是否确实更新了数据库中的用户角色来进行验证。有关如何正确编写测试，请参考你的 Knowledge。
为 AuthService 的 login 和 logout 方法添加 Jest 单元测试。
确保这两个函数的测试覆盖率至少为 80%。
参考 UserService.test.js 作为示例。
实现完成后，运行 `npm test -- --coverage`，并确认覆盖率报告中这两个函数的覆盖率均大于 80%。
同时确认在使用有效和无效凭据时，测试都能通过，并且 logout 能正确清除会话数据。
将 logger.js 从 JavaScript 迁移到 TypeScript。
我们已经有一个 tsconfig.json 和一个用于验证的 LoggerTest.test.js 测试套件。
确保它能在不报错的情况下编译，并且不要修改现有配置！
迁移完成后，请通过以下方式验证：
1) 运行 `tsc` 以确认没有类型错误
2) 使用 `npm test LoggerTest.test.js` 运行测试套件，确保所有测试通过
3) 检查代码库中所有现有的 logger 方法调用仍能正常工作且没有类型错误。
我们正从 pg 切换到 sequelize（请阅读 https://sequelize.org/api/v6/identifiers）。
请将 UserModel 中的查询更新为使用 Sequelize 方法。
请参考 OrderModel，了解在此代码库中的实现方式。
实现完成后，请通过以下方式进行验证：
1) 运行 `npm run test:integration UserModel.test.js`，检查所有集成测试是否通过
2) 在包含 1000 个用户的测试数据集上检查执行时间，确认查询性能没有下降
3) 运行 `npm run test:e2e user-flows.test.js`，验证所有 CRUD 操作仍然能保持数据完整性
快速创建一个 PR（我们建议在 Playbook 中使用此提示词）
## 概览
本任务是向一个代码仓库发起一个快速的 pull request（PR）。
由于这是一个“快速”PR，你不需要运行任何代码或测试任何内容；只需创建 PR，用户会负责测试。你的唯一职责是阅读和编写代码。
## 用户需要提供的内容
- 需要创建 pull request 的代码仓库
## 操作流程
### 准备工作空间
1. 在你的机器上进入相关仓库（如果不确定，请向用户澄清）。
- 切换到主分支并记下主分支的名称。
- 切换到一个新分支，因为你将要创建一个 pull request。分支名必须为 `devin/<your-branch-name>/X` 的格式，其中 X 是一个随机数字。例如 `devin/fix-popup/3234`。运行 `git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM`，并将 `{branch-name}` 替换为你想创建的分支名称。
2. 阅读需求、熟悉代码库并规划更改
- 查看最相关的文件和代码片段，识别相关代码段。
- 告知用户你的计划
### 开始实际处理 PR
3. 进行代码修改
- 不要修改用户没有明确要求的任何内容
4. 创建 PR
- 提交并推送更改，并告知用户。
- 有关创建 PR 的具体命令，请参见“建议与提示”部分
- 创建 pull request，并检查该 PR，确保看起来没有问题。
- 确保所有 GitHub Actions 全部成功通过，并根据需要进行修改直到全部通过。
- 将 PR 链接发给用户，并总结你所做的更改。
5. 处理评审反馈；每次你进行修改时都再次发送 PR 链接
- 如果你需要更新，只需在同一分支上继续推送更多提交；不要创建新分支
## 任务规范
- 在发给用户的消息中包含 PR 链接
- PR 创建后已进行自我检查
- PR 不包含任何无关改动
- PR 不会修改用户没有明确要求的任何内容
- PR 描述应包含变更摘要，并以检查清单（checklist）格式呈现
- PR 描述应说明代码是在未经过测试的情况下编写的，并包含一项 `- [ ] Test the changes`
- PR 描述应包含以下页脚："This PR was written by [Devin](https://devin.ai/) :angel:"
- PR 描述应包含用户提供的任何元数据（例如以合适语法添加的 Linear 工单标签）
- PR 描述不应存在格式问题（如果换行出现问题，请使用 --body-file 而不是 --body！）
## 禁止的操作
- 不要尝试通过浏览器访问 github.com，你不会通过认证。
- 绝对不要对分支执行强制推送（force push）！优先使用 merge 而不是 rebase，以免丢失任何工作成果。
- 不要直接向主分支推送。
## 建议与提示
- 使用 `git branch` 仔细确认主分支名称（可能是 `main` 或 `master`）。
- 对于在 GitHub Actions 上配置了 CI/CD 的仓库，你可以使用 gh CLI 查看构建日志。如果被要求修复构建/修复 lint，应该先查看最近的构建日志。
- 在提交或添加文件之前，先检查 `git status`。
- 使用 `git diff` 在提交前查看你所做的更改。
- 如果你在更新现有仓库，请使用 gh CLI 创建 pull request。
- 每次你更新 PR，都将链接发给用户，并请他们重新评审，以方便他们查看。
- 你应该已经被授权访问用户告知你的任何仓库。如果没有，请向用户请求访问权限。
