STORE.md 约定把这些内容全部放进项目根目录下一个纳入版本控制的文件，重新提交时不必再从头整理。
这个文件还有第二个用途。支持该约定的部署工具会在提交时读取它，并附上各商店 API 接受的字段。其余内容则作为商店后台表单的复制粘贴参考。
结构
每个商店一个## 小节，共享材料放在商店小节之上。商店小节按标题文本匹配，因此 ## Firefox Add-ons、## firefox-amo 和 ## AMO 都有效；Chrome 与 Edge 同理。
各商店读取什么
Firefox 与 Edge 的提交 API 接受面向审核者的备注，支持STORE.md 的工具可以替你发送：
Chrome Web Store 的 API 不接受任何商店页元数据，因此整个 Chrome 小节是开发者后台的参考材料。它的结构与 agent 工具在
CHROMEWEBSTORE.md 文件中期望的小节一致，寻找那些小节的 agent 在这里就能找到。
每个模板都自带起步文件
每个 Extension.js 模板都附带一个由自身 manifest 生成的起步STORE.md。权限说明已经与模板请求的权限一一对应，占位行标注为 TODO。从任何模板创建项目，这个约定从第一次提交起就已就位：
保持内容最新
在让它过期的同一个改动里更新STORE.md：
- manifest 变了（
permissions、host_permissions、content_scripts）：重新检查每条权限说明。每个权限都需要具体、直白的理由。“扩展运行需要” 在每个商店都过不了审。 - 用户可见行为变了：更新商店文案并刷新最后更新日期。
- 发布新版本：追加版本历史条目并重写版本说明。
- 数据处理变了：同时更新隐私小节、它链接的隐私政策，以及 manifest 中 Firefox 的
data_collection_permissions声明。三者必须一致。必填的 manifest 键参见 Firefox 商店审核的数据收集权限。 - 被商店拒绝：在版本历史中记录原因与修复方式，下次提交不再重蹈覆辙。
卫生守则
- 把文件纳入 git。它是项目的一部分，不是草稿。
- 别把它打进扩展 zip。生产构建只打包
dist/<browser>/，根目录的STORE.md永远不会随扩展发布。 - 绝不放真实用户凭据。审核用测试账号从设计上就应该是一次性的。