feat(review): back comment-status and presubmit for Aone Code targets

docs/design/2026-08-13-review-platform-provider-abstraction.md

@@ -490,8 +490,22 @@ Enterprise paragraph.
     the gate #9616's self-PR read passes through: `ensureAoneAuthenticated`
     now returns the whoami account (`--format json`, one spawn), so the
     version floor applies to the presubmit seam as well. Still open:
-    dedup backing for Aone, cleanup audit, the ai_comment marking flag
+    dedup backing for Aone, the ai_comment marking flag
     (a1-side), the render-adjudication carve-out.
+  - **Landed (2026-08-21, #9627): the dedup backing for Aone** —
+    `comment-status` and `presubmit` route an Aone target at the a1 reads
+    (`mr view` author+head, `mr status` gates, `mr comment list`,
+    `auth whoami`) and reuse the SAME pure classification core the GitHub
+    path pins, so the buckets, the downgrade flags, and the report schema
+    stay one contract. The a1 shape differences map onto the GitHub
+    inputs: threads ride `parentNoteId`, a `closed` thread is the engaged
+    (resolved) bucket, an `outdated` thread takes the stale bucket (its
+    line was rewritten — a new finding there still posts), comments carry
+    NO commit anchor (code facts degrade to `unknown`; nothing is stale by
+    commit), and drift has no compare API (anchorsAtRisk fails safe). The
+    context-unavailable cap stays until `pr-context` lands. Still open:
+    pr-context Aone backing, the ai_comment marking flag (a1-side), the
+    render-adjudication carve-out.
 
 - **Phase 3b — Aone `pr-context` backing (this change).** The reader gains
   `getReviewContext` + `getCurrentUser` (D1's `getContext` + `self`,

docs/design/2026-08-15-review-aone-provider.md

@@ -61,7 +61,14 @@ findings), and `--comment` on an Aone target refuses cleanly.
   on `pr-context` success, so it is SKIPPED on Aone too — `issue-context`
   works standalone for the workitem evidence but is not wired to Agent 0.
 - `comment-status.ts` anchor-status and `presubmit.ts` CI checks: skip for
-  Aone v1 (the skill already handles their absence).
+  Aone v1 (the skill already handles their absence). **Landed (2026-08-21):**
+  both subcommands are a1-backed, reusing the same pure classification cores
+  the GitHub path pins — see the Phase 3 note in
+  `2026-08-13-review-platform-provider-abstraction.md` for the shape mapping
+  (parentNoteId threading, `closed` → resolved, `outdated` → stale, no
+  commit anchors, drift with no compare API). Of the flows deferred in
+  this section, only `pr-context` remains unbacked (the
+  context-unavailable cap stays until it lands).
 
 _Update (2026-08-21, #9619): `test-plan` is no longer unbacked — its body
 fetch routes through the platform reader (the MR description on Aone, already
@@ -109,8 +116,12 @@ semantics (head-drift refusal, partial-post reporting, host binding).
 1. **Scope**: ship the minimal slice (reader + detection + fetch-pr;
    pr-context/comment-status/presubmit degrade), or also make `pr-context`
    render Aone comments (bigger lift)? Recommendation: minimal slice.
+   _Resolved: minimal slice shipped; comment-status/presubmit backing
+   landed 2026-08-21; pr-context rendering remains open._
 2. Aone comment threading (`closed`, `outdated`) vs GitHub's
    `in_reply_to_id`/`line` model — only matters if `comment-status` joins.
+   _Resolved with the 2026-08-21 backing: `parentNoteId` → `in_reply_to_id`,
+   `outdated` → GitHub's null-line (stale), `closed` → the resolved bucket._
    The ANCHOR half of this (how `--line` lands, what `side`/`outdated`
    read back) is RESOLVED by the 2026-08-21 probe — see
    `docs/design/2026-08-21-review-aone-removed-line-anchoring.md`: new-side

docs/users/features/code-review.md

@@ -382,7 +382,7 @@ The deterministic halves of the pipeline — argument parsing (`qwen review pars
 
 **GitHub Enterprise:** reviewing a PR URL on a non-`github.com` host routes every GitHub call at that host — the review subcommands (`match-remote`, `meta`, `fetch-pr`, `pr-context`, `comment-status`, `issue-context`, `fetch-diff`, `comment-body`, `plan-diff`, `test-plan`, `presubmit`, `compose-review`, `submit`, `publish-assets`) accept `--host` and set it in code, so a forgotten host cannot silently retarget the review at `github.com`.
 
-**Aone Code:** for a clone whose origin is on `gitlab.alibaba-inc.com`, run `/review` from inside that clone — the platform is detected from the remote and the subcommands work, backed by the `a1` CLI (at least 0.1.90 — an older install is refused at authentication time with an upgrade message) — the target number is the global MR id. `fetch-pr` fetches `refs/merge-requests/<id>/head` and builds the worktree + diff, so the agent review of the worktree is unchanged, and `test-plan` works too — it reads the MR description through the same reader. `pr-context` is backed too: it reads the MR's metadata, discussion threads, and previously posted qwen summaries (the machine ledger recovers from them), so an Aone run sees the MR's existing discussion exactly as a GitHub run sees a PR's. Several flows are still skipped or reduced (rather than hitting github.com's same-named repo): `comment-status` has no Aone backing, `presubmit` is backed only for self-PR detection (the `a1 auth whoami` account vs the MR author) and head drift — its CI and existing-comment checks come back neutral — and the `publish-assets` write is skipped. `--comment` **posts** the review through the `a1` CLI: one comment per inline finding, then the summary comment. Aone has no native request-changes state — on that verdict the summary comment carries a blocking header, and any inline Criticals that were actually posted block the merge through the discussion gate while their discussions stay unresolved (when no inline Critical posted, the header is advisory and nothing mechanically blocks the merge). The posted comments carry no AI-comment flag — `a1` cannot set one — so a repo's dedicated `ai_comment` merge gate does not track them. The native `a1 repo mr approve` fires for an Approve verdict when the run read the MR's context (the same gate as GitHub; a context-unavailable run stays capped at Comment). Incremental re-review follows the AGit-Flow update model: an update AMENDS the single CR commit in place, orphaning the head the previous round reviewed — so the cached anchor is ruled WITHOUT ancestry (the anchor-behind-head test would fail for every update), and the re-review scopes the PR's own diff to the files the update touched instead of falling back to a full review; an update that also rebased onto newer master keeps that scope only while the rebase's drift stays within the CR's files — drift touching any other file falls back to the full review, and no drift byte enters the published scope either way. One caveat for repeat rounds: there is no dedup backing yet, so a second `--comment` round re-posts every still-valid finding as a new comment (self-PR detection IS backed: reviewing your own MR gets the same verdict downgrade as on GitHub). See `docs/design/2026-08-15-review-aone-provider.md`.
+**Aone Code:** for a clone whose origin is on `gitlab.alibaba-inc.com`, run `/review` from inside that clone — the platform is detected from the remote and the subcommands work, backed by the `a1` CLI (at least 0.1.90 — an older install is refused at authentication time with an upgrade message) — the target number is the global MR id. `fetch-pr` fetches `refs/merge-requests/<id>/head` and builds the worktree + diff, so the agent review of the worktree is unchanged, and `test-plan` works too — it reads the MR description through the same reader. `pr-context` is backed too: it reads the MR's metadata, discussion threads, and previously posted qwen summaries (the machine ledger recovers from them), so an Aone run sees the MR's existing discussion exactly as a GitHub run sees a PR's. `comment-status` and `presubmit` are a1-backed too (presubmit fully: self-PR detection, head drift, merge-gate CI, and existing-comment dedup), so repeat `--comment` rounds dedup against the MR's existing comments instead of re-posting them (a thread the platform marks outdated — its line no longer maps after an amend — stays re-postable), and self-PR detection works too. The `publish-assets` write is skipped. `--comment` **posts** the review through the `a1` CLI: one comment per inline finding, then the summary comment. Aone has no native request-changes state — on that verdict the summary comment carries a blocking header, and any inline Criticals that were actually posted block the merge through the discussion gate while their discussions stay unresolved (when no inline Critical posted, the header is advisory and nothing mechanically blocks the merge). The posted comments carry no AI-comment flag — `a1` cannot set one — so a repo's dedicated `ai_comment` merge gate does not track them. The native `a1 repo mr approve` fires for an Approve verdict when the run read the MR's context (the same gate as GitHub; a context-unavailable run stays capped at Comment). Incremental re-review follows the AGit-Flow update model: an update AMENDS the single CR commit in place, orphaning the head the previous round reviewed — so the cached anchor is ruled WITHOUT ancestry (the anchor-behind-head test would fail for every update), and the re-review scopes the PR's own diff to the files the update touched instead of falling back to a full review; an update that also rebased onto newer master keeps that scope only while the rebase's drift stays within the CR's files — drift touching any other file falls back to the full review, and no drift byte enters the published scope either way. See `docs/design/2026-08-15-review-aone-provider.md`.
 
 Every run ends with one machine-readable line (`Review complete: <target> — <disposition>`), so scripts and CI wrappers can detect completion and outcome with a single `^Review complete: ` match.