后端架构锻造

解决什么问题

有经验的前端工程师接手中型后端项目时，最常见的失败模式不是代码写不出来，而是在没有确认需求、架构假设和数据影响的情况下直接动手。结果往往是返工、数据边界模糊、权限模型缺失，或者把后端工作流退化成零散的代码代写。Backend Forge 要解决的就是这个问题：把后端架构负责人的思考方式固化成可执行流程，让前端背景的工程师能以低门槛、高纪律地承担后端架构职责。

核心能力与关键步骤

技能的核心工作流是「先路由，再分类，再确认，再执行」。启动后按顺序执行：

• 项目状态检测：运行 scripts/detect_project_root_state.py 判定当前是空目录、新项目、已有 Spring Boot / FastAPI / Django 项目还是非后端项目。
• 任务分类：通过 scripts/classify_task.sh 判定执行策略，从标准 bf-、轻量 bf-fast 到全自动 bf-a。
• 任务类型路由：区分架构负责人轨道、新项目共创、API 开发、数据模型迁移、认证鉴权、Bug 排查、测试补强等十余种任务类型。

根据路由结果，技能进入三条执行轨道之一：

1. 架构负责人轨道（A0–A7）：从上下文收集到架构冻结（A5）再到分片交付（A6）和验证收口（A7）。A5 之前禁止大规模实现，高风险选择必须形成 ADR。
2. 新项目共创轨道（C0–C4）：从目标收口到技术定型、领域设计、范围冻结再到实现测试闭环。C3 之前禁止写代码。
3. 现有项目执行轨道（S0–S6）：扫描、需求确认、方案确认、实现、验证、收口。大任务需先冻结子单元。

测试闭环是主验收方式：Bug 修复优先补复现测试，数据迁移必须验证迁移和关键查询，权限改动必须覆盖未登录、越权等路径。脚本门禁（bf_session.sh、gate_check.py）会在写入实现文件前检查确认状态。

适用边界

• 面向 Java/Python 生态，主线框架是 Spring Boot 与 FastAPI，Django 仅作维护支持。
• 定位是中型项目后端架构，企业级平台治理和跨团队生产决策必须显式升级为架构会签。
• 全自动模式 bf-a 可采用安全默认方案，但不得自动决定业务语义、数据删除、权限模型或生产变更。
• 轻量路径 bf-fast 不豁免需求确认与验证，发现数据、权限、事务风险时必须升级到中等或专项模式。