在此页面上

发布说明通过识别已更改的代码、它所执行的行为以及其他人可以检查的结果来赢得其地位。最有用的记录包括促使更改的失败。

对于 Zortex 而言，公开工作意味着发布对决策和权衡的有用解释。它确实如此 不 意味着每个存储库、开发环境或用户记录都是公开可访问的。我们的一些实现存储库是私有的。我们应该这样说，而不是暗示一篇公开文章提供了对其未公开代码的独立访问。

这项练习的目的不是最大限度地披露。它是一个可以经受团队成员、工具或假设变化考验的记录。

从一个足够狭窄的声明开始进行测试

一份好的发布说明会指出所做的更改以及观察到更改的系统。在“一个包装器在两个主机之间共享”和“每个桌面UI现在行为相同”之间存在差异。前者可以通过检查特定构建中的共享资产服务、主机插件和安装程序来确定。后者需要对版本、机器、权限和本机控件进行大量测试。

同样的纪律也适用于网站。其内容来源是存储库中的 Markdown 和 YAML frontmatter。一个种子命令将这些文件协调到发布数据库中。草稿和已发布版本是分开的，私人修订在发布之前不应公开出现。这是一个有意义的测试行为。

屏幕截图无法证明该边界。测试需要保存草稿、发布、修改私人工作版本并检查匿名读者是否仍能看到之前的出版物。这就是为什么我们将检查视为具有明确前提条件的论证，而不是整体质量的证书。

保留反例

我们的网站验证记录包含首次失败的案例。编辑器保存仍然标记为脏，因为两个等效的 JSON 对象以不同的顺序序列化了它们的键。更正方法是跟踪编辑版本，以便在进行中的保存期间进行的击键保持未保存状态。

另一个失败来自冗长、不间断的编辑文本。品牌名称、标题和元数据在窄宽度下无法满足固有的布局限制。修复方法包括明确的最小宽度行为和紧急换行。代码和表格保留其自己的滚动；在整个文档上隐藏溢出只会掩盖缺陷。

这两个例子都不光鲜亮丽。它们都具有持久的价值。下一个从事编辑器或响应式卡片工作的人可以理解规则存在的原因，而不是复制一个视觉补丁然后稍后将其删除。

我们首选的证据链如下所示：

Observed problem
       |
       v
Reproducible case
       |
       v
Correction + executed checks
       |
       v
Written result + evidence boundary

公司工作流程图：公司发布我们的决策

设计原则的概念性说明，而非实时集成的认证。

浏览器检查了什么

9月16日，网站的验证记录描述了在macOS上执行的原生Playwright运行，使用了可抛弃的数据库、真实的本地服务器、cookies、登录、编辑和发布。它还记录了早期使用桥接器的浏览器检查，因为在那个特定环境中，Chromium甚至无法导航到localhost。

这些是实质上不同的方法。桥接测试可以锻炼 DOM 行为和真实的服务器请求；它们无法建立普通的浏览器导航、原生 cookie 行为或 TLS。后来的原生运行涵盖了一个不同且更狭窄的主张：本地浏览器工作流在该机器上通过。它没有建立生产正常运行时间或跨平台等效性。

同一页面保留了实验室 Lighthouse 测量及其条件。一台机器上的模拟节流不能保证现场性能。没有设置和范围的结果会得出比证据支持的更强的结论。

我们发布了环境和操作以及结果。原生浏览、桥接 DOM 测试和实验室性能测量回答了不同的工程问题。

编辑工作的真相来源

与实现并行编写有实际原因。我们的网站从版本化文件中读取帖子，其编辑器具有私人草稿/公开出版边界。Markdown源将标题、日期、类别、摘要、图像和文章内容一起携带。

这让未来的编辑可以检查哪些词语和资产属于某个更改。它不能自动保证页面是正确的。编辑审查会检查内容，验证资产路径并将事实声明与其来源联系起来。存储库是存储证据的便捷位置；证据不会仅仅因为存在提交而出现。

我们的出版记录命名了界面中显示的每个值的来源。

什么保持私密，以及为什么

身份验证材料、本地保管库记录、实时客户数据和机器特定测量不属于公开解释，仅仅因为它们可以使文章更生动。报告可以说明某个过程已经过测试，而无需将用户的文件复制到屏幕截图或发布包含凭据的日志。

我们也不将公开撰写等同于安全审计。系统卡或架构说明可以描述控制模型和失败案例。它不能取代对完整部署产品的独立评估。

我们的标准应该是：公布决策、相关机制、结果和剩余未知；保留私人数据；避免暗示未发布的计划已触达用户。

有用的最终状态

当原始实施团队之外的某人可以提出一个具体、有成效的问题时，开放式工作才有用。哪个构建通过了此测试？那是模拟连接器还是实时提供商？授权失败后会发生什么？可以回滚更改吗？什么会证伪文章的主要结论？

如果一个笔记无法回答这些问题，它仍然可能是一个有用的草图。它应该被标记为草图。如果可以，它就成为产品历史中持久的一部分。

来源依据： ZortexHQ/zortex-site、docs/TESTING.md（9 月 16 日记录）、app/content.py、app/markdown.py 和 app/schemas.py。