在 DSHBox 里，两类截然不同的数据住在一起：你在意的工作成果，和让工作成为可能的机器。
把它们放进两棵独立的树，不是实现细节，而是让更新安全、备份简单的那条设计主线。这篇把两棵树都画出来。
唯一重要的规则
用户数据和运行时是两棵独立的树。你的文件住在一个任何操作都不会重写的根下；
运行时——一摞层——住在其余所有地方，并且随时可以被整体替换。关于 DSHBox 的存储，
如果只记一件事，就记这条分界线。
真正属于你的部分
安卓侧的应用私有存储里有一个 user-data/ 目录；在客户机里，它出现在
/root/projects。你创建的一切、每个会话的文件、每个项目——都在这棵树里，
它是你的。
有一个例外住在旁边而不是里面：DSH 自己的配置在 user-data/.dsh。
说它属于你，是因为任何更新都不会碰它；但它是配置而不是项目数据——里面可能有密钥，
这一点在备份时要记住。
层是机器，不是仓库
客户机里的其余部分是一个分层运行时，首次启动时装配，随时可以替换：
|
| | 层 | 提供什么 | 客户机内位置 |
|---|
| base | Debian 13（trixie）根文件系统 | / |
| node | Node.js 24（npm、npx、corepack） | /usr/local |
| dsh | DSH Harness 本体 | /opt/dshapp/runtime |
| android-side | PRoot、加载器与共享内存组件 | 在宿主侧，不在客户机内 |
每一层在启动时都有 SHA-256 哨兵校验。把所有层都当成只读的机器：读它没问题，
写它就是错了。存进层里的文件是“占住房子的人”——层被替换之前很舒服，之后就没之后了。
一套可扩展的布局
/root/projects 就是个普通目录，常规的项目纪律完全适用。
一个项目一个文件夹，会话、导出和文件管理器的工作区视图都会清爽很多：
/root/projects/
├── notes/ # 草稿本，可丢弃
├── website/ # 一个项目一个文件夹
├── scripts/ # 可复用的脚本
└── archive/ # 收尾的工作，挪开不碍事
文件标签页体现了同一条边界：工作区视图只显示 /root/projects；
沙盒视图显示整棵客户机树，其中系统目录、node 层、DSH 层和 .dsh
都按级别带着风险标签。这些标签在实际操作中的表现，见
《文件管理器详解》。
为什么更新是安全的
正是这条边界，让《更新 DSH 与 DSHBox》里的
更新机制可以放心使用。在线 DSH 更新或离线层导入换掉的是层；运行时包导入则整体替换
base、node 和 android-side，逐层校验 SHA-256，并保留一份回滚副本。
在所有这些路径里，user-data 和 .dsh 永远不会被触碰。
你的项目能幸存，不是因为更新器小心翼翼，而是它根本不去那棵树。
备份与常见误区
备份逻辑由此直接推出：把工作区复制出去——用导出，或
《DSHBox 把数据存在哪，怎么备份》里的方法——
若想让配置随行，把 .dsh 一并带上。要避免的误区，恰好是那条规则的镜像：
- 在层里改文件——
/usr/local 下的改动能用到下一次更新换层为止。
- 指望层里的文件熬过运行时导入——导入是替换层；只有
user-data 保证留存。
- 把密钥放在项目文件里——会话读到的任何内容都可能进入上下文，附件或被引用的内容会随提示词一起发往你配置的模型服务商。
一个快速自检。如果“某个文件被更新弄丢了”会让你意外，
那它就不该待在 /root/projects 之外——它就该待在那里，
别处都别放。趁还记得，挪过去。