每个 pull request 都有明确结论
当 diff 在中高严重性下干净、且没有未解决的早期 Codna 线程时，codna review 现在以批准结束。否则只评论。它从不请求变更。
- 批准计入分支规则。用 review.approve: false 关闭。
- 当必需检查为红色时，审查会在结论旁边说明：结论只针对 diff，不是合并许可。
- 对 npm 和 PyPI 清单的依赖发现会与注册表核对：被推翻的发现会丢弃，无法核对的标记为 Unverified。
更新日志
PR
App
从推送到结论，看得见的检查
每个任务一个 check run，名为 codna review、codna fix 或 codna secure。
- codna review 检查在你推送的那一刻就显示为排队中。被取代的提交以 neutral 结束；新的 head 会被审查。
- 支持合并队列：组提交继承 pull request 的结论。
- 审查根据 pull request 的大小在 4 到 20 分钟内完成。超时的审查会说明情况，并请你 @codna review 或拆小 PR。
Fix
从红色检查、评论或标签发起修复
pull request 上失败的检查套件在花费任何成本之前先被分诊。
- 基础设施故障以 neutral 结束，不花任何成本；代码故障把失败步骤和日志交给智能体。每个 pull request head 每天一次 CI 失败修复。
- @codna fix 作为对 Codna 发现的回复生效，需要写权限。fork 会收到建议改动。每次拒绝都会在回复中解释。
- 修复提交由 codna-ai[bot] 署名。当你的测试不是 pytest 时，在 codna.yaml 中设置 fix.test_command。
CLI
增量审查、投入级别和新命令
codna review 只重新审查自 Codna 上次审查以来的提交。传入 --full 审查整个 pull request。
- --effort low、medium 或 high 设置审查深度：越高越彻底，成本也越高。默认：置信度 0.75 及以上最多 10 条发现。
- codna impact 离线、零 token 列出 diff 可能影响的测试。codna memory export 写出一个紧凑的只读回忆索引。
- codna report 从终端向公开反馈仓库提交缺陷、功能或问题。
CI
在你自己的 CI 中 fix、review 和 secure
thyn-ai/codna-action@v1 从 PyPI 安装 codna，并运行与本地相同的命令。
- mode: fix 打开 pull request 且从不合并。mode: review 在 pull request 上发布发现和结论。mode: secure 以只读方式分类 SARIF 发现。
- 把 package-spec 固定到某个 codna 版本、把 action 固定到完整提交 SHA，以获得可复现的运行。
- CI 中的审查获得与 App 相同的批准、红色检查提示和经注册表核对的依赖发现。
MCP
面向 Cursor 和 Claude 的五个工具
codna mcp install --client cursor 或 --client claude 把服务器接入你的编辑器，不写入凭据。
- codna_triage、codna_fix、codna_secure、codna_recall 和 codna_report_bug。
- codna_fix 默认只做规划；open_pr 需要 git URL 和服务器环境中的写令牌。
- 回忆在 Telys 上于设备端运行，索引位于你的主目录下。