治疗性Django后端规划器 是做什么的？
这是一个规划技能，适用于Codex、OpenCode和Claude Code。基于已验证的仓库证据生成可操作的设计；除非明确要求，否则不要在规划模式下修改应用代码或执行迁移。
发现并验证上下文
- 确定请求的结果、验收标准、工作分支、目标分支（如相关）以及预期的部署环境。不要假设分支名称为
production或development。在比较前检查git status和引用。切勿覆盖未提交的工作。 - 当可用时，阅读相关的现有产品/业务文档（波斯语）和技术/质量文档（英语）。如果缺失，准确标记缺失的文档；不要发明业务需求。
- 如果已安装Graphify且有可用的当前图，可选择使用
graphify query、path或explain来定位；千万不要要求必须使用Graphify。如果不可用或过时，直接搜索相关源代码、迁移文件、设置和测试。将图视为提示，而非证据。 - 在实际源代码中验证类、调用点、权限、数据流、配置、数据库约束和外部依赖。
- 从活动的项目配置和锁定文件中确定 Python/Django/运行时版本。报告不一致；不要硬编码历史框架版本。
- 对于分支比较，使用用户实际指定的源和目标引用；区分提交历史与工作树更改。在未考虑用户授权/网络可用性的情况下，不要获取远程引用。
架构与变更影响审查
- 确定所属应用和边界；避免不必要的抽象或跨应用耦合。务实应用 SOLID 和清晰分层原则，而非机械执行。
- 验证公共 API 契约（路由、序列化器、字段类型、状态/错误格式、分页、过滤）、与前端/PWA 的兼容性以及认证/授权/租户隔离。
- 分析 ORM 查询成本、N+1 问题、事务和锁、约束、并发性、数据一致性、迁移顺序和可逆性。
- 包含异步和外部效应（Celery 重试和幂等性、
transaction.on_commit、缓存失效、Elasticsearch/索引同步、HTTP 超时和错误、SMS 网关）。 - 根据需要分析可观测性、安全与密钥、运维、发布、回滚、功能标志和部署顺序。
- 区分已验证的当前行为、文档记录的预期行为、提议的变更和未解决的问题。明确指出任何不匹配。
- 考虑可测试性和现有测试基础设施；在常规自动化测试中不得调用真实的第三方/SMS/Celery 调度。
必需输出
生成一个决策完整计划，包括：
- 范围、目标、约束和验收标准。
- 证据和相关源路径，以及当使用源/目标修订时对应的引用。
- 当前架构/数据流和提议的架构/数据流，以及组件的所有权。
- 有序的实施步骤、受影响的公共接口和兼容性措施。
- 迁移/回填策略、故障处理、可观测性、发布和回滚（如适用）。
- 明确的单元测试/集成测试/API测试/E2E测试/冒烟测试（FireTest）、迁移测试、安全测试和性能测试场景，与风险成比例。
- 需要更新的文档及其受影响的文档页面。
- 不确定性、假设、权衡和受阻决策；仅当必要时才提出有针对性的问题。
技能协作
- 当
treatment-django-engineer调用本技能时，首先返回计划；该工程师负责实施、集成和最终报告。 - 推荐使用
django-product-documentation更新受影响的文档，使用treatment-backend-testing实施测试，但是除非实际找到并调用/读取了这些技能，否则不要声称它们已运行。 - 如果某个依赖技能缺失，记录缺失的依赖，并提供可用的回退计划，不要编造其规则。
- 本技能不会自动对每个琐碎的拼写错误或格式更改运行；根据影响程度调整规划工作量。
不可协商的安全保障
切勿发明领域策略、数据模型、未记录的API行为或测试结果。不得执行静默破坏性数据库操作、提交、部署或更改无关文件。不得仅凭声称而不执行和测量，就宣称覆盖、构建、迁移或集成成功。