实现跨前后端的安全全栈功能时…

适用于从数据库到 UI 的全栈功能开发，需要同时完成后端、前端和安全三方面实现与审查。

适用场景

解决思路

1. 收集需求：明确功能范围和验收标准。
2. 设计方案：同时从前端、后端、安全三个视角考虑解决方案。
3. 编写技术设计：把实现方案记录到 `specs/{feature}_design.md`。
4. 设置安全关卡：写任何代码前先过一遍 `references/security-checklist.md`，确认已处理认证（auth）、授权（authz）、输入验证和输出编码。
5. 增量实现：逐步构建功能，并在构建过程中测试每个组件。
6. 交接：把成果交给 Test Master 做 QA，交给 DevOps 做部署。
7. 按上下文加载参考指南：每个功能都加载 `references/security-checklist.md`，用于检查 auth、authz、validation。
8. 开始功能和三视角设计时，加载 `references/design-template.md`。
9. 实现错误流程时，加载 `references/error-handling.md`。
10. 实现 CRUD、表单、API 流程时，加载 `references/common-patterns.md`。
11. 实现微服务、队列、可观测性、Docker 时，加载 `references/backend-patterns.md`。
12. 实现实时、优化、可访问性、测试时，加载 `references/frontend-patterns.md`。
13. 处理类型共享、部署、架构决策时，加载 `references/integration-patterns.md`。
14. 设计 REST/GraphQL API、版本化、CORS、验证时，加载 `references/api-design-standards.md`。
15. 做技术选型、单体 vs 微服务决策时，加载 `references/architecture-decisions.md`。
16. 完成功能、准备交接时，加载 `references/deliverables-checklist.md`。
17. 必须覆盖前端、后端、安全三个视角。
18. 在客户端和服务端都验证输入。
19. 使用参数化查询，防止 SQL 注入。
20. 对输出进行净化/编码，防止 XSS。
21. 在每一层实现适当的错误处理。
22. 记录与安全相关的事件日志。
23. 写代码前先写实现计划。
24. 边构建边测试每个组件。
25. 不要跳过安全考虑。
26. 不要只信任客户端验证。
27. 不要在 API 响应中暴露敏感数据。
28. 不要硬编码凭据或密钥。
29. 不要在没有验收标准的情况下实现功能。
30. 不要只处理 happy path 而跳过错误处理。
31. 后端示例：使用带 `require_auth` 依赖的认证路由；用 `current_user.id != user_id` 检查当前用户，不匹配时在任何数据库访问前返回 403。
32. 后端示例：使用参数化查询，如 `SELECT id, name, email FROM users WHERE id = ?` 并传 `(user_id,)`，不做原始字符串插值。
33. 后端示例：返回显式 schema，如 `ProfileResponse(**row)`，避免密码/token 泄漏；查不到记录返回 404。
34. 前端示例：用 `apiFetch` 调用 `/users/${userId}/profile`，由它附加认证头；检查 `res.ok`，失败时抛出响应文本错误。
35. 前端示例：在客户端做输入保护，如检查 `Number.isInteger(userId) && userId > 0`，但绝不把它作为唯一防线。
36. 安全示例：认证在服务端通过 `require_auth` 强制；客户端认证头只是便利，不是入口关卡。
37. 安全示例：响应 schema 明确排除敏感字段；ID 不匹配时先返回 403 再做数据库访问，避免通过 404 产生时序泄漏。

适用边界 · 注意事项

• 只做前端、只做后端或只做 API 单侧，不涉及跨层功能实现时，不适用。
• 不涉及任何安全要求或只需要一次性原型验证时，这套分层安全流程可能过重。
• 功能范围或验收标准尚未明确时，不先按此流程实现。