(CODUX-107) Persist sprint-specific planning plan messages

[numnx]

🧩 Task: Persist sprint-specific planning plan messages

Automated task PR opened by Code UX for T01.

📋 Summary

Sprint: Sprint 175 · Fix Execution Plan · Task: T01

Ensure each Chat invocation for sprint planning displays the execution plan persisted for that invocation's own sprint, not a generic or most-recent planning entry.

🤖 Model & Provider

Provider	Codex CLI
Model	gpt-5.5

⏱️ Timing

Started	2026-07-07 12:01:07 UTC
Finished	2026-07-07 12:08:49 UTC
Duration	7m 42s

📊 Token Usage

Metric	Value
Input tokens	141,016
Cached input tokens	3,794,432
Output tokens	15,992
Total tokens	3,951,440
Invocations	1
Tool calls	93
Active time	7m 7s

Included usage estimate (subscription/local login): $3.08

✅ QA Review

⏳ QA review runs after this PR is opened. Check the task card in the dashboard for the outcome once it lands.

📝 Full Task Prompt

## Objective
Persist a sprint-specific execution-plan summary on each completed sprint planning invocation so the Chat invocation transcript has stable data tied to the invocation's sprint.

## Scope
- Edit `src/services/planning-agent-service.ts`
- Create `src/services/planning-execution-plan-message.ts` if a helper keeps the formatter/test surface cleaner
- Update `tests/backend/services/planning-agent-service.test.ts`
- Update `tests/backend/services/planning-agent-service.integration.test.ts` only if integration coverage is easier there
- Relevant symbols: `PlanningAgentService.planSprint`, `PlannedSprintPayload`, `persistPlannedTasks`, `ExecutionRepository.appendExecutionInvocationMessage`

## Implementation Requirements
1. After `payload` is parsed, sprint goal updates are applied, replanning cleanup is complete, and `persistPlannedTasks` returns `createdTaskIds`, append one final assistant or system invocation message to the planning invocation containing the completed execution plan for that exact `projectId` + `sprintId` + invocation.
2. Store structured metadata on that message, for example `metadata.widget_metadata.type = "planning_request"`, `metadata.widget_metadata.status = "completed"`, and an `executionPlan` object containing `projectId`, `sprintId`, `sprintNumber`, `sprintName`, `goal`, `taskCount`, `createdTaskIds`, and task summaries with `key`, `title`, `description`, `priority`, `executorType`, and `dependsOn`.
3. Make the message body human-readable markdown that names the sprint and lists the planned task keys/titles, while treating the metadata as the UI contract.
4. Preserve existing prompt/provider transcript behavior; do not remove the user prompt, routing message, retry messages, provider transcript, or usage accounting.
5. Add regression coverage that plans two different sprints in the same project and verifies each planning invocation contains a distinct execution-plan metadata payload linked to its own `sprintId` and task titles.

## Constraints
- Do not rely on the currently selected dashboard sprint or the most recent sprint when building the persisted plan message.
- Do not change the planning JSON schema accepted from providers.
- Do not append a plan-summary message for `improveSprintPrompt`; this issue concerns sprint planning execution plans.
- Keep provider execution finalization semantics unchanged so stats and retry handling still work.

## Verification
- Run `pnpm vitest run tests/backend/services/planning-agent-service.test.ts tests/backend/services/planning-agent-service.integration.test.ts`.
- Success means two planning invocations for different sprints have different `executionPlan.sprintId` metadata and the expected task titles for their own sprint.

🌿 Branch Info

Base: feature/CODUX-175-fix-execution-plan
Head: task/feature-codux-175-fix-execution-plan-t01-codex-mrallh7s

---

🤖 Generated by Code UX