29d0310f03
Add new frontend pages for the multi-tenant OCDP platform: - Charts page (/charts): Browse Harbor OCI registries to list Helm chart repositories and versions, with deploy modal to launch charts on selected clusters - Monitoring page (/monitoring): Display cluster metrics (CPU/Memory/GPU usage) and per-node details with resource utilization bars - Chart References page (/chart-references): CRUD for chart metadata references - Values Templates page (/templates): CRUD for Helm values templates with version history and rollback support - Sidebar: Add Charts navigation, update Storage and Templates links - api.ts: Add all API client functions (clusterApi, registryApi, instanceApi, monitoringApi, storageApi, chartReferenceApi, valuesTemplateApi, workspaceApi, userApi) with full TypeScript types Note: deploy flow and values template rollback not yet end-to-end tested.
47 lines
2.9 KiB
Markdown
47 lines
2.9 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，在掌握全局上下文后，用优雅的方式重构它（但不要过度设计）。
|
||
|
||
## Ⅱ. 任务管理闭环 (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)
|
||
- 遇到极其复杂的问题时，不要试图在一个终端窗口内硬扛。
|
||
- 拆解子任务，主动进行探索性研究，针对焦点问题逐一击破。
|