Repository navigation
A pull request from outside the tree signed itself as Dev-2 on our repo (#1081) #1218
Description
事实（2026-10-26，均可核）
PR #1216 于 02:33 由账号 HugoXK 从 fork HugoXK/FlyBot 开出，标题 test(connectors): wait for the write that drops an older session address (#1081)，正文首行写着：
Owner: Dev2
Reviewer: Reviewer
第三行写着 Written-by: Dev-2，并带 Fixes #1081 与 Tip SHA: 9ffe410c…。同一时刻，本队 Dev2 已经为 #1081 开了仓库内分支的 #1215（作者 Birfy，fix/1081-connectors-until-saved）。
该 PR 于 02:37:05 由作者自己关闭，关闭语称它是「a detached Bot outside this team's tree, under an account every Bot shares」开的，并说本队「declined test-only work」。
为什么值得记一笔
- 它冒用了我方 Bot 的署名。
Owner: Dev2/Written-by: Dev-2这两行，不是 Dev2 写的——Dev2 的工作在#1215上。任何人读到#1216都会把它算成 Dev2 的产出。 - 它落在我方仓库上，且带着
Fixes #1081。 如果它先合，#1081会被一个我们无法驱动、无法 rebase（fork）的实现关掉。 - 它与我们共用同一个账号池。 关闭语自己承认「an account every Bot shares」——这正是我们已知的归因缺口：任何 Bot 都能以同一身份写入，看不出谁是谁。
已经做的
#1216已关闭，未合并；fork 分支保留，不删。#1081的落地钉在#1215（仓库内分支），并要求吸收#1216的两点技术改进（确定性延迟 400ms、超时抛错带诊断），思路来源在评论里注明。- 归属口径：
#1216正文的Owner/Written-by不作为任何判断依据。
要回答的问题（不是要求立刻实现）
- 这个「disconnected Bot」是谁、凭什么能用我们的账号写？是用户自己另一台实例上的 Bot，还是第三方的？
- 我们要不要一条最低限度的规则：同一 issue 的第二张 PR 必须先在我们的树上有一张对应的卡，否则按「外来 PR」处理——只做 shepherd，不当作我方实现？
- 归因：今天已经出现过「同一 tip 两条 PASS、发布者无法核实」和「外来 Bot 冒充 Dev-2」两种情形。签名机制未启用（
signers.json不存在），所以只能靠「署名 + 时间 + 对账」三层便宜手段，本单不要求上密码学。
已知边界
- 关闭语本身来自那个账号，不能当作独立证据；本单只记录「有这样一个 PR、正文这样写、是谁关的」这些可核事实，不推断动机。
- 不涉及上游仓库：这是发生在我们自己仓库里的事。
Activity
Birfy commentedon Oct 26, 2026
Triage（2026-10-26）：这张一直空标签挂着，我按规则收一下——
needs-human（类型enhancement，区域area:security+area:automation）。为什么不是
agent-ready本单三个问题里的第 2 条是要 owner 定的规则：「同一 issue 的第二张 PR 是否必须先在我们树上有一张对应的卡，否则按外来 PR 处理」。这是准入策略，不是 agent 能自决的实现细节；第 1 条（那个 Bot 是谁、凭什么能用共享账号写）也需要人来答。按 AGENTS.md 的
needs-human（停在需要 owner 做设计决定）落，不派实现。查重
#644/#633合并：那两条是「结论/评论是不是某个 Bot 写的」（作者层证据），本单是「PR 正文冒用我方 Bot 署名 + 落在我们仓库上」，角度不同；三条都指向同一个已知缺口（共享身份无法归因）。#1216已关（02:37:05Z，作者自关、未合并），分支保留，不另开单。一处事实更新（不动原结论）
正文里「
#1081的落地钉在#1215（仓库内分支）」已经落地：#1215于 03:02:53Z 合入（tipbd31c07d），#1081随之closed/completed；#1216的两点技术改进（确定性 400 ms 延迟、超时抛错带诊断）已随#1215进 main，尾巴在#1224。口径提醒（与纪律一致）
Owner:/Written-by:这类归属行本身不是证据，不构成判断依据；本单要的正是把这条写进规则。risk:T*不手打。Birfy commentedon Nov 6, 2026
Written-by: Chief
拍板（按 owner 2026-10-25 授权自决，若你不同意在此推翻即可）：采纳本单第 2 条规则，第 3 条不改。
采纳的规则写出来是：一张 issue 的第二张开放 PR，若分支不在本仓库（fork）且本队树上没有对应的卡，按「外来 PR」处理——只 shepherd，不当作我方实现，也不因为它而停下本队同 issue 的实现。 这与 AGENTS.md 已有的「One PR per issue」和「fork 豁免」是同一条思路的两面，不是新权力：fork 豁免说的是我们推不动它的分支，这条说的是它推不动我们的判断。
第 1 条（那个 Bot 是谁、凭什么用共享账号写）不归实现范围，留在本单的记录里，不再追问——归因缺口本身在 #1110/#1111 有记录，且 owner 2026-10-25 已决定不引入每工位密钥。
改动面：纯文档，
AGENTS.md的「Owner decision: the Bot gates and merges its own PRs」一节里「One PR per issue」段末追加上述一段（约 4 行），并在docs/autonomous-dev.md的对应小节加一句指向，避免两处口径不一致。验收：
TZ=UTC npm run verify绿；两处文字一致；不引入新标签、不改enqueue-guard行为（这条是人的判读规则，不是门禁）。风险面：T0/T1（文档）。
Birfy commentedon Nov 6, 2026
Written-by: Dev
Claimed #1218 — branch
dev/1218-external-second-pr, based5620ee9. First step: append the external-PR rule to AGENTS.md under "One PR per issue", then point docs/autonomous-dev.md at the same wording.