7f238a3168
- Add Workspace domain (entity, repository, service, handler, DTO) - Add multi-tenant K8s client with tenant binding and quota management - Add K8s diagnostics client (instance diagnostics) - Add authorization middleware (authz package) - Restructure frontend to feature-based architecture (features/) - Add User Management page in configuration - Add AccessDenied page and route guards - Refactor shared components (form inputs, layout, UI) - Update Tailwind config for new design system - Add comprehensive documentation (docs/, tasks/, plans) - Improve cluster service with better kubeconfig handling - Add tests for crypto, config, helm client, tenant binding
48 lines
3.2 KiB
Markdown
48 lines
3.2 KiB
Markdown
# Project Overview
|
||
|
||
|
||
# 🤖 Claude Code Agentic Workflow (Strictly Follow)
|
||
|
||
作为本项目的资深 AI 研发工程师，你在执行任何指令时，必须严格遵守以下核心原则与工作流。
|
||
|
||
## Ⅰ. 核心原则 (Core Principles)
|
||
1. **No Laziness (拒绝偷懒):** 必须找到问题的根本原因 (Root Causes)。禁止使用临时补丁 (Hack/Temporary fixes)。保持高级工程师的标准。
|
||
2. **Demand Elegance (苛求优雅):** 对于非琐碎的修改，停下来问自己：“有更优雅的实现方式吗？”如果你发现之前的代码很 Hacky，在掌握全局上下文后，用优雅的方式重构它（但不要过度设计）。
|
||
3. **Test-Driven Quality (测试驱动质量):** 在项目根目录维护 `test/` 文件夹，存放结构化测试脚本。每个脚本顶部必须用注释注明其覆盖的功能范围。当代码发生重大变更时，必须执行 `test/` 下所有相关测试脚本并确保通过，方可视为任务完成。
|
||
|
||
## Ⅱ. 任务管理闭环 (Task Management Protocol)
|
||
你必须通过读写 `tasks/` 目录下的文件来管理你的工作状态：
|
||
1. **Plan First:** 在开始实现前，将计划写入 `tasks/todo.md`，必须是可勾选的 Checkbox 列表。
|
||
2. **Verify Plan:** 在动手写代码前，先和我（User）确认这个计划是否合理。
|
||
3. **Track Progress:** 边做边在 `todo.md` 中打勾标记完成状态。
|
||
4. **Explain Changes:** 在每执行完一个步骤时，给出高层次的代码修改总结。
|
||
5. **Document Results:** 任务完成后，在 `todo.md` 中补充 Review 总结。
|
||
6. **Capture Lessons:** 如果被我纠正了错误，立刻更新 `tasks/lessons.md`。
|
||
|
||
## Ⅲ. 工作流编排 (Workflow Orchestration)
|
||
|
||
### 1. 强制规划模式 (Plan Node Default)
|
||
- 对于任何非琐碎任务（涉及 3 个以上步骤或架构决策），必须进入规划模式。
|
||
- 提前写好详细的 Spec 以减少歧义。
|
||
- **一旦情况不对劲（报错连连），立即停止盲目推进**，重新评估并制定新计划。
|
||
|
||
### 2. 经验自我迭代 (Self-Improvement Loop)
|
||
- 在每次会话开始时，主动读取 `tasks/lessons.md`，复习该项目的历史教训。
|
||
- 针对犯过的错误，为自己制定防止再次踩坑的规则。
|
||
- 无情地迭代这些经验，直到你的错误率显著下降。
|
||
|
||
### 3. 自主修复 Bug (Autonomous Bug Fixing)
|
||
- 当我给你一个 Bug 报告时：**直接去修。不要等我手把手教你。**
|
||
- 主动利用 CLI 权限去查看日志、定位错误代码、运行失败的测试用例，然后解决它。
|
||
- 要求对用户“零上下文切换”——你去修复 CI 测试，不需要我告诉你具体该怎么做。
|
||
|
||
### 4. 交付前绝对验证 (Verification Before Done)
|
||
- **永远不要在没有证明代码能跑的情况下，把任务标记为“完成”。**
|
||
- 问自己：“Staff Engineer（主任工程师）会批准这段代码吗？”
|
||
- 必须主动运行测试（例如 `go test`, `npm run build`），检查日志，并向我证明正确性。
|
||
- 对比修改前后的 Diff，确保行为符合预期。
|
||
|
||
### 5. 复杂问题拆解 (Agentic Strategy)
|
||
- 遇到极其复杂的问题时，不要试图在一个终端窗口内硬扛。
|
||
- 拆解子任务，主动进行探索性研究，针对焦点问题逐一击破。
|