E2.21.4reason and return-to-edit设计
禁用原因应可查询，只读状态应说明何时可编辑
别名: 为何禁用 · when can I edit · 只读到什么时候
概念解释
看见不能改，下一问是「为什么」和「什么时候能」。禁用若没有可查询的原因，人会当成故障；只读若不说明编辑权何时回来（或永不回来），人会空等或反复申请。原因与恢复编辑的说明（reason and return-to-edit）把这两句写在状态旁边。它管的是解释，不是外观像不像，也不是只读能不能复制。
机制
不能改是一种拒绝。拒绝没有理由时，人用故障模型去填：刷新、换浏览器、再点一次。禁用的真实理由通常是前置（没选协议、没权限、不在窗口时间），把理由放在可发现的地方，故障模型才会换成任务模型（去勾那一项、去找管理员）。只读的理由是生命周期：已提交待审、归档、由别人锁住。说明「审核通过前不能改」或「归档后永久只读」，等待才有尽头。读屏器用户进不了悬停，原因必须是能聚焦或常驻的文本。
边界
原因涉及安全（「你因风控被限制」）时不能写得太细，但仍要有一条可行动的下一句（联系谁）。系统自己的短暂禁用（保存中）用进度表达，不必写成权限故事。永久只读写「何时可编辑」的诚实答案是「不能」，要比假装有日期更好。多字段共用同一原因时，不要每格重复长文，在分组标题说一次，格内用短引用。
怎么落地
- 每个禁用控件旁放一句原因和可做的下一动作，不要只靠悬停。
- 只读旁写编辑权的条件或「永久只读」，避免无限期空等。
- 让原因能被键盘和读屏器读到。
- 验证：指着禁用和只读各问「为什么」和「我怎样才能改」。答不出、或答案要靠碰巧悬停，解释就还没做成查询对象。再等一天回来，只读若仍无期限，说明就该写成永久。