Traffic-light findings 是一套面向代码评审、审计、验收检查等工作的发现项报告约定，用于统一问题的严重级别、编号方式和证据要求，使评审结果清晰、可追溯、便于决策。
用途与严重级别 该规范以交通灯颜色区分发现项的影响程度。🔴 为阻断级：相关工作在问题修复前不能推进（合并、发布或进入下一阶段），需要修复或获得用户的明确决定。🟠 为值得讨论级：属于真实问题或有力反驳，但不阻断流程，应先讨论，再修复或记录决定。🟡 为次要级：无实质风险的警告或外观问题，可在方便时修复或接受。选择级别时应综合影响与发生可能性；若某发现项仅在特定上下文（例如仅在代理之后）构成阻断，应说明上下文并分别给出级别。
发现项格式 每条发现项都必须有稳定 ID，由表示来源的前缀加数字组成，例如 RT1（红队）、B2（浏览器测试）、V3（验证）、P4（生产就绪）、AC-17（验收标准）。ID 一经分享不得重新编号；确需变更时应同时展示旧 ID 与新 ID。每条发现项包含：ID 与一行标题；位置（文件:行、路由、文档章节或命令）；证据（简短引用、复现步骤或测试输出）；影响（会出现什么问题、影响谁）；以及具体建议。
证据规则 规范强调先验证再断言：需阅读代码或复现行为。自己复现的发现项用 ✔ 标记；证据与推测须分开，推断内容写明“未验证”；无法与代码、文档或复现建立关联的发现项不得上报。
合并多份报告 合并多位评审者或子代理的报告时，应把重复项合并为一条，并列出发现者（如“Found by: security, architecture”）；保留证据支持的最高严重级别，并说明对某评审者级别的调整及原因；上报前应亲自复现 🔴 及最重要的 🟠 发现项；同时增加“已验证无发现”章节，说明评审覆盖了哪些检查。
摘要与用户确认 每份报告开头应给出计数摘要，列出 🔴 阻断、🟠 值得讨论、🟡 次要各有多少条。请用户选择要处理哪些发现项时，应按 ID 与标题逐条引用，发送前核对 ID 与列表是否一致，避免编号错误导致用户回答产生歧义。
优先级与限制 若 AGENTS.md 对该主题设定了不同约定，则遵循 AGENTS.md。该规范本身只定义报告与沟通约定，不涉及具体工具实现、收费、平台或自动化能力；资料未提供这些内容。