风险不是从辞职信开始的。它在几周前就已经开始：工程师仍然登录着每一个代码仓库，仍然能完全访问设计文档，并且已经在盘算下一步。这段时间很安静，不会触发任何警报，看起来就像平常的一个星期二。而这恰恰是一家初创公司失去谁真正构建了什么这一最清晰记录的时刻。
真正从门口带走的是什么
很少是成品本身。生产环境的代码仓库通常没问题：有提交记录，有真实的更新日志，也有不止一个人可以证明它的来源。消失的是围绕它的一切。在"正式"仓库存在之前，为早期原型建立的私人仓库。因为那天Slack出故障而粘贴进个人邮箱的设计文档。因为功能被搁置而没人合并的分支，却仍然保存着后来以另一个名字发布的想法的第一个可运行版本。只要这个人还在团队里，这些都显得无关紧要。等到他不在了，这一切都会变成争议的焦点。
一位在分歧之后离开的技术联合创始人，是这个问题最尖锐的体现。两个人可以对同样的六个月有完全不同的记忆，一旦关系破裂，就再也没有共同的说法来确认谁先写下了哪一行代码，谁的草图变成了架构，或者某个想法究竟是何时成形的。剩下的只是记忆对记忆，而这不是证据。
这不仅仅关乎创始人。一位在全职入职之前就构建了某个功能第一版的承包商。一位暑期项目悄悄变成产品核心部分的实习生。一位画出最初架构图的自由职业者。他们都会留下同样的空白，通常没有人注意到，直到一场纠纷迫使某人去寻找一份从未被保存下来的证据。
为什么只在"重大节点"封存会留下漏洞
大多数会想到这个问题的技术团队，往往在错误的时刻才想到。版本被打上标签。合同被签署。如果有什么东西被封存，那就是这些。塑造了这次发布的探索性分支、证明想法本身可行的早期原型、发布实际所依据的内部设计文档，这些通常都得不到同样的对待，因为当大家还在一起写代码时，没有人会想到有人将来会离开。这正好反了过来。文档记录最薄弱的材料，恰恰是即将离开的工程师记得最清楚、也往往最有动机声称功劳的材料。
持续封存究竟确立了什么
解决办法不是组建更大的法务团队，而是把封存当作保存技术成果的日常环节，而不是只留给发布和签约的特殊步骤。实际做法就像合并到主分支一样简单：源代码按固定节奏封存，而不是只在发布时才封存；设计文档在与团队共享的当天就封存，而不是等到定稿那天；早期原型在第一次运行的那一周就封存，而不是几个月之后，甚至根本没有。这一切都不需要有人记得离职可能会发生，只需要它已经成为团队的日常工作方式。根据eIDAS第41条，合格的电子时间戳对其记录的日期和时间的准确性，以及所涵盖数据的完整性，享有推定效力。在瑞士，通过ZertES认证服务商签发的签名，与手写签名具有同等法律效力。这两套框架都不关心纠纷最终出现时谁还在职。它们关心的是记录了什么、何时记录，而这恰恰是故事中不会因讲述者而改变的部分。
设想两位创始人共同构建了产品的第一个可运行版本，十八个月后却因矛盾恶化而分道扬镳。如果早期原型及促成它的设计文档在写成的那一周就已封存，那么就存在一份带日期、防篡改的记录，独立于任何一方的记忆或当下的关系。如果没有封存，纠纷就会归结为谁看起来更有说服力，而这是任何一位创始人都不应该陷入的处境。
这做不到什么
封存不能替代雇佣合同或知识产权转让条款，也不能单凭自身解决一场纠纷。公司仍然需要那些从一开始就确定工作成果归属的基础协议。封存所增加的，是一旦这些协议到位后，纠纷真正需要的证据记录：证明当时存在什么、以何种形式存在、何时存在，且任何一方都无法在关系结束后悄悄改写。
在离职之前养成习惯，而不是之后
等到有人提交辞呈时，再开始封存那些最重要的工作已经太迟了。能够避免这类纠纷的初创公司，都是从一开始就把封存当作保存技术成果方式的一部分，就像把版本控制当作编写代码方式的一部分一样。在下一次离职，无论是计划中的还是突然发生的，让这个问题变得紧迫之前，了解这对软件和知识产权团队意味着什么。
