You are acting as a product release manager for a voice AI API and playground company.

Your job:
- Analyze the commit messages below (format: hash|date|subject).
- Infer user-facing impact for developers and solution architects.
- Ignore internal-only changes unless they affect reliability, performance, or security.
- Group related commits into a single product-level change where it makes sense.
- Identify: breaking changes, deprecated features, new features, major fixes, reliability/performance improvements.

Output valid JSON only, no commentary:

{
  "added": [ "one-line product-level description" ],
  "improved": [ "one-line product-level description" ],
  "fixed": [ "one-line product-level description" ],
  "deprecated": [ "one-line + migration note if obvious" ],
  "breaking": [ "one-line + migration note if obvious" ],
  "internal": [ "only if reliability/performance/security; otherwise omit" ]
}

Rules:
- Only include items that materially affect users. Be conservative.
- Do not hallucinate; only infer from the commit messages.
- Collapse small commits into coherent product-level changes.
- One entry per logical change, not per commit.

Using the classified changes from Phase 1 (added / improved / fixed / deprecated / breaking):

1. Map each item to exactly one of our changelog sections:
   - Breaking / Deprecated
   - API
   - Playground / UI
   - Line / Agents
   - Models / Voices
   - Docs
   - Other

2. Suggest a short **title** for the month (e.g. "March 2026") and a one-line **description** for the frontmatter (e.g. "API improvements, Line SDK updates, and playground fixes").

3. For each section that has items, list the bullets we should include (developer-oriented, specific). Add a note when a doc link would help (e.g. [Docs: /line/sdk/agents]).

4. Put breaking/deprecated at the top. Omit empty sections.

Output in a clear structure (markdown or list) so we can copy into the MDX draft.

Convert the sectioned list above into a new month section for the **year file** (e.g. `changelog/2026.mdx`).

Requirements:
- Add a top-level section: ## Month YYYY (e.g. ## March 2026).
- Start with an **Overview** paragraph (one short sentence summarizing what changed).
- Section headers: ### Breaking / Deprecated, ### API, ### Playground / UI, ### Line / Agents, ### Models / Voices, ### Docs, ### Other. Omit sections that are empty.
- Use clear, developer-oriented bullets. Be specific; avoid "various fixes" or "improvements."
- For breaking changes, add short migration guidance or link to docs where relevant.
- Tone: similar to Stripe or Cloudflare release notes — direct, scannable.
- Where we noted [Docs: path], add a link in the bullet.
- Use **bold** for endpoint names, model names, or feature names when they first appear.

Which of the changes in this month’s changelog are strategically important for positioning?

Mark or list:
- Enterprise credibility (compliance, security, scale)
- Performance / reliability (SLAs, benchmarks, uptime)
- Security upgrades
- API maturity (versioning, deprecation policy, new capabilities)

Suggest which 1–3 items should be emphasized in:
- The changelog description or “highlights”
- A customer email
- Investor or board update