每一句现在时的产品陈述都需要状态。没有状态时，读者会把愿景、历史与已交付行为当成同一份合同。
状态词汇
| 状态 | 含义 | 可否出现在公开页 | 所需证据 |
|---|---|---|---|
| 当前合同（Current contract） | 在已命名的目标运行时上可以据此设计的行为 | 可以，用「支持 / 会 / 拒绝」 | 当前源码或类型 以及 测试或在目标版本上观察到的本地运行 |
| 架构（Architecture） | 层次如何配合；仅作定向 | 可以，须标明为解释 | 与当前结构一致；不得发明新的公开 API |
| 实验 / 缺口（Experimental / gap） | 未完成、部分完成或未经 E2E 核验 | 可以，仅当明确标注 | 写明缺什么、未证明什么；不得软化成承诺 |
| 沿革（Lineage） | 旧名称为何仍会出现 | 可以，并写清非承诺 | 产品记录、reference app 或依赖事实——不是功能对等 |
| 未决（Unresolved） | 需要产品或工程决定 | 优先 issue / 审阅笔记；公开页仅可作简短警示 | 点名决策点；不要发明默认答案 |
证据顺序（强制）
- 当前代码、类型、测试与本地运行 才能证明「现在支持」。
- 已合并 PR 只证明某次变更曾经落地。必须再查当前树；后续提交可能已删除或收窄。
- 规划文档、open issue、架构草稿、文章 属于考古。可以引导研究，不能单独建立公开合同。
- 来源冲突时，公开文档写当前实现；冲突记入
research-ledger.md或 issue 评论，而不是用营销文案抹平。
如何给一句话定状态
| 草稿句子 | 正确状态 | 改写方式 |
|---|---|---|
「arc afs ls 会列出路径」 | 当前合同 | 仅在已文档化的 CLI 版本上实际跑过后再保留 |
| 「AFS UI 把 UI 工作与 AFS 路径关联」 | 架构 | 保留为解释；不要追加「稳定扩展 API」 |
| 「所有远端的 Instance DID 生命周期都已完成」 | 实验 / 缺口（若未证明） | 写清本地已核验部分；远端生命周期单独标注 |
| 「Discuss Kit 已并入 ARC」 | 沿革 | 写 reference Blocklet / surface；否认完整旧功能等价 |
| 「第三方可以交付任意 UI 设备」 | 未决 / 非当前 | 在有代码 + E2E 样例前不要写成合同 |
各类 board 应承载什么
| Board 类型 | 主要状态组合 |
|---|---|
| 架构（本 board） | 架构 + 沿革；指向合同 |
| AFS / AUP / Web Device / Blocklets / Identity / CLI | 以当前合同为主；实验缺口须显式标注 |
| 产品营销页 | 可用沿革语言；不得发明开发者合同 |
版本钉扎
页面若包含命令或字段级行为：
- 写明核验所用的 CLI 或包版本。
- 教命令时展示真实输出或错误形态。
- 若本机版本不同，重新跑过再把该页当权威。
本 board 的定向事实以 arc 2.0.0-beta.28 与 ARC 源码 44fbd616f 核验。专题 board 可钉自己的版本；操作工作以更严或更新的核验为准。
覆盖状态的红线
读者可见文字仍受站点定位约束（只谈产品与技术；不谈价格或收益承诺；禁用违禁营销用语；不把未实现写成已交付）。「架构」状态不能为 §1C 越权陈述开脱。