用途：当进程发生段错误、abort 或产生 core dump 时，从 systemd-coredump 的核心转储出发，诊断程序为何在本机崩溃。目标是基于证据给出诚实结论，而非听起来合理的猜测。
主要能力与用法：
- 建立事实：用 coredumpctl info <pid> 查看回溯，并注意进程启动命令行；用 coredumpctl list 判断是偶发还是重复模式。
- 先排除常见原因：用 free -h 与日志检查 OOM kill，被 OOM 杀死的进程不算该进程的 bug。
- 时间线关联：将崩溃时间戳与文件系统 mtime、该时刻前后日志、近期软件包更新对比。
- 阅读整个 core：查看其他线程栈（缩略图、图像加载、IPC、GPU 队列等），并留意地址空间中的第三方代码（扩展、插件、树外驱动），但无证据不归咎。
- 符号化：Arch 提供公共 debuginfod，可用 coredumpctl dump 导出 core 后配合 gdb 与 DEBUGINFOD_URLS="https://debuginfod.archlinux.org" 解析。core 是进程内存的逐字副本，可能含密码、令牌和私密文档，应写入 mktemp 新路径并在完成后删除，不要留在 /tmp。许多包无调试符号，无法解析时应如实说明，不得编造函数名。
- 报告：说明崩溃的程序及其当时在做什么、最可能的机制（区分证据与推断）、是否有用户数据丢失及可从何处恢复（先检查回收站）、是否可能复发及如何避免或修复，并坦承证据局限。
限制与注意：诊断只读，不修复、不整理、不重配置；唯一清理的是自己导出的 core。可应要求提供静音通知：omarchy-crash-mute '<program>' 静音，omarchy-crash-mute '<program>' off 恢复，omarchy-crash-mute 列出已静音项；需传入二进制名（优先）或进程名，名称需加引号，经解释器运行的程序会以解释器为键（如静音 python3.13 会静音所有 Python 程序）。静音不能替代修复。若确属 Omarchy 自身问题，应先阅读 reporting.md 再考虑提交。针对所有程序的开关位于 Trigger > Toggle > Crash Capture。