docs(website): add v2.13 blog teaser and renumber roadmap

Surface the v2.13 AI inline suggestions post on the landing page and
in the nav, and shift the forge-completeness roadmap to v2.14 so the
remaining GitLab/Bitbucket stubs land in a single jalon.

🪄 Commit via GitWand

Author: Laurent Guitton

ROADMAP.md

@@ -790,7 +790,36 @@ Deux extensions du workflow de review déjà en place.
 
 ---
 
-### v2.14.0 — Voice Input (expérimental)
+### v2.14.0 — Forge completeness
+
+_Suite de v2.10 : combler les stubs `ForgeNotImplementedError` sur GitLab et Bitbucket, et ouvrir les trois méthodes d'intelligence forge-agnostiques._
+
+**GitLab — stubs restants**
+
+- `updateComment` / `deleteComment` : ajout d'un paramètre `prNumber` optionnel dans l'interface `ForgeProvider` (MR IID requis par l'API GitLab Notes) ; mise à jour de `GitLabProvider` et `GitHubProvider` (rétrocompatible)
+- Ancrage diff-line via Discussions API GitLab : remplace les notes générales par des `POST /projects/:id/merge_requests/:iid/discussions` avec `position` (base_sha, start_sha, head_sha, old_line / new_line) — parité avec le behaviour GitHub
+- `getCIChecks` via `gl pipeline list --json` : listing des jobs pipeline, mapping vers `CICheck` commun (status, url, name)
+
+**Bitbucket — stubs restants**
+
+- `getCIChecks` via REST v2 `/commit/{commit}/statuses` : wiring du endpoint déjà connu, mapping vers `CICheck`
+- `convertDraftToReady` : workaround via renommage du titre (`Draft: …` → titre propre) — Bitbucket n'a pas de notion native de draft, mais la convention titre est largement utilisée
+- `updateComment` / `deleteComment` : `DELETE /2.0/repositories/{workspace}/{repo}/pullrequests/{id}/comments/{comment_id}` + `PUT` update — mêmes guards que GitLab sur `prNumber`
+
+**Intelligence forge-agnostique**
+
+- `getConflictPreview` + `getHotspots` : audit des types `PrConflictPreview` et `PrHotspot` — les deux méthodes sont implémentées sur données git locales (Rust, pas d'API forge) ; vérifier si les types peuvent être populés identiquement sur GitLab/Bitbucket ou s'il faut des variants ; supprimer le guard `forge.name === "github"` si l'audit confirme la compatibilité
+- `getFileHistory` (GitLab) : équivalent de la query GraphQL GitHub `pullRequest { reviews { files } }` via l'API REST GitLab MR notes — chips "ce fichier a été reviewé N fois" dans la diff view
+- `getFileHistory` (Bitbucket) : via REST v2 `/pullrequests/{id}/comments?q=…` avec filtrage par path
+
+**Multi-compte provider**
+
+- Passer le contexte `Account` actif dans les méthodes `ForgeProvider` (paramètre optionnel de contexte) — permet de switcher entre `alice` et `bob@corp.com` sur GitHub sans quitter l'app
+- `useAccounts` et `Account` sont déjà en place (v2.10) ; v2.14 connecte le compte à la résolution de credentials dans le provider
+
+---
+
+### v2.15.0 — Voice Input (expérimental)
 
 Inspiré de Gitux, mais intégré au pipeline IA GitWand existant plutôt qu'en silo.
 
@@ -804,7 +833,7 @@ Inspiré de Gitux, mais intégré au pipeline IA GitWand existant plutôt qu'en
 
 ---
 
-### v2.15.0 — Scratch worktree + Conflict Predictor étendu
+### v2.16.0 — Scratch worktree + Conflict Predictor étendu
 
 _Inspiré GitSquid. Extension naturelle du moteur GitWand et du Worktree first-class (v2.7)._
 
@@ -823,7 +852,7 @@ _Inspiré GitSquid. Extension naturelle du moteur GitWand et du Worktree first-c
 
 ---
 
-### v2.16.0 — Monorepo Scope
+### v2.17.0 — Monorepo Scope
 
 _Inspiré GitSquid. Rend GitWand ergonomique sur les gros monorepos (pnpm, Cargo, Nx…)._
 
@@ -834,7 +863,7 @@ _Inspiré GitSquid. Rend GitWand ergonomique sur les gros monorepos (pnpm, Cargo
 
 ---
 
-### v2.17.0 — Safety Bundle : secrets scanner pré-commit
+### v2.18.0 — Safety Bundle : secrets scanner pré-commit
 
 _Inspiré GitSquid. Feature "safety" sans aucune dépendance réseau — tout en local._
 
@@ -851,7 +880,7 @@ _Inspiré GitSquid. Feature "safety" sans aucune dépendance réseau — tout en
 
 ---
 
-### v2.18.0 — Stacked Branches (natif)
+### v2.19.0 — Stacked Branches (natif)
 
 _Feature différenciante : workflow stacked PRs sans CLI externe (Graphite, ghstack…). Scope important — jalon dédié._
 
@@ -872,7 +901,7 @@ Le paradigme : au lieu d'un gros PR, on empile des branches courtes (`feat/step-
 
 - Détection automatique quand la base d'une stack a bougé (push sur `main`, merge d'une branche intermédiaire)
 - Bouton "Restack" en un clic : rebase l'ensemble de la stack en cascade (`git rebase --onto` layer par layer)
-- Preview du restack avec liste des conflits potentiels avant exécution (réutilise le Conflict Predictor de v2.15)
+- Preview du restack avec liste des conflits potentiels avant exécution (réutilise le Conflict Predictor de v2.16)
 
 **PRs**
 

website/.vitepress/config.ts

@@ -146,6 +146,8 @@ export default defineConfig({
           text: 'Blog',
           items: [
             { text: 'All articles', link: '/blog/' },
+            { text: 'AI code review in your PR diff (v2.13)', link: '/blog/v2-13-ai-inline-suggestions' },
+            { text: 'GitHub, GitLab & Bitbucket support (v2.10)', link: '/blog/v2-10-forge-integrations' },
             { text: "Launchpad: cross-repo dashboard (v2.9)", link: '/blog/v2-9-launchpad' },
             { text: 'Why we made LLM resolution opt-in (v2.5)', link: '/blog/v2-5-llm-fallback' },
             { text: 'Hooks, workspaces & agent sessions (v2.7–v2.8)', link: '/blog/agent-sessions-automations-v2-8' },

website/.vitepress/theme/HomeLanding.vue

@@ -1528,10 +1528,10 @@ function cellClass(v: CompareValue | undefined): string {
         <div class="blog-teaser-header">
           <span class="blog-teaser-label">From the blog</span>
         </div>
-        <a href="/blog/agent-sessions-automations-v2-8" class="blog-teaser-card">
-          <div class="blog-teaser-meta">May 2, 2026 · 18 min read</div>
-          <h3 class="blog-teaser-title">Hooks, workspaces, agent sessions, and automations: what went into GitWand v2.7 and v2.8</h3>
-          <p class="blog-teaser-excerpt">Git hooks manager, multi-repo workspaces, worktree quick-create, cross-platform AI agent detection with lsof and /proc/cwd, a daemonless scheduler, and conflict resolution memory.</p>
+        <a href="/blog/v2-13-ai-inline-suggestions" class="blog-teaser-card">
+          <div class="blog-teaser-meta">May 18, 2026 · 14 min read</div>
+          <h3 class="blog-teaser-title">AI code review in your PR diff: how GitWand v2.13 works</h3>
+          <p class="blog-teaser-excerpt">Per-hunk AI critique with a four-tier verdict (ok / nit / suggestion / risk), an inline suggestion editor that stages GitHub suggestion blocks without leaving the diff, and named AI prompt presets for commit messages.</p>
           <span class="blog-teaser-cta">Read article →</span>
         </a>
       </div>

website/blog/v2-10-forge-integrations.md

@@ -167,7 +167,7 @@ Every string in the PR panel that names the PR concept uses `prLabel` — no har
 
 **What works on GitLab in v2.10:** MR list, MR detail, diff, pipeline status (CI), create MR, merge MR, checkout MR, draft→ready conversion, MR notes (general comments), approvals, reviewer candidates.
 
-**Stubs deferred to v2.11:** `updateComment` and `deleteComment` — both require the MR IID alongside the note ID, and the `ForgeProvider` interface's comment methods only take a `commentId`. The interface will gain an optional `prNumber` parameter in v2.11. Diff-line anchoring via GitLab's Discussions API (as opposed to general notes) is also v2.11.
+**Stubs deferred to v2.14:** `updateComment` and `deleteComment` — both require the MR IID alongside the note ID, and the `ForgeProvider` interface's comment methods only take a `commentId`. The interface will gain an optional `prNumber` parameter in v2.14. Diff-line anchoring via GitLab's Discussions API (as opposed to general notes) is also v2.14.
 
 ---
 
@@ -183,7 +183,7 @@ Bitbucket's API quirks that required adaptation:
 
 - **PR state casing.** Bitbucket uses `"OPEN"`, `"MERGED"`, `"DECLINED"` (uppercase). The provider upcases the `state` argument at its boundary.
 - **No native draft.** Bitbucket has no `isDraft` concept. The `convertDraftToReady` method in `BitbucketProvider` is a stub in v2.10 — Bitbucket workarounds (title prefix `"Draft:"`) are not yet implemented.
-- **CI Checks.** Bitbucket Pipelines are accessible via a separate REST endpoint (`/2.0/repositories/{workspace}/{repo_slug}/commit/{commit}/statuses`). That endpoint is wired in v2.11; `getCIChecks` throws `ForgeNotImplementedError` in v2.10.
+- **CI Checks.** Bitbucket Pipelines are accessible via a separate REST endpoint (`/2.0/repositories/{workspace}/{repo_slug}/commit/{commit}/statuses`). That endpoint is wired in v2.14; `getCIChecks` throws `ForgeNotImplementedError` in v2.10.
 - **Approvals only, no "request changes".** Bitbucket's review model has approve / unapprove, but no "request changes" equivalent. `submitReview` with `event: "REQUEST_CHANGES"` silently downgrades to `event: "COMMENT"` on Bitbucket — the review is posted but no blocking flag is set on the PR.
 
 **What works on Bitbucket in v2.10:** PR list, PR detail, diff, create PR, merge PR, checkout PR, PR comments (general + inline via Bitbucket inline anchors), approvals, reviewer candidates (repo members with write access).
@@ -217,7 +217,7 @@ function activeAccount(forge: ForgeName): Account | null {
 }
 ```
 
-In v2.10, multi-account awareness is informational: the active account badge shows "Connected as alice" in the PR panel header, but all API calls still go through a single per-forge provider instance. Per-account provider instantiation — so you can switch between `alice` and `bob@corp.com` on GitHub without leaving the app — is deferred to v2.11, where the `ForgeProvider` methods will receive an optional `Account` context.
+In v2.10, multi-account awareness is informational: the active account badge shows "Connected as alice" in the PR panel header, but all API calls still go through a single per-forge provider instance. Per-account provider instantiation — so you can switch between `alice` and `bob@corp.com` on GitHub without leaving the app — is deferred to v2.14, where the `ForgeProvider` methods will receive an optional `Account` context.
 
 The **Settings → Accounts** tab renders each forge section with its list of accounts, an "Add account" form, and an active-account radio selector. GitHub accounts are displayed with a note that auth is managed by `gh auth login` (GitWand reads the active `gh` account but doesn't store a token); GitLab accounts similarly defer to `glab auth login`; Bitbucket accounts go through the App Password form.
 
@@ -227,11 +227,11 @@ The **Settings → Accounts** tab renders each forge section with its list of ac
 
 Three methods on the `ForgeProvider` interface throw `ForgeNotImplementedError` on GitLab and Bitbucket:
 
-**`getConflictPreview`** uses `git merge-tree` to simulate a merge and return which files conflict and which hunks can be auto-resolved before the merge is executed. This requires local git analysis, not a forge API call — it works by running `git merge-tree MERGE_BASE HEAD PR_HEAD` and parsing the output. There's no reason it can't work on GitLab or Bitbucket (the local git history is available regardless of the forge). It's listed as a stub because the `PrConflictPreview` data structure was designed around the GitHub PR model, and the implementation that feeds it needs review before being declared forge-agnostic. v2.11.
+**`getConflictPreview`** uses `git merge-tree` to simulate a merge and return which files conflict and which hunks can be auto-resolved before the merge is executed. This requires local git analysis, not a forge API call — it works by running `git merge-tree MERGE_BASE HEAD PR_HEAD` and parsing the output. There's no reason it can't work on GitLab or Bitbucket (the local git history is available regardless of the forge). It's listed as a stub because the `PrConflictPreview` data structure was designed around the GitHub PR model, and the implementation that feeds it needs review before being declared forge-agnostic. v2.14.
 
-**`getHotspots`** identifies files in a PR that have been frequently modified together in recent commit history — a heuristic for "this change might require looking at file B if you're editing file A". It's implemented via a commit graph walk in Rust, not a forge API call. Same situation as conflict preview: forge-agnostic in principle, blocked by implementation review. v2.11.
+**`getHotspots`** identifies files in a PR that have been frequently modified together in recent commit history — a heuristic for "this change might require looking at file B if you're editing file A". It's implemented via a commit graph walk in Rust, not a forge API call. Same situation as conflict preview: forge-agnostic in principle, blocked by implementation review. v2.14.
 
-**`getFileHistory`** fetches recent review comments for a set of file paths across the PR's history — used to show "this file has been reviewed three times in the last two weeks" context chips in the diff view. This one does require a forge API call (GitHub's GraphQL `pullRequest { reviews { files } }` query), and the equivalent query path for GitLab and Bitbucket needs separate work. v2.11 for GitLab; v2.12 for Bitbucket.
+**`getFileHistory`** fetches recent review comments for a set of file paths across the PR's history — used to show "this file has been reviewed three times in the last two weeks" context chips in the diff view. This one does require a forge API call (GitHub's GraphQL `pullRequest { reviews { files } }` query), and the equivalent query path for GitLab and Bitbucket needs separate work. v2.14 for GitLab; v2.14 for Bitbucket.
 
 The `PrDetailView.vue` component gates all three widgets behind `forge.name === "github"` checks, so GitLab and Bitbucket users see the diff, comments, and CI status without the intelligence features — a clean partial experience rather than a broken full one.
 
@@ -256,13 +256,13 @@ SSH URLs (`git@gitlab.com:user/repo.git`) and HTTPS URLs (`https://gitlab.com/us
 
 ## What's next
 
-The v2.11 scope is:
+The v2.14 scope is:
 
 **GitLab stubs:** `updateComment` / `deleteComment` (need the `prNumber` in the interface), diff-line comment anchoring via Discussions API, CI Checks (`gl pipeline list`).
 
 **Bitbucket stubs:** `getCIChecks` (Bitbucket Pipelines REST endpoint), `convertDraftToReady` (via title prefix), `updateComment` / `deleteComment` (same interface gap as GitLab).
 
-**Multi-account provider instantiation:** Pass the active `Account` context into `ForgeProvider` methods so a user with two GitHub accounts can toggle which one is used for API calls without leaving the app. The `useAccounts` composable and `Account` interface are already in place; v2.11 connects the account to the provider's credential resolution.
+**Multi-account provider instantiation:** Pass the active `Account` context into `ForgeProvider` methods so a user with two GitHub accounts can toggle which one is used for API calls without leaving the app. The `useAccounts` composable and `Account` interface are already in place; v2.14 connects the account to the provider's credential resolution.
 
 **`getConflictPreview` + `getHotspots` forge-agnostic audit:** Both are implemented on local git data; the audit is about whether the `PrConflictPreview` and `PrHotspot` types need a GitLab/Bitbucket variant or can be populated identically.