(CODUX-221) Document QA follow-ups and CI states

[numnx]

🧩 Task: Document QA follow-ups and CI states

Automated task PR opened by Code UX for T08.

📋 Summary

Sprint: Sprint 221 · Clarify QA follow-ups and CI status · Task: T08

Clarify QA change requests and CI progress consistently across Sprint, Task, and Live cards by projecting complete QA follow-up metadata, deriving durable CI workflow states from existing execution evidence, and presenting accessible, responsive badges with end-to-end regression coverage and synchronized documentation.

🤖 Model & Provider

Provider	Codex CLI
Model	gpt-5.6-sol

⏱️ Timing

Started	2026-07-13 20:50:53 UTC
Finished	2026-07-13 20:58:12 UTC
Duration	7m 18s

📊 Token Usage

Metric	Value
Input tokens	173,431
Cached input tokens	2,677,504
Output tokens	16,575
Total tokens	2,867,510
Invocations	1
Tool calls	28
Active time	6m 46s

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

✅ 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
Document how QA requested changes, collapsed follow-up tasks, and event-backed CI workflow states appear and behave across Sprints, Tasks, and Live views.

## Scope
- Edit `docs/dashboard/dashboard-guide.md`
- Edit `docs/dashboard/design-system-sprints.md`
- Edit `docs/dashboard/design-system-tasks.md`
- Edit `docs/dashboard/design-system-live-runtime.md`
- Edit `docs/dashboard/interaction-patterns.md`
- Edit `docs-web/user/dashboard/sprints.md`, `docs-web/user/dashboard/tasks.md`, and `docs-web/user/dashboard/live-session.md`
- Regenerate affected `docs-web/content/docs/user-dashboard-*.mdx` pages and the generated docs registry through the repository sync command
- Describe the finalized behavior from T04, T05, and T06

## Implementation Requirements
1. Explain the blue QA edit badge, the distinction between pass, running, requested changes, and provider failure, and the details available in the accessible hover-and-focus card.
2. Document that generated follow-up task specifications are collapsed initially, what information expansion reveals, and how keyboard, touch, dismissal, focus, responsive layout, and reduced-motion behavior work.
3. Define the pull-request, checks, and merge CI steps; their pending, running, successful, and failed presentations; the red-X failure rule; and the difference between CI failure, review blockers, and merge conflicts.
4. Explain that badges derive from persisted execution events and active attention rather than per-card polling, including latest-event selection, failure aggregation, restart and reconnect behavior, and stale-failure resolution.
5. Keep the Sprints, Tasks, and Live documentation consistent, run the docs synchronization workflow, and review generated content for valid links and product terminology.

## Constraints
- Do not claim behavior or validation that the dependent implementation tasks do not provide.
- Keep canonical `docs/` and public `docs-web/` content aligned; do not create a `docs-release/` directory.
- Do not manually diverge generated MDX content from its source pages.
- Use generic project terminology and never include real customer or live project names.

## Verification
- Run `pnpm run sync:docs-web` and `pnpm run check:docs-web`.
- Run `pnpm run build`.
- Confirm canonical and public pages describe identical QA and CI semantics and that generated documentation contains no broken internal links or stale state descriptions.

🌿 Branch Info

Base: feature/CODUX-221-clarify-qa-follow-ups-and-ci-status
Head: task/feature-codux-22-t08-codex-ef0031cd-mrjp5vs0

---

🤖 Generated by Code UX