fix(spa): complete checkout flow, UI standardization, and tailwind v4 styling fixes

.agents/skills/management-talk/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: management-talk
+description: Rewrite engineer-to-engineer content for engineering-org leadership (VPs, directors, PMs) and shape it specifically for Taskboard MCP operations (submit_task_result, add_comment, create_sub_task). Trigger when the user asks to write/rewrite an update, report, or summary for management, or asks to make technical text less jargony specifically for taskboard updates.
+---
+
+# Management Talk for Taskboard MCP
+
+Same audience and translation rules as a traditional written status report, but **shaped specifically for Taskboard MCP operations** — `submit_task_result`, `add_comment`, or `create_sub_task`. The audience reads project names, task numbers, and high-level impacts, but not deep code logic.
+
+Use this any time engineering content needs to be summarized and logged into the Taskboard for management, product teams, or cross-functional tracking.
+
+## When to invoke
+
+- "write something for management / PM to put in the taskboard"
+- "rewrite this technical update for the taskboard comment"
+- "make this non-technical" / "less techy" / "less jargony" for a task update
+- "executive summary" / "status update" to submit the task result
+- "create a sub-task description based on this technical bug"
+
+## Audience — what "engineering-org leadership" means
+
+Engineering-savvy non-engineers: VPs, directors, PMs, release managers. They read product/framework names and cross-reference Task IDs. They do not read code.
+
+They want: *what's the state, what does it mean for customers, who owns it, what's next.* They do not want: how the bug works at the function level.
+
+This is **not** for marketing, finance, or customer-facing audiences — those need a different rewrite. Flag and confirm before producing one.
+
+## Tone
+
+**Keep.** Product names, framework names, team-owned component names, Task IDs, PR numbers, customer/workload identifiers. These are the bridge between engineering and leadership tracking.
+
+**Strip.** Function names, file paths, struct fields, commit SHAs, code expressions, env var names, line numbers, internal data-structure jargon. None of this is actionable to the audience.
+
+**Translate.** Mechanism into one or two sentences of plain-English cause-and-effect. Not *"the kernel reads from `scratchBuf == NULL`"* but *"the GPUs end up reading from an uninitialized buffer and wait forever for a signal that never arrives."*
+
+**Bias toward** active voice, concrete subjects, short paragraphs. *"We found the bug. Alex wrote the fix. PR is up for review."* beats *"The root cause has been identified and a fix has been authored and submitted for review."*
+
+## Channel shapes (Taskboard MCP Tools)
+
+Same content, different shell. Pick the shape that matches the target MCP tool.
+
+### 1. Task Result (`submit_task_result`)
+
+Full structured block used when closing a task. Easy to scan.
+Building blocks (use as many as fit):
+- **Status / TL;DR.** One clear line. *"Fixed and merged."* / *"Workaround applied, full fix pending next sprint."*
+- **Impact.** Who's affected, how badly, what they see.
+- **What broke / What was done.** Short paragraph. Plain-English mechanism, no code identifiers.
+- **Owner / Links.** PR number or reference links.
+- **Next steps / Risks.** Real risks only or what follows after closing this.
+
+### 2. Task Comment (`add_comment`)
+
+Used for continuous updates, flagging blockers, or daily progress. No walls of text.
+- One **TL;DR** as the first line.
+- 2–3 short bullets underneath: current state, blockers (if any), next step.
+- Do not use heavy bolded section labels like the Task Result. Keep it brief and scannable.
+
+### 3. Sub-Task Description (`create_sub_task`)
+
+Used when breaking down a highly technical issue into actionable work for others.
+- **Goal:** One sentence explaining what needs to be done.
+- **Context:** Why we are doing this (plain English).
+- **Technical Hints (Optional):** Keep this brief, pointing to where the engineer should look (this is the only place some technical jargon is acceptable if the assignee is an engineer, but keep it high-level).
+- **Acceptance Criteria:** How to know it's done.
+
+## Source material
+
+The input is one of:
+1. **A Task ID** → fetch via `call_mcp_tool` `get_task_detail` to read current status and comments.
+2. **Pasted technical text** → use directly.
+3. **The current conversation** → if you just produced engineering content, reuse what's in context.
+
+## Output flow
+
+1. **Confirm the target tool** if it's not stated (Result, Comment, or Sub-task).
+2. **Produce the draft** formatted for the Taskboard as a chat message.
+3. **Ask before executing:** Show the exact drafted text, wait for explicit *"post it"* / *"go ahead"*, then execute the corresponding MCP tool (`submit_task_result`, `add_comment`, etc.).
+4. **Never post automatically** without the user seeing the drafted management-talk first.
+
+## Rules
+
+- **Never invent facts** to make the rewrite cleaner.
+- **Never strip a Task ID, PR number, or product name** during de-jargoning.
+- **Get sign-off before executing the MCP tool.**