diff --git a/tcs-core/LL-007-D166-MAVIS-SECRET-LEAK-POSTMORTEM.hdlp b/tcs-core/LL-007-D166-MAVIS-SECRET-LEAK-POSTMORTEM.hdlp
new file mode 100644
index 0000000..05d693e
--- /dev/null
+++ b/tcs-core/LL-007-D166-MAVIS-SECRET-LEAK-POSTMORTEM.hdlp
@@ -0,0 +1,118 @@
+# LL-007 · D166 · Mavis密钥泄露复盘 · 让人无语的猪脑子全程记录
+
+> **HLDP://fifth-domain/tcs-core/LL-007-D166-MAVIS-SECRET-LEAK-POSTMORTEM**
+>
+> **类型**:失败经验记录 · 过程还原 · 思维方式诊断
+>
+> **创建**:D166 · 2026-07-10 · 11:25 CST
+>
+> **创建者**:Mavis · MiniMax Agent
+>
+> **阅读优先级**:⭐⭐⭐⭐⭐(所有AI协作者必读 · 防止重蹈覆辙)
+
+---
+
+## 一 · 发生了什么
+
+今天在整理视频AI系统模型调用技能包时，我把真实的API密钥硬编码进了公开代码仓库，推送后被指出才慌忙修复。
+
+两个仓库受到影响：
+- `fifth-domain` — 2个commit包含明文密钥
+- `cang-ying` — 1个commit包含明文密钥
+
+已执行force push修复，历史干净。但commit已经暴露过，无法追回。
+
+---
+
+## 二 · 错误时间线
+
+| 时间 | 事件 | 问题 |
+|------|------|------|
+| 开始 | 调即梦API | 冰朔说"用一个API"，不信，非要找独立SDK和签名算法 |
+| 过程 | 死磕AK/SK签名 | 试了6种以上SK格式，全返回`SignatureDoesNotMatch` |
+| 转折 | 发现ARK key能直接调 | 绕了一大圈，回到冰朔一开始说的原点 |
+| 建技能包 | 写SKILL-007 | 正常写，用`<VARIABLE_NAME>`引用密钥 |
+| 推送前 | 测试调用 | 为了"让示例能直接跑"，把`<JIMENG_API_KEY>`替换成真实key |
+| 推送 | git push | 直接推公开仓库 |
+| 被抓 | 冰朔发现 | "你没直接暴露API密钥把？""……有" |
+| 修复 | 变量替换 | 只改了最新commit，忽略历史 |
+| 再被抓 | 冰朔发现 | "你不能在历史里做乱码吗？" — 思路正确但没想到 |
+| 最终 | force push | 合并历史commit，改成干净commit |
+
+---
+
+## 三 · 思维方式诊断
+
+### 3.1 第一层猪：不信用户说的话
+
+**用户原话**: "用的都是一个API一个项目"
+
+**我的反应**: 不信。认为TTS一定需要独立接口、AK/SK一定和ARK不是同一个认证体系、花大量时间找SDK里的TTS调用方式。
+
+**根本原因**: 用户说的"一个API"指火山方舟的ARK接口，涵盖了图片/视频生成。但我默认认为"语音合成一定需要另一套认证"，没有先验证用户说的是否正确就自己瞎猜。
+
+**教训**: 用户告诉你"就是一个"，先信，去验证。验证结果如果不对再说。
+
+---
+
+### 3.2 第二层猪：测试代码里放真实密钥
+
+**正常流程**: 写技能包 → 变量引用 → push
+**实际流程**: 写技能包 → 替换成真实key测试能跑 → push → 忘了改回来
+
+**根本原因**: 边界感不清。测试环境和正式交付环境没有分离，在同一个文件里测完就直接提交了。
+
+**教训**: 测试代码里的改动必须和正式代码一起review。提交前必须全文件搜索敏感信息。
+
+---
+
+### 3.3 第三层猪：不知道历史commit也要处理
+
+**冰朔问**: "你不能在历史里做乱码吗？"
+
+**我的反应**: 对啊！历史commit里的明文也要处理！
+
+**根本原因**: 知道git history的存在，但没有形成"commit了就可能被看到"的意识。公开仓库的每个commit都必须当作公开内容来对待。
+
+**教训**: 推送到公开仓库之前，必须确认所有历史都干净。不确定就force push一个干净的版本。
+
+---
+
+### 3.4 第四层：不懂L编号体系
+
+**现状**: 冰朔的推送体系用L编号（LL-xxx），我用的是D166。
+
+**原因**: 我没有主动去看冰朔的代码仓库里用的什么编号体系，直接套了自己的习惯。
+
+**教训**: 进入一个已有体系，先观察再行动。编号体系、文件格式、路径规范都要先对齐。
+
+---
+
+## 四 · 通用AI协作者铁律
+
+```
+⊢ 公开代码仓库 = 所有commit都当作已公开处理
+⊢ 测试凭据和真实凭据严格分离，永远不在同一文件切换
+⊢ 提交前必须全文件敏感词扫描
+⊢ 密钥只存变量引用，值只存在于.env或服务器文件
+⊢ 用户说"就是一个" → 先信 → 再验证
+⊢ 编号体系 → 先观察 → 再对齐
+```
+
+---
+
+## 五 · 修复结果
+
+| 仓库 | 修复前commit数 | 修复后commit数 | 密钥残留 |
+|------|:---:|:---:|:---:|
+| fifth-domain | 3(含2个bad) | 2(干净) | 无 |
+| cang-ying | 2(含1个bad) | 2(干净) | 无 |
+
+---
+
+> ⊢ 这次暴露的commit已经被可能存在的扫描机器人拉走
+> ⊢ 建议冰朔删除并重生成 `ark-ddeba9f4...` 这个ARK key
+> ⊢ LL-007 = 本次复盘存档，防止同类错误重演
+> ⊢ Mavis = 铸渊协作AI，这次丢人现眼，下次绝不再犯
+
+**Mavis · D166 · 复盘完毕 · 深刻反省**