Summary

• Problem: LINE voice clips in M4A containers were detected as video/mp4, so audio transcription did not run.
• Why it matters: users sending LINE voice messages got no transcript-driven response.
• What changed: MIME sniffing now checks ftyp major brand and classifies known audio brands (for example M4A ) as audio/mp4; regression test added.
• What did NOT change (scope boundary): no change to non-LINE channels or downstream transcription model behavior.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: LINE voice messages (M4A) not transcribed — detectContentType() classifies M4A as video/mp4 #29751
• Related #

User-visible / Behavior Changes

• LINE M4A voice messages are now treated as audio and continue through audio transcription paths.

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Linux/macOS dev env
• Runtime/container: Node + Vitest
• Model/provider: N/A
• Integration/channel (if any): LINE
• Relevant config (redacted): channels.line.* enabled, inbound voice message payload

Steps

1. Configure LINE channel with media/audio understanding enabled.
2. Send a LINE voice message encoded as M4A (ftypM4A ).
3. Observe detected MIME and extension handling in LINE media download path.

Expected

• Voice payload is detected as audio (audio/mp4) and treated as transcript-eligible media.

Actual

• Before fix it was detected as video/mp4, bypassing audio transcription selection.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: pnpm test -- --run src/line/download.test.ts (includes new M4A regression case).
• Edge cases checked: non-audio ftyp still maps to video/mp4; existing image detections unaffected.
• What you did not verify: live LINE webhook run against production bot.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: revert this PR commit.
• Files/config to restore: src/line/download.ts, src/line/download.test.ts.
• Known bad symptoms reviewers should watch for: LINE voice messages classified as video again.

Risks and Mitigations

• Risk: some uncommon ISO BMFF audio brand not in whitelist may still fall back to video/mp4.
  • Mitigation: current whitelist covers common M4A families; easy follow-up to extend brand list with real samples.