公开代码与项目代码分开维护
公开 AppKernia 提供可复用工程，根目录保留 MIT LICENSE，第三方组件另有声明。官方私有项目基于指定的公开提交继续开发网站与运营功能，这些新增代码不会自动进入公开仓库。
客户的报修规则、内部系统连接和专用配置，应在约定的客户项目中维护。通用缺陷可以到独立的公开 checkout 修复；包含私有业务的工作区应限制公开远端推送，避免一次推送带出未获授权的代码。
为派生版本记录上游提交、项目补丁和构建依赖。交接一个 ZIP 却不记录来源，会让接手者难以判断哪些文件来自框架、哪些文件需要继续保留。相关工程结构可参照公开仓库。
许可文件和素材需要逐项核对
代码交付包应保留实际适用的许可与版权通知。根 LICENSE 无法代替对所有字体、图片、SDK 和组件来源的检查；本项目的第三方声明也单独记录了相关材料。
向客户提供源码、进行再分发或约定专有修改的使用范围时，应审阅对应文件及项目协议。具体授权结论由项目权利人与合格的法律顾问确认。这里不提供再许可或合同条款的替代文本。
凭据按运行环境管理
数据库密码、邮件渠道凭据、OAuth Secret 和签名私钥不应进入源码包，私有 Git 仓库同样不承担秘密存储职责。开发文档可以列出配置名称、申请流程、用途和所需权限，生产值由受控环境提供。
第三方登录的交接，还要交代回调域名归属、厂商账户管理员和轮换操作。维护人员离职后，应能撤销其访问权；更换 Secret 后，应知道哪些服务必须重新加载。否则源码虽然交了，运行环境仍可能依赖原开发者的个人账号。
把交付清单写到能验收
以售后 App 为例，合同范围应说明谁可以派单、何时允许转派、离线回单如何补交，以及外部设备台账由谁提供。只写“App、后台、推送”，无法判断工作是否完成。
| 交接材料 | 需要记录的内容 |
|---|---|
| 源码与构建 | 提交号、依赖锁文件、构建命令及所需工具版本 |
| 数据库 | 迁移版本、现有数据处理方案、核对责任与恢复步骤 |
| 运行环境 | 域名、云资源、证书和厂商账户的持有人及访问权限 |
| 测试记录 | 场景、设备和系统版本、真实结果、仍待验证的条件 |
| 维护安排 | 缺陷处理、兼容升级、部署批准和团队更换时的交接方式 |
“支持推送”尤其需要写清证据。服务端已接受请求、厂商已受理和设备已显示通知是不同状态，不能只用一个勾选框表示。若真实设备未参与验收，应将其保留为待验证项。
派生项目如何跟进升级
升级前比较公开基线与项目修改，检查数据库变化，再安排冲突处理、构建和业务回归。保存旧版本、配置及可恢复备份，才能在新版出现问题时执行已约定的恢复流程。合并成功只说明代码层面没有未处理冲突。
当前网站免费目录提供带来源与许可的模块源码，不包含采购订单、付费权益或响应时限承诺。若项目需要实施服务，应单独确认交付范围、费用、维护安排和验收条件，并以实际发布的服务文件为准。