LAYER 06 · 动手扩展并交付
实战：从插件到可交付产品
用 Package、Bundle、Profile、契约测试和源码快照把扩展变成可维护产品
package → bundle → profile → release一个在本地能跑的插件，离“可交付”还差哪些边界？
先建立直觉
发明一个零件不等于造出商品：还要有规格、装配清单、兼容版本、验收测试、升级说明和召回路径。
MECHANISM
机制拆解
功能按 Service Definition、Provider、Consumer、Policy 分包；Bundle 提供可覆盖配置，Profile 命名产品组合，用户 patch 保留本地差异。
开发者预览意味着 breaking change 是常态；教学与扩展项目应固定 upstream commit、记录 source map、用契约测试和定期 diff 审计更新。
第 1 步 / 共 6 步
定义包边界
导出稳定词汇，避免反向依赖。
INVARIANTS
无论怎么扩展，都不能破坏
- 产品默认配置可用 --dump-config 解释
- 所有用户自定义通过上层 patch 保留
- 教学结论注明 upstream 快照与推断边界
FAILURE MODES
最容易踩中的坑
- ×把示例配置硬编码进 Provider
- ×发布 Bundle 却要求用户修改源码
- ×官方 breaking change 后仍展示旧事件顺序
VERIFY IN SOURCE
不要相信结论，去源码里复核
以下链接固定到官方 deepseek-harness@47f9438；查看当前上游时请留意后续 breaking changes。
KNOWLEDGE CHECK
先停十秒，再揭晓答案
为什么本教学项目必须记录 upstream commit，而不能只写“最新版”？
为什么下一章紧接在这里
你现在拥有一条从心智模型、组合、运行主干、安全耐久性到扩展交付的完整学习路径。架构地图与源码索引会继续作为日常查阅入口。