十四个工作日与第 4.2 条冲突，那里承诺的是十个。得二选一——我建议保留十个并调整附件 B。
围绕标题的工作流场景：一份带有高亮段落和锚定批注的渲染文档、评审者的评论气泡、批注随新版本重新锚定的版本跳转、一条被接受的决定，以及一张零未决批注的定稿卡片——由一条流动的线串联，沿途是评审者的头像。
这种卡住你的流程，你早就熟悉了。
文档评审往往发生在工具之间的缝隙里——每道缝隙都要付出一条评论、一个版本或一个下午的代价。
-
没有 qnop: 文档作为邮件附件发出去。
五位评审者、五份副本、五套评论，得有人手动合并。
有了 qnop: 一份文档、一次评审，所有评审者都在同一个地方。
-
没有 qnop: 反馈以“第 4 页第二段第三行”的形式出现。
改的人找段落花的时间比改动本身还长。
有了 qnop: 批注精确锚定在它们所指的行和区域上。
-
没有 qnop: 新版本一出，旧版本上的评论全部失去着落。
于是最稳妥的做法是评审结束前不更新文档。
有了 qnop: 新版本会重新锚定既有批注，而不是丢弃它们。
-
没有 qnop: 没人说得清评审到底完成了没有。
“完成”的意思是有人不再回复讨论串，而不是工作已经收尾。
有了 qnop: 只有零未决批注时，评审才能定稿。
该精确的地方精确，该有结构的地方有结构。
三件事承担了重活：精确锚定、不离原处的讨论，以及让对话延续的版本机制。
标注那一行，而不是那一页。
在渲染后的 PDF 上选中精确的行和区域，用 Markdown 在讨论串中评论。多层锚定会保存文字引用、位置和版面——批注始终指向它想表达的内容，而不是某个今天恰好在那里的坐标。
- 行级、区域级的精确选择
- 支持回应表情的 Markdown 评论
- 在文档与讨论之间一键跳转
讨论始终不离原处。
每条批注都带着自己的讨论串：回复、回应，以及一个真正有含义的状态。未决、已讨论，然后被接受或拒绝——决定就留在它所针对的段落上，而不是躺在某个人的收件箱里。
- 每条批注独立的回复讨论串
- 接受或拒绝是明确的决定
- 可选的评审者匿名机制
新版本延续既有对话。
内容变更会创建不可变的新版本——旧版本从不被改写。既有批注通过模糊匹配重新锚定到新版本上，版本间差异视图精确展示哪些内容移动了。
- 不可变、完整保留的版本历史
- 跨版本的模糊重锚定
- 用于对比视图的版本间差异
一次能亲口告诉你它已完成的评审。
qnop 把评审建模为显式状态机，而不是一条请大家自觉遵守的约定。只要还有未完成的工作，最终状态就无法到达。
-
未决
批注被放在某个段落上，归属于必须回应它的人。
-
已讨论
讨论串在推进：回复、回应，以及做决定所需的上下文。
-
已接受 / 已拒绝
决定记录在批注本身上，并进入审计日志。
-
已定稿
只有零未决批注时才能到达。没有任何事项悄悄掉出清单。
把评审当作一场竞技
评审吞吐量，终于看得见。
评审是没人排进日程的工作。qnop 让这份投入清晰可见：连续纪录、排行榜、成就和玩家卡片档案，把完成评审变成习惯，而不是负担。
-
玩家卡片
一份档案，展示某人真正为评审做了什么。
-
连续纪录与任务
看得见的势头，就在工作所在的仪表盘上。
-
团队段位
按团队的进度与领导力段位，来自真实的评审活动。
你的文档始终在你的掌控之下。
qnop 以自托管为第一设计目标：一个容器运行 REST API 和内嵌的 Web 界面，加上 PostgreSQL 和任意兼容 S3 的对象存储——全部在你自己的基础设施上。
- qnop API + Web 界面
- PostgreSQL 关系型数据
- 兼容 S3 的对象存储 文档
你的基础设施
没有不安全的默认配置
缺少必需的密钥或密钥仍是占位符时，服务器会立即启动失败。不存在会被遗忘的“先凑合用”配置。
企业级登录
带邮箱验证的本地账户，或 OIDC 单点登录。JWT 会话配合轮换刷新令牌，认证端点有速率限制。
默认可追责
每个相关操作都进入审计日志，可由专设的审计员角色查阅——这个角色正是为此而存在。
贴合现实的角色
全局的管理员、成员和审计员角色，加上按团队的负责人——流程需要时，评审还可以在评审者匿名的情况下进行。