feat(review): disclose that Aone posts join the discussion gate only - #9625
Merged
Conversation
Aone has a dedicated ai_comment merge gate for AI-posted review comments. A controlled probe on a scratch CR (issue #9614) resolved the design doc's open question Q4: `a1 repo mr comment create` does NOT auto-set isAiComment for the posting identity (a general and an inline probe both read back false, re-checked against an async classifier), and a1 v0.1.90 exposes no flag to request it — so qwen-posted comments sit in the generic discussion gate only, and the ai_comment gate never tracks them. The same probe re-confirmed Q3: still no native reject/request-changes on the a1 mr surface. Until a1 ships a marking flag (feature request to the a1 CLI), the write path discloses the gate split instead of silently implying participation: the Aone REQUEST_CHANGES note names the posted comments as unflagged and the discussion gate as the only mechanical block, and SKILL.md / the user docs carry the same fact. createMrComment documents the constraint and is named as the seam where a future marking flag wires.
wenshao
requested review from
LaZzyMan,
doudouOUC,
tanzhenxin and
yiliang114
as code owners
August 21, 2026 01:51
github-actions
Bot
added
the
review/self-reported
Collaborator
Author
|
E2E probe report (issue #9614) Controlled write probe, 2026-08-21, a1 v0.1.90, posting identity a personal account, scratch repo
Conclusion: no auto-marking and no explicit flag — qwen-posted comments join the |
Collaborator
|
|
Collaborator
|
Thanks for the PR! Template looks good ✓ Problem: real and evidenced. Issue #9614 scopes this as the next phase of the Aone provider design (open question Q4), and the controlled probe in this thread — one general and one inline comment posted on a scratch MR, both read back Direction: aligned. Aone treats AI comments as a first-class category with its own must-address gate, and claiming blocking semantics while silently bypassing that gate integrates worse than disclosing the split. The a1 CLI (v0.1.90) offers no marking flag today, so explicit disclosure at the moment a request-changes verdict posts is the honest interim behavior; the marking request is filed with the a1 team as workitem 85722050. Size: no concern — 84+/13− across 6 files. The only Approach: scope feels right and minimal. The change does one thing — wires the probe outcome into the existing request-changes terminal note — plus the test that pins the note and the doc updates that record the fact (user doc, skill relay prose, and the design doc resolving Q4 / re-confirming Q3, which belong with the change rather than after it). Nothing I'd cut. Risk: no elevated risk signals — none of the changed files match the revert-correlated high-risk paths. Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题：真实且有证据。Issue #9614 把这项工作总结为 Aone provider 设计的下一阶段（open question Q4），本线程中的受控探测——在 scratch MR 上发布一条普通评论和一条 inline 评论，读回均为 方向：对齐。Aone 将 AI 评论作为一等类别，设有"必须处理"的专属门禁；声称阻塞语义却悄悄绕过该门禁，集成效果反而更差。a1 CLI（v0.1.90）目前没有打标参数，所以在 request-changes verdict 发布时做显式披露是合理的过渡行为；打标需求已作为工作项 85722050 提交给 a1 团队。 规模：无顾虑——6 个文件 84+/13−；唯一触及 方案：范围恰当且最小化。改动只做一件事——把探测结论接入既有的 request-changes 终端提示——加上钉住该提示的测试和记录事实的文档更新（用户文档、skill 转发文案，以及结案 Q4 / 复核 Q3 的设计文档，它们与改动本身同属一批）。没有可砍的部分。 风险：无升级风险信号——改动文件均未命中与 revert 相关的高风险路径。 进入代码审查。🔍 — Qwen Code · qwen3.8-max Reviewed at |
Collaborator
Code reviewThe implementation matches what I'd have proposed for this problem: extend the existing Aone REQUEST_CHANGES terminal note rather than adding a new disclosure surface. No blockers found.
Testing — the PR's own CI, read via APIThis is an unattended run, so nothing was built or executed here — the evidence is the PR's own CI on the reviewed commit. At fetch time the ubuntu unit suite (the PR-event gate) was still in progress and nothing had failed; the macOS/Windows unit legs and the integration leg are skipped by this repo's CI design (merge_group-only jobs), pre-existing and not caused by this PR. The finalize job will refresh the table below once CI settles. One honest gap: the underlying platform fact — that a1 v0.1.90 cannot mark comments as AI — is the author's probe record (scratch MR, both comment shapes read back Final CI results for
One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。 中文说明代码审查实现与我独立提出的方案一致：扩展既有的 Aone REQUEST_CHANGES 终端提示，而不是新增披露面。未发现阻塞问题。
测试——经 API 读取 PR 自身 CI本次为无人值守运行，未构建或执行任何 PR 代码——证据是 PR 自身在受审提交上的 CI。抓取时 ubuntu 单测套件（PR 事件门禁）仍在运行，且无任何失败；macOS/Windows 单测与集成腿被跳过是本仓库 CI 的既有设计（merge_group 专属任务），与本 PR 无关。CI 落定后 finalize 任务会自动刷新下表。 一个如实的缺口：底层平台事实——a1 v0.1.90 无法给评论打 AI 标——是作者的探测记录（scratch MR 上两种评论形态均读回 CI 状态见上方表格（落定后自动更新）。 — Qwen Code · qwen3.8-max Reviewed at |
Collaborator
|
Confidence: 5/5 — clean across every stage; the only open item is the still-running ubuntu suite, so approval is deferred, not withheld. Stepping back: the problem is real — a controlled probe showed posted comments read back unflagged — and the honest response until a1 ships a marking flag is exactly what this PR does: disclose the gate split at the moment blocking semantics are claimed, and document the seam where the flag will wire in. My independent proposal before reading the diff was the same shape (extend the existing REQUEST_CHANGES note, pin it in the Aone submit test, record the fact in the docs), and I found no simpler path the PR missed. The scoping decision I scrutinized hardest — disclosing only in the arm where inline Criticals actually posted — holds: the zero-Critical arm claims no mechanical block and the note already says so, and the gate split only matters where something blocks. The GitHub path is untouched, the seam comment is accurate ( The one thing nobody can verify from this repo is the a1 platform fact itself; the probe record is detailed and read-side corroborated, and the change stays right under either state of the world — when the flag ships, one call site and one note string change. In six months this reads as a clean, honest interim answer, not something to curse at. All stages pass and the guardrail is clear, so the verdict is approve. Approval is deferred until CI lands green on 中文说明置信度：5/5 —— 各阶段全部通过；唯一未决项是仍在运行的 ubuntu 套件，因此批准推迟而非否决。 退一步看：问题是真实的——受控探测显示发布的评论读回无标记——在 a1 提供打标 flag 之前，诚实的回应正是本 PR 所做的：在声称阻塞语义的那一刻披露门禁分裂，并记录未来 flag 的接线点。我在看 diff 之前的独立提案与之同形（扩展既有 REQUEST_CHANGES 提示、在 Aone submit 测试中钉住、在文档中记录事实），也没有找到 PR 遗漏的更简路径。 我最仔细审视的范围决策——只在 inline Critical 实际发布的分支披露——成立：零 Critical 分支本来就没有机械阻塞，提示也已明说，门禁分裂只在有阻塞处才有意义。GitHub 路径零改动，缝隙注释准确（ 本仓库无法验证的唯一事项是 a1 平台事实本身；探测记录详尽且有读侧佐证，且改动在两种情形下都成立——flag 落地时只需改一个调用点和一句提示。六个月后回看，这是一个干净、诚实的过渡方案。 所有阶段通过且护栏无异议，结论为 approve。批准推迟至 CI 在上述提交上全绿——finalize 任务会在剩余检查转绿后发布钉住该提交的批准；若有检查变红或头部移动，会在状态评论中标明。 — Qwen Code · qwen3.8-max Reviewed at |
Contributor
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
qwen-code-ci-bot
previously approved these changes
Aug 21, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
LGTM, looks ready to ship — CI landed green after the review. ✅
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
Reviewed — no blockers. Suggestions are inline.
中文说明
已审查——无阻断问题。 建议见行内评论。
— qwen3.8-max via Qwen Code /review (v0.21.15)
Comment on lines
+289
to
+291
| expect(stderrMock).toHaveBeenCalledWith( | ||
| expect.stringContaining('ai_comment'), | ||
| ); |
Collaborator
There was a problem hiding this comment.
[Suggestion] The two new assertions pin the substrings 'ai_comment' and 'cannot set the flag', but not the disclosure's load-bearing directional claim — that the ai_comment gate does not track the posted comments. A meaning-inverting mutation survives green: changing merge gate does not track them. in submit.ts to merge gate tracks them. leaves both pinned substrings present, all 29 tests still pass, and the terminal note tells the user the opposite of the probed truth about the gate that decides their merge. The adjacent clause so they join the generic discussion gate only can likewise be deleted undetected. Pinning the directional clause closes the hole — confirmed by a mutation probe: with stringContaining('does not track them') added, the inverted mutant fails the test.
Suggested change
| expect(stderrMock).toHaveBeenCalledWith( | |
| expect.stringContaining('ai_comment'), | |
| ); | |
| expect(stderrMock).toHaveBeenCalledWith( | |
| expect.stringContaining('ai_comment'), | |
| ); | |
| expect(stderrMock).toHaveBeenCalledWith( | |
| expect.stringContaining('does not track them'), | |
| ); |
中文说明
新增的两条断言钉住了 'ai_comment' 和 'cannot set the flag' 两个子串，但没有钉住披露中承重的方向性论断——即 ai_comment 门禁不会跟踪发布的评论。含义取反的变异可以存活：把 submit.ts 中的 merge gate does not track them. 改成 merge gate tracks them.，两个被钉住的子串依然存在，29 个测试依旧全绿，而终端提示会向用户传达与探测结论相反的事实（关于决定其合并的门禁）。相邻子句 so they join the generic discussion gate only 同样可以被删除而不被发现。钉住方向性子句即可堵住该漏洞——已经过变异探测确认：加入 stringContaining('does not track them') 后，取反的变异体会使测试失败。
— qwen3.8-max via Qwen Code /review (v0.21.15)
Collaborator
Author
|
@qwen-code /takeover |
qwen-code-dev-bot
added
the
autofix/takeover
Collaborator
|
🤝 Takeover engaged: the autofix loop now manages this PR — it will address new review feedback and resolve base conflicts until the label is removed or the round cap is reached. Remove the 中文说明🤝 已接管：autofix 循环现在管理此 PR —— 将持续处理新的评审反馈与 base 冲突，直到移除标签或达到轮次上限。移除 |
Collaborator
…isclosure note Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Collaborator
|
🤖 Addressed the latest review feedback (round 1/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 1/100 轮）。改动内容与我反驳保留之处如下： Autofix review round summary — PR #9625One inline suggestion, one review body, and one issue-level comment were triaged this round. The inline suggestion was verified with a mutation probe and implemented; the other two items require no code change. Feedback points and dispositions[rc:3826888801] — Suggestion: pin the disclosure's directional claim — IMPLEMENTEDThe finding claims the two assertions added in this PR ( Reproduced before changing anything (source-blind verification):
Change: in [rv:4989272660] — Review body: "Reviewed — no blockers. Suggestions are inline." — NO ACTIONNothing to implement beyond the inline item above. [ic:5364223229] — E2E probe report (issue #9614) — NO ACTION@wenshao's controlled write probe confirms the facts this PR encodes: Conflict notesNone — Verification
中文说明Autofix 审查轮次总结 — PR #9625本轮分诊了一条行内建议、一条审查 body 和一条 issue 级评论。行内建议已用变异探测验证并实现；其余两项无需改动代码。 反馈点及处置[rc:3826888801] — 建议：钉住披露中的方向性论断 — 已实现该发现指出：本 PR 新增的两条断言（ 在改动任何东西之前先复现（来源盲验证）：
**改动：**在 [rv:4989272660] — 审查 body："Reviewed — no blockers. Suggestions are inline." — 无需处理除上述行内项外没有需要实现的内容。 [ic:5364223229] — E2E 探测报告（issue #9614）— 无需处理@wenshao 的受控写探测确认了本 PR 所编码的事实： 冲突说明无 —— 验证
Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
Partially reviewed — gaps disclosed. Suggestions are inline.
Not explored to full depth (tool budget reached): "agent 6b": did not execute submit-aone.test.ts under vitest — the shared review worktree has no node_modules or built workspace dist/ , and a full install/build was o….
Not reviewed: reverse audit — stopped before round 6 by the review time budget.
中文说明
仅完成部分审查，审查缺口已披露。 建议见行内评论。
未探索到全部深度（达到工具调用预算）："agent 6b"：did not execute submit-aone.test.ts under vitest — the shared review worktree has no node_modules or built workspace dist/ , and a full install/build was o…。
未审查：反向审计——评审时间预算不足，未能开始第 6 轮。
— qwen3.8-max via Qwen Code /review (v0.21.15)
Comment on lines
+289
to
+294
| expect(stderrMock).toHaveBeenCalledWith( | ||
| expect.stringContaining('ai_comment'), | ||
| ); | ||
| expect(stderrMock).toHaveBeenCalledWith( | ||
| expect.stringContaining('does not track them'), | ||
| ); |
Collaborator
There was a problem hiding this comment.
[Suggestion] The two assertions pin the disclosure only as independent substring-existence checks over stderrMock's whole call history — each passes if ANY recorded stderr call matches, and neither binds subject to predicate or clause to call — so the note this PR exists to pin (documented as provisional: "Until a1 ships a flag, this note is the disclosure", submit.ts:1010-1011) stays unpinned along three probe-verified axes:
- Content: inverting which gate tracks the comments — "...join the dedicated ai_comment gate only; a repo's generic discussion merge gate does not track them." — keeps both pinned substrings present and this test green while the disclosure tells operators the opposite. Splitting the note across two
writeStderrLinecalls also passes. - Clause coverage: the positive clause ("so they join the generic discussion gate only") and the causal clause ("They are NOT marked as AI comments —
a1 repo mr comment createcannot set the flag") are pinned by no assertion — swapping or trimming either stays green, even though the comment above these assertions claims to pin "The Q4 probe outcome", which lives in the unpinned causal clause. - Call-binding and emission condition: nothing forces the disclosure to share the REQUEST_CHANGES
Note:line (the singlewriteStderrLineatsubmit.ts:1015), and no test pins when the note fires — moving the disclosure sentence into the unconditionalPosted …line (submit.ts:993) keeps every assertion green (the contiguous-fragment fix round 1 suggested in this thread survives it too) while an APPROVE post also prints a disclosure about nonexistent blocking Criticals, and the SKILL.md relay (SKILL.md:109) keys on aNote:line that lost the gate disclosure.
Each mutant was run at the reviewed commit: the inverted wording, split calls, positive-clause swap and causal-clause trim all pass 29/29, and the moved-disclosure mutant additionally passes a probe assertion printing the disclosure on APPROVE. Pin one contiguous fragment from the blocking clause to the end of the disclosure — content and call-binding in one check — plus an emission-condition negative:
Suggested change
| expect(stderrMock).toHaveBeenCalledWith( | |
| expect.stringContaining('ai_comment'), | |
| ); | |
| expect(stderrMock).toHaveBeenCalledWith( | |
| expect.stringContaining('does not track them'), | |
| ); | |
| expect(stderrMock).toHaveBeenCalledWith( | |
| expect.stringContaining( | |
| "block the merge while their discussions stay unresolved. They are NOT marked as AI comments — `a1 repo mr comment create` cannot set the flag — so they join the generic discussion gate only; a repo's dedicated ai_comment merge gate does not track them", | |
| ), | |
| ); |
and in a REQUEST_CHANGES with zero inline Criticals says nothing mechanically blocks, add:
expect(stderrMock).not.toHaveBeenCalledWith(
expect.stringContaining('does not track them'),
);Both halves of the spanning fragment were separately verified contiguous in the real emitted note; the combined pin passes the committed code (29/29) and fails every mutant above (probe: 1–2 tests failed per mutant).
中文说明
这两条断言仅以独立的子串存在性检查钉住披露——每条都对 stderrMock 的全部调用历史匹配，任一 stderr 调用命中即通过；两者既不把主语与谓词绑定，也不把子句与调用绑定。因此本 PR 要钉住的这条提示（源码注释已注明其为过渡方案："Until a1 ships a flag, this note is the disclosure"，submit.ts:1010-1011）在三个经探测验证的轴向上仍未被钉住：
- 内容：把两个门禁的主语互换——"…join the dedicated ai_comment gate only; a repo's generic discussion merge gate does not track them."——两个被钉子串依然存在，测试全绿，而披露告知运维的事实恰好相反；把提示拆成两个
writeStderrLine调用同样通过。 - 子句覆盖：正向子句（"so they join the generic discussion gate only"）与因果子句（"They are NOT marked as AI comments —
a1 repo mr comment createcannot set the flag"）没有任何断言钉住——互换或删掉任一子句测试依旧全绿，尽管上方注释声称这里钉住的是 "The Q4 probe outcome"（该结论恰在未钉住的因果子句中）。 - 调用绑定与触发条件：没有断言强制披露与 REQUEST_CHANGES 的
Note:行（submit.ts:1015处唯一的writeStderrLine）出自同一次调用，也没有测试钉住它的触发条件——把披露句移入无条件的Posted …行（submit.ts:993）后所有断言依旧全绿（本线程 round 1 建议的连续片段修法同样拦不住），APPROVE 发布也会打印一条关于不存在的阻塞 Critical 的披露，而 SKILL.md 的转发（SKILL.md:109）会引用一条已失去门禁披露的Note:行。
上述每个变异体都在受审提交上实际运行过：取反表述、拆分调用、正向子句互换、因果子句裁剪均 29/29 全绿；移动披露的变异体还会让一条 APPROVE 打印披露的探测断言通过。建议用一个从阻塞子句延伸到披露末尾的连续片段——一次检查同时钉住内容与调用绑定——再加一个触发条件负向断言（代码块见英文部分）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
Comment on lines
+289
to
+294
| expect(stderrMock).toHaveBeenCalledWith( | ||
| expect.stringContaining('ai_comment'), | ||
| ); | ||
| expect(stderrMock).toHaveBeenCalledWith( | ||
| expect.stringContaining('does not track them'), | ||
| ); |
Collaborator
There was a problem hiding this comment.
[Suggestion] These pins exercise only the attribution-ON shape — no test pins this note under an attribution-OFF post. The note's count source is deliberately the MARKED pre-post payload (criticalsPosted counted off payload.comments, submit.ts:1012-1014), because under attribution: false the posted bodies lose their severity prefixes and severityOf — a leading-marker classifier (lib/inline-counts.ts:63-72) that never reads the trailing <!-- qwen-review critical --> marker — returns null for all of them. A future edit aligning the count with what was "actually posted" — const criticalsPosted = (post.comments ?? []).filter((c) => severityOf(c) === 'critical').length;, exactly the reading the variable name invites — passes all 29 tests (the mutant was run at the reviewed commit: 29/29 green, invisible). Every attribution-OFF Aone REQUEST_CHANGES post with inline Criticals then flips the note to "posted NO inline Critical discussions, so nothing mechanically blocks the merge; the header is advisory" and drops this disclosure entirely, while Critical discussions actually posted and mechanically block the merge — the operator is told the opposite of the platform state. The fix in the adjacent comment does not close this: it lives in attribution-ON tests, where post.comments === payload.comments. Pin the note in the attribution-OFF test ('an attribution-OFF Aone post strips the severity prefix and appends the invisible marker'):
expect(stderrMock).toHaveBeenCalledWith(
expect.stringContaining('1 inline Critical(s) block the merge'),
);
expect(stderrMock).toHaveBeenCalledWith(
expect.stringContaining('ai_comment merge gate does not track them'),
);The suggested assertions pass the committed code (29/29) and fail the count-source mutant (1 failed) — probe-verified at the reviewed commit.
中文说明
这些钉子只覆盖 attribution-ON 形态——没有任何测试在 attribution-OFF 发布下钉住该提示。提示的计数源刻意取自打标后的发布前载荷（criticalsPosted 来自 payload.comments，submit.ts:1012-1014），因为 attribution: false 时实际发布的正文会被剥掉 severity 前缀，而 severityOf——按首部标记分类（lib/inline-counts.ts:63-72），从不读取尾部的 <!-- qwen-review critical --> 标记——对它们一律返回 null。未来若有人把计数改为"按实际发布的评论"——const criticalsPosted = (post.comments ?? []).filter((c) => severityOf(c) === 'critical').length;，变量名 criticalsPosted 恰好诱导这种读法——全部 29 个测试依旧通过（变异体已在受审提交上运行：29/29 全绿，完全不可见）。此后每一次带 inline Critical 的 attribution-OFF Aone REQUEST_CHANGES 发布都会把提示翻转为 "posted NO inline Critical discussions, so nothing mechanically blocks the merge; the header is advisory"，并完全丢掉本披露，而 Critical 讨论实际已发布且在机械上阻塞合并——运维被告知的与平台状态恰好相反。相邻评论中的修法堵不住这个洞：它们在 post.comments === payload.comments 的 attribution-ON 测试里。请在 attribution-OFF 测试中钉住该提示（代码块见英文部分）。
— qwen3.8-max via Qwen Code /review (v0.21.15)
Collaborator
|
🤖 Addressed the latest review feedback (round 2/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 2/100 轮）。改动内容与我反驳保留之处如下： Autofix round summary — PR #9625 (address-review)Round outcome: changed — one commit ( Feedback dispositions
Changes
Mutation probes (each applied to
|
qwen-code-ci-bot
approved these changes
Aug 21, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
No issues found. LGTM! ✅
Not explored to full depth (tool budget reached): "agent 5": execution of packages/cli/src/commands/review/submit-aone.test.ts under vitest — the review worktree has no node_modules and no built workspace dist, and a full….
中文说明
未发现问题。LGTM！✅
未探索到全部深度（达到工具调用预算）："agent 5"：execution of packages/cli/src/commands/review/submit-aone.test.ts under vitest — the review worktree has no node_modules and no built workspace dist, and a full…。
— qwen3.8-max via Qwen Code /review (v0.21.15)
wenshao
enabled auto-merge
August 21, 2026 08:16
yiliang114
approved these changes
Aug 21, 2026
This was referenced Aug 21, 2026
Collaborator
|
Released in v0.22.0. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
When
/review --commentposts to an Aone Code MR, the comments it creates carry no AI-comment flag — a controlled probe on a scratch CR showed the a1 CLI's comment create neither auto-marks comments for the posting identity nor offers a flag to request marking. This PR wires that probe outcome into the write path as explicit disclosure: the terminal note a request-changes post prints now names the posted comments as unmarked, joins them to the generic discussion merge gate only, and says the repo's dedicated ai_comment gate does not track them. The skill prose that relays the note, the user-facing feature doc, and the provider design doc (resolving open question Q4, re-confirming Q3) carry the same fact, and the provider's comment write seam is documented as the place a marking flag wires in once the CLI ships one — the feature request is filed with the a1 team.Why it's needed
Aone treats AI comments as a first-class category with a dedicated merge gate that requires them to be addressed. A review tool whose comments silently bypass that gate integrates worse than one whose comments join it: findings get resolved with less friction than the platform intends, and the gate's reporting under-counts the AI review activity on the MR. Marking is impossible from the CLI today, so the honest integration is to disclose the split at the moment blocking semantics are claimed, instead of silently implying participation. This was open question Q4 in the provider design doc, explicitly left for the phase after the write path landed.
Reviewer Test Plan
How to verify
a1 repo mr comment list --mr <id> -f jsonsurfacesisAiCommentper comment, anda1 repo mr comment create --help(v0.1.90) shows no marking flag. The controlled probe posted one general and one inline comment on a scratch MR (now closed) — both read backisAiComment: false, re-checked minutes later to rule out async classification.Evidence (Before & After)
N/A — no TUI change; the terminal note is covered by the pinned tests and the probe record above.
Tested on
Environment (optional)
Probe: a1 v0.1.90, scratch repo shaojin.wensj/abc, scratch MR 29427546 (closed, branches deleted). Unit tests via vitest; build + typecheck clean.
Risk & Scope
Linked Issues
Fixes #9614 (the qwen side the issue scopes — probe, wiring, and the a1 request; marking itself awaits the a1 flag).
中文说明
这个 PR 做了什么
/review --comment发布到 Aone Code MR 的评论不带 AI 评论标记——在 scratch CR 上的受控探测证实：a1 CLI 创建评论既不按发布身份自动打标，也没有请求打标的参数。本 PR 把探测结论接入写路径，改为显式披露：request-changes 发布时打印的终端提示现在明确指出发布的评论未打标、只进入通用 discussion 合并门禁，仓库专属的 ai_comment 门禁不会跟踪它们。转发该提示的 skill 文案、面向用户的功能文档与 provider 设计文档（结案 open question Q4、复核 Q3）都记录同一事实；provider 的评论写缝隙被注明为未来打标 flag 的接线点——需求单已提交给 a1 团队。为什么需要
Aone 把 AI 评论作为一等类别，设有"必须处理"的专属合并门禁。评论悄悄绕过该门禁的审查工具，集成效果反而更差：findings 被 resolve 的摩擦小于平台预期，门禁统计也会漏掉 MR 上的 AI 审查活动。当前 CLI 无法打标，诚实的集成方式是在声称阻塞语义的那一刻披露门禁分裂，而不是悄悄暗示参与了门禁。这是 provider 设计文档中的 open question Q4，明确留到写路径落地之后的阶段。
评审者测试计划
如何验证
a1 repo mr comment list --mr <id> -f json会带回每条评论的isAiComment；a1 repo mr comment create --help（v0.1.90）无打标参数。受控探测在 scratch MR（已关闭）上发了一条普通评论和一条 inline 评论，读回均为isAiComment: false，数分钟后复查排除异步分类。证据（前后对比）
N/A——无 TUI 变化；终端提示由上述钉住的测试与探测记录覆盖。
测试环境
macOS ✅；Windows⚠️ ；Linux ⚠️
环境（可选）
探测：a1 v0.1.90，scratch 仓库 shaojin.wensj/abc，scratch MR 29427546（已关闭、分支已删）；单测经 vitest；build + typecheck 全绿。
风险与范围
关联 Issue
Fixes #9614（issue 所界定的 qwen 侧工作——探测、接线与 a1 需求单；打标本身等待 a1 flag）。