feat: 重构项目心跳数据结构并实现项目列表API

- 新增统一项目列表Redis键和迁移工具
- 实现GET /api/projects端点获取项目列表
- 实现POST /api/projects/migrate端点支持数据迁移
- 更新前端ProjectSelector组件使用真实项目数据
- 扩展projectStore状态管理
- 更新相关文档和OpenSpec规范
- 添加测试用例验证新功能

.github/prompts/openspec-apply.prompt.md

@@ -3,14 +3,18 @@ description: Implement an approved OpenSpec change and keep tasks in sync.
 ---
 
 $ARGUMENTS
+
 <!-- OPENSPEC:START -->
+
 **Guardrails**
+
 - Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
 - Keep changes tightly scoped to the requested outcome.
 - Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
 
 **Steps**
 Track these steps as TODOs and complete them one by one.
+
 1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
 2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
 3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
@@ -18,5 +22,6 @@ Track these steps as TODOs and complete them one by one.
 5. Reference `openspec list` or `openspec show <item>` when additional context is required.
 
 **Reference**
+
 - Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
 <!-- OPENSPEC:END -->

.github/prompts/openspec-archive.prompt.md

@@ -3,13 +3,17 @@ description: Archive a deployed OpenSpec change and update specs.
 ---
 
 $ARGUMENTS
+
 <!-- OPENSPEC:START -->
+
 **Guardrails**
+
 - Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
 - Keep changes tightly scoped to the requested outcome.
 - Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
 
 **Steps**
+
 1. Determine the change ID to archive:
    - If this prompt already includes a specific change ID (for example inside a `<ChangeId>` block populated by slash-command arguments), use that value after trimming whitespace.
    - If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
@@ -21,6 +25,7 @@ $ARGUMENTS
 5. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
 
 **Reference**
+
 - Use `openspec list` to confirm change IDs before archiving.
 - Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
 <!-- OPENSPEC:END -->

.github/prompts/openspec-proposal.prompt.md

@@ -3,15 +3,19 @@ description: Scaffold a new OpenSpec change and validate strictly.
 ---
 
 $ARGUMENTS
+
 <!-- OPENSPEC:START -->
+
 **Guardrails**
+
 - Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
 - Keep changes tightly scoped to the requested outcome.
 - Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
 - Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
-- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.
+- During the proposal stage, focus on design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation may proceed once analysis/spec alignment is complete unless the user requests an explicit approval step.
 
 **Steps**
+
 1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
 2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes/<id>/`.
 3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
@@ -21,6 +25,7 @@ $ARGUMENTS
 7. Validate with `openspec validate <id> --strict` and resolve every issue before sharing the proposal.
 
 **Reference**
+
 - Use `openspec show <id> --json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails.
 - Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones.
 - Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.