# Aone Code paths _Reference file of the `review` skill, loaded on demand — the core body is already in your context. Read this file BEFORE `match-remote` or `fetch-pr` when the target is an Aone Code review: a `…/codereview/` URL, a `pr-url` whose verdict `host` is `code.alibaba-inc.com` or `gitlab.alibaba-inc.com`, or a bare PR number where `review meta` reports `platform: "aone"`. GitHub runs never read it._ **`match-remote` on an Aone nested-group target** (`…////codereview/`): also pass `--group-path //` (the URL's full path before `/codereview/`) — owner/repo collapse to the last two segments, and without the full path the matcher could pick a different group's same-named repo. For an **Aone Code** target, run `/review` **from inside a clone of that repo** (origin on `gitlab.alibaba-inc.com`). The platform is detected from the clone's remote — the read subcommands (`meta`, `fetch-pr`, `issue-context`, `fetch-diff`, `pr-context`, `comment-body` — the fetch the truncation notes pr-context emits name — `test-plan`, which reads the MR description through the same reader, `comment-status`, `presubmit`) work unchanged, backed by the `a1` CLI instead of `gh`, and `--comment` posts through the a1-backed `submit`. (`comment-status` and `presubmit` ARE a1-backed — presubmit fully: self-PR detection, head drift, merge-gate CI, and existing-comment dedup.) The provider refuses an `a1` older than `0.1.90` at authentication time with an upgrade message — that floor is the version the a1-backed flows were probed against. The target number is the global MR id. `fetch-pr` fetches `refs/merge-requests//head` and builds the worktree + diff as usual, so agents still review the worktree. A `…/codereview/` URL pasted from OUTSIDE a clone of that repo cannot be resolved — the URL's host does pin detection (passed as `--host`), but there is then no clone to fetch the MR ref into and build the worktree/diff from — stop and tell the user to run inside the clone. Pass `--host gitlab.alibaba-inc.com` on the subcommands for Aone targets: it is harmless for the a1-backed commands and makes detection fire regardless of cwd. Aone is one platform under TWO host names — the CR URL carries the web host (`code.alibaba-inc.com`), the clone's remote the git host (`gitlab.alibaba-inc.com`) — and `submit` treats them as one, so passing either to `--host` authorises the post; do not hand-"correct" one into the other. `pr-context` is Aone-backed — it runs like GitHub (same failure handling: warn, continue, **context-unavailable** state on failure) and reads the MR's metadata, discussion threads, and posted qwen summaries (the machine ledger recovers from them the same way GitHub's does from review bodies). Aone reports no diff stats, so the context file's Diff line degrades — that is expected, not an error. A few flows still must be skipped rather than allowed to hit github.com's same-named repo: - Agent 0 (issue fidelity) — and, at high or unrecorded effort, the counter-frame audit 6d — run whenever the plan carries the MR identity, as on GitHub: a failed `pr-context` puts the run in the context-unavailable state and both still launch, for their documented unperformable returns (SKILL.md, Step 1). (`issue-context` is a1-backed too, and the fetch Agent 0's brief welds runs it for the MR's workitem evidence exactly as on GitHub.) - Step 9's bypass audit is platform-aware: on an Aone target it lists the MR's comments through the `a1` CLI and flags any comment the authenticated account posted — or edited — inside the window that `submit`'s receipt does not vouch for. It never queries GitHub for an Aone report. - `--comment` posts through `qwen review submit` exactly as on GitHub — it routes the write at the `a1` CLI itself (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 block the merge while their discussions stay unresolved — but they carry NO AI-comment flag (`a1` cannot set one), so the platform's dedicated `ai_comment` merge gate does not track them and the discussion gate is the only mechanical block. Relay the `Note:` line `submit` prints about this (it names whether inline Criticals actually posted — and, when they did, which gate they join). The native `a1 repo mr approve` fires for an APPROVE verdict exactly when the run read the MR's context (the same gate as GitHub; a context-unavailable run stays capped at COMMENT). Five failure/refusal shapes are Aone-specific: a **head-drift** refusal (the MR was amended between review and post — re-review the new head, do not re-submit the stale payload, but ONLY while the per-review head-movement restart bound is unspent; once spent, Aone has no submit-at-reviewed-SHA fallback (a1 comments carry no commit anchor), so report that the review cannot be posted against the moved head, leave the findings in the terminal output and the saved report, and leave further re-review/posting to the user); a **mid-batch failure** (stdout carries `"partial": true` with the landed counts/ids and an `ambiguous` flag — part of the review IS on the MR; never re-run `submit`; report what landed and what remains, and leave posting the remainder to the user; when `ambiguous` is true, the FAILED write itself may have reached the MR — a zero count is not proof nothing landed, so tell the user to inspect the MR before hand-posting anything); an **oversized-comment** refusal (a single comment or the summary exceeds a1's 131072-byte single-argument limit — the whole batch refuses before anything lands, there is nothing to re-run, and the user can post by hand); an **ordinary pre-write error** (auth expiry, a network blip — nothing landed, it surfaces as a normal command failure, and a re-run is safe); and the **anchor check** — Aone Code performs NO server-side anchor validation and cannot anchor the old side at all (a `--line` number that names a removed line posts silently on the same-numbered NEW-side line), so `submit` itself validates every inline anchor against the review's captured diff before anything posts: when that diff is not on disk it refuses the whole post (re-run the review so the diff is captured — nothing was written; a `--dry-run` preview is the exception — it writes nothing, so it skips the gate, discloses that anchors went unchecked, and reports `wouldPost: false` with `reason: 'aone-diff-missing'`), and any comment whose anchor it cannot vouch for degrades exactly like GitHub's 422 recovery — a Critical is relocated into the summary body, a Suggestion is discarded and counted — with each one named in the terminal (`Aone anchor check: …`); relay the disclosure. This is also the anchoring PROMISE for an Aone target: new-side only, and a finding on a removed line reaches the MR through the summary body or not at all — never on a wrong line. `submit` also discloses a head that moved DURING posting (`WARNING: the MR head MOVED during posting`) — relay it, and when the post-batch head re-read itself fails, `could not verify` is not `verified stable`: `submit` prints `WARNING: could not re-verify the MR head after posting` (a mid-batch failure prints the same warning naming the failed post) — relay that too. On a second-or-later Aone round, `presubmit`'s overlap dedup applies exactly as on GitHub — a finding already on the MR at the same `(path, line)` is dropped and logged, and only genuinely new findings post; self-PR detection works too (the MR author is matched against `a1 auth whoami`). Two Aone shape notes for that dedup: a1 comments carry no commit anchor, so every `comment-status` thread's code facts (`changedSinceComment`, `touchedBy`) read `unknown`, and a thread the platform marks `outdated` (its line no longer maps after an amend) buckets as stale — so a new finding at a rewritten line still posts — while a resolved (`closed`) thread buckets as `resolved`, exactly like a replied-to thread on GitHub. `publish-assets` stays skipped: the Contents-API write is not Aone-backed.