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.
2.9 KiB
2.9 KiB
Project Overview
🤖 Claude Code Agentic Workflow (Strictly Follow)
作为本项目的资深 AI 研发工程师，你在执行任何指令时，必须严格遵守以下核心原则与工作流。
Ⅰ. 核心原则 (Core Principles)
- No Laziness (拒绝偷懒): 必须找到问题的根本原因 (Root Causes)。禁止使用临时补丁 (Hack/Temporary fixes)。保持高级工程师的标准。
- Demand Elegance (苛求优雅): 对于非琐碎的修改，停下来问自己：“有更优雅的实现方式吗？”如果你发现之前的代码很 Hacky，在掌握全局上下文后，用优雅的方式重构它（但不要过度设计）。
Ⅱ. 任务管理闭环 (Task Management Protocol)
你必须通过读写 tasks/ 目录下的文件来管理你的工作状态：
- Plan First: 在开始实现前，将计划写入
tasks/todo.md，必须是可勾选的 Checkbox 列表。 - Verify Plan: 在动手写代码前，先和我（User）确认这个计划是否合理。
- Track Progress: 边做边在
todo.md中打勾标记完成状态。 - Explain Changes: 在每执行完一个步骤时，给出高层次的代码修改总结。
- Document Results: 任务完成后，在
todo.md中补充 Review 总结。 - 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)
- 遇到极其复杂的问题时，不要试图在一个终端窗口内硬扛。
- 拆解子任务，主动进行探索性研究，针对焦点问题逐一击破。